Type systems and the future of programming languages - <AUTHOR> https://docs.google.com/document/d/1-aLUwnN0XzLbzICnFLWfCLuD4ULYXGcKAoyRAqTuAIY/edit#heading=h.bxiqdlerl36p <comment><USER2> We aren't going to move to dependently-typed languages based around theorem proving anytime soon. The reason is simple: those languages don't support normal industry development practices, where you don't have time to spend 10x the time on verification as you do on development. (They _do_ support development practices favored by the US Department of Defense, which is perhaps part of the reason why research into such type systems attracts DARPA grants.)

Where such languages may have a future is for proving some kernel of core infrastructure code correct, where the code has such a high value to size ratio that spending the time to prove it correct may cross the line into economic viability. SeL4 is a high-profile example of this. Another example that's been on my mind over the years could be proving the unsafe code in the Rust standard library correct. The latter would be interesting because it would address the criticism of "well, there's unsafe code in libstd, how can you say Rust is safe?" without burdening regular Rust users (not standard library developers) with all the baggage of a complex type system.

<comment><USER3> Not even going to dependent types, the type system and verification capabilities of the SPARK language & toolset already allow for use in the mission-critical (and not only safety-critical) domain.

The tech is progressive so you can go first for 'correct' data flow (no access to uninitialized variables, dataflow constraints like Depends, Global, very interesting stuff already), then for proof of the absence of runtime errors, then for some specific properties (think maybe properties like 'this should never happen' or properties you'd write when doing PBT) to full functional proof. On a procedure to procedure base.

The progress that's been made with support of floating point is amazing. Things that were hard 3 years ago now get proved without help. Pointers are now supported via a rust-like mechanism.

NVidia seems to believe in the tech (well at least for Ada) for some of its new firmwares. I've seen pure algorithmic code fully proven with similar effort as it would have taken testing /AND/ you always find bugs... People that have written some SPARK then start thinking and designing for proof. Code gets simpler, design clearer, loops more evident, added contracts help understanding the interface and clear the mind while reading code (like early returns would have done before).

I don't work for AdaCore or Altran UK but I think they're amazing minds at work here.

<comment><USER2> Maybe some folks are experimenting with it, but I would be shocked if SPARK achieves market share of 1%. Or 0.1%.

<comment><USER3> I think it's a bootstrapping problem, similar to rust adoption. People are now getting enthusiastic about a language with lots of static guarantees and a difficult-to-please compiler, and I keep reading people almost jumping to formal proof/verification ('now that I made all this effort and I get all those static guarantees, why not go the extra static verification mile ?'.

I think the rust formal-methods community should look at what's already been done with Spark2014 (Ada) and Frama-C. A large part is an adaptation of the language for proof (adding /executable/ contracts, some quantifiers, loop variants/invariants, expression functions), and another big part of the work is in why3 and all the SMT tech behind, so can be re-used 'for free'.

Sure not even 0.1% market share today, and I'm not even sure Ada is above this. But it's there, it's already mature, progress is very fast, and it can be tried out for free without 'asking for a quote'. Same for Frama-C.

Sure it's a paradigm shift, but it's not an academic tool with an obscure UI and no retargetable skills.

</comment></comment></comment></comment><comment><USER4> This author predicts that we'll drift towards languages like Agda or Idris, and also discusses how type systems came out of math. I'm curious about two related questions:

1\. Why is it that a minority of math is done with proof systems (i.e. yielding automatically checkable artifacts)? It's burdensome to formalize much of the math that we're interested, even when we're confident in that math. What's the nature of that burden, and how could tools improve to lessen it?

2\. Are the difficulties which prevent a lot of math from being done with these systems the same as the difficulties which prevent programmers from using them? There are many invariants that we can easily know about a program, but representing the lot of them in types would be onerous. How do we make that easier/lighter?

<comment><USER5> > Why is it that a minority of math is done with proof systems (i.e. yielding > automatically checkable artifacts)?

Because most interesting math depends on a lot of other math, and formalizing all of these pre-requirements is a significant burden. The math subfields where this is less of a problem (so-called 'synthetic' mathematics) are also where formalization is being used the most.

<comment><USER6> And additionally it takes a _lot_ of effort to formalise a proof. (I say this as someone who has spent nearly two years formalising basic maths in Agda.) It's true in maths as in programming: 90% of the work is in the last 10%, and if you don't get the last 10%, you haven't got a proof.

<comment><USER5> The usual rule of thumb is that 1 page of paper proof leads to 4 pages of "proper" formal proof. Though this may vary depending on how capable the proof assistant is - AIUI, Agda requires you to write out complete proof terms, whereas other systems may be more capable.

Sometimes you can use a kind of "reflection" that makes many proofs trivial, simply by defining a decision procedure that's proven to be correct in the general case, and having the system perform the appropriate computations. This is how you would deal, e.g. with trivial simplifications in elementary algebra (that can usually be proven to be valid in any ring, field etc.)

<comment><USER6> Correct, Agda has this notion of reflection. The way to do "tactics" in Agda is simply to manipulate expressions, and there's no meta-language in which to do this: it's just Agda all the way down. It's neat, but not easy.

</comment></comment></comment></comment></comment><comment><USER7> It is quite strange how people assume and spread the notion that types are the best or the only place to put propositions. Why ignore the option of specifying propositions as separate invariants or postconditions, verified by proof, model checking, or testing? Why this focus on Curry-Howard, dependent types, and type theory?

<comment><USER5> > Why ignore the option of specifying propositions as separate invariants or > postconditions

These are usually called 'contracts'. But there's not much of a distinction between contracts and refinement-types.

</comment></comment><comment><USER8> LEAN is another popular language in this area.

There are huge benefits for moving the industry in this direction. Such programs that are formally correct eliminates the need for testing almost completely and can cut such infrastructure down by possibly 95%. A program can use dependent typing to prove itself 100% correct vs. 100 unit tests which proves only 100 arbitrary test cases as correct. Unit tests are statistical experiments where the people hope that the verification of 100 arbitrary test cases correlates with the entire program being correct.

Yes, proofs are harder to write than tests, yes there can be bugs in your proof (their can be bugs in tests too). However, I genuinely believe that for the lifetime of an application, in general, the net benefits of dependent types is positive and greater than that provided by testing.

However I do not believe the industry will move in this direction.

The reason why the industry won't move in this direction is largely cultural and intellectual. It is harder to learn how to use dependently typed languages and harder to learn how to write a proof of correctness than it is to learn how to write 30 unit tests.

Additionally you just need to look at how the industry changes to see that the industry does not trend towards "better" technologies for abstraction. HTML, css, javascript, JAVA, SQL are all awkward/imperfect technologies that dominate the industry for reasons other than technical prowess. Culture dictates their dominance as will it dictate the language of the future.

You even get technology that culturally moved backwards simply because people just don't get the importance of static typing... python, php and javascript all came out after typed languages were popular and are all used for large applications where typing would otherwise be very important.

Trends like this, and lack of awareness of even algebraic data types tells me that dependent typing is even more unlikely to become popular.

<comment><USER9> > Such programs that are formally correct eliminates the need for testing > almost completely and can cut such infrastructure down by possibly 95%

I think this is an absurdly high number. The difficulty of proving the kind of rich properties that integration and system-level testing can easily cover is mind-boggling, and also requires huge amounts of infrastructure that doesn't exist and is not feasible for a single team to build.

Think of an end-to-end test for a traffic generator application - you simulate a click in a web UI, you start a TCPdump on a network interface, wait for a a few minutes, and sample the capture for some expected packets.

How much dependently-typed infrastructure would you need to get even the small level of assurance that this test gives? How much of networking protocols and OS APIs would you have to formally specify to even start proving that your program adheres to them? How much of the DOM and JS APIs would you have to formally specify in order to prove that the button is going to be visible on the screen and that clicking it will produce the right HTTPS calls to the backend?

I am reasonably sure that dependent types will continue to get better and will help with developing certain kinds of abstract software components. But I believe that it would take decades before they can become a tool that could be used to prove a realistic large scale program to the point that you can throw away 95% of the testing done today.

<comment><USER8> Nah I'm going by the testing pyramid. Basically by 95% I mean all unit tests, which under the testing pyramid is the majority. If you follow different philosophies (which is valid and perfectly ok imo) and have more integration tests then unit tests then the 95% marker does not apply.

Integration tests or end to end tests or any test that touches IO or tests that measure performance are outside the purview of proofs. Proofs only verify pure logic.

Having a full formal model of an end to end system that can be verified with proofs is, I completely agree, really far away.

If 95% of your tests are unit tests then my statements apply.

</comment></comment></comment><comment><USER10> What I'd like to locate/implement would be:

\- an in-memory SQLite database with

\- a sufficiently generalized schema that could

\- ingest the static type information emitted by, say GCC, so that

\- one could easily inspect/compare metadata from any language.

I doubt that this idea is unique to me.

<comment><USER11> Sounds like Language Server: [https://langserver.org/](https://langserver.org/)

<comment><USER10> Same idea carried further to include data types and objects that actual programs in the languages use, not just the EBNF grammar constructs of the languages.

Unless I missed that in my quick glance at the link.

<comment><USER11> Yep, LSP does include semantic view of the code. That is anything you'd see at the end tools such as IDEs: types, members, functions, properties within context (e.g. this function is a member of this class).

</comment></comment></comment></comment><comment><USER12> What's the purpose of posting as a G-Doc instead of HTML? The visitors' google account info could potentially be collected.

<comment><USER13> Not really anymore. It's now anonymized by default.

<comment><USER14> Color me skeptical. Plus it breaks the "visited" styling on HN, and generally pisses me off for throwing me out of my browser.

<angry old man waves fist at cloud />

</comment></comment></comment><comment><USER15> I'd like to joke that we could replace the link with [0] and it would be a massive improvement. Seriously, though, these descriptions of type-theoretic programming as a solution to a problem, rather than a tower to be climbed, are increasingly obscurantist, hiding the meat of the correspondence behind analogies and narratives.

[0] [https://ncatlab.org/nlab/show/computational+trinitarianism](https://ncatlab.org/nlab/show/computational+trinitarianism)

<comment><USER16> > hiding the meat of the correspondence behind analogies and narratives.

Interesting. Could you elaborate a little?

<comment><USER15> Sure. Any time somebody says "Curry-Howard" and doesn't provide the table that I provided, they are handwaving. The table makes the correspondence precise.

<comment><USER16> Cheers. When you say "the correspondence behind analogies and narratives", which column is analogy and which is narrative? I hope I'm not being really dense or ignorant here, apologies if so.

<comment><USER15> The page I linked is relatively clear. I was complaining about the original article, which fails to make contact with the actual guts of formal type theory.

<comment><USER16> Right, I get that. But the words "analogy" and "narrative" don't appear in the page. I'm wondering what you mean by those words?

<comment><USER15> For fuck's sake.

> For instance, it's impossible to write an executable program in Java that > adds a string to a number.

Wrong [0] and misleading and not a reasonable summary of type-driven development. The article goes rapidly downhill from there. It tastes like an undergrad who has just learned about the very basics of things and is still trying to figure out how to put them all together.

> So it is possible to statically verify that a function always returns the > square of its input, it just needs a proof (aka its type).

This is not sufficiently convincing. What exactly was that type, and which language was it written in? The type "int -> int" is not at all enough. This sort of handwaving logic seems to come up constantly with folks new to type theory. And each time it comes up, it seems that a massive argument must happen [1] in which folks who actually understand type theory have to remind folks that no, type systems do not automatically save us.

Here are two analogies in the article. "I'm lying" is a reference to a famous paradox [2], and the barber story is a truncated part of an older set of stories told by Russell, Gardner, Smullyan, and others [3]. All fine and well. However, they then try to claim that types somehow fix the underlying paradoxes, but of course, they don't. This is because the underlying cause of the paradoxes is of course Gödel's first incompleteness, which works even in statically-typed environments [4]. Worse, the article author makes it sound like incompleteness is some barrier to be climbed over, when in fact it is a basic (if tough-to-prove) categorical property [5].

[0] [https://hackernoon.com/java-is- unsound-28c84cb2b3f](https://hackernoon.com/java-is-unsound-28c84cb2b3f)

[1] [https://lobste.rs/s/yyhu4w/real_problems_with_functional_lan...](https://lobste.rs/s/yyhu4w/real_problems_with_functional_languages#c_4pbkan)

[2] [https://en.wikipedia.org/wiki/Liar_paradox](https://en.wikipedia.org/wiki/Liar_paradox)

[3] [https://en.wikipedia.org/wiki/Barber_paradox](https://en.wikipedia.org/wiki/Barber_paradox)

[4] [http://r6.ca/Goedel/goedel1.html](http://r6.ca/Goedel/goedel1.html)

[5] [https://ncatlab.org/nlab/show/Lawvere%27s+fixed+point+theore...](https://ncatlab.org/nlab/show/Lawvere%27s+fixed+point+theorem)

<comment><USER16> ... I just realized that, when you wrote:

> hiding the meat of the correspondence _behind_ analogies and narratives.

I misread:

> hiding the meat of the correspondence _between_ analogies and narratives.

...and I thought you might have been pointing to some potentially very interesting deep connection or something.

Sorry for the noise.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> The webpage for AGDA seems to be [https://github.com/agda/agda](https://github.com/agda/agda) or [https://wiki.portal.chalmers.se/agda/pmwiki.php](https://wiki.portal.chalmers.se/agda/pmwiki.php), but not [https://www.agda.com.au/](https://www.agda.com.au/) (end of the paper).

<comment><AUTHOR> Thanks. Fixed the links.

</comment></comment><comment><USER18> Still think that dynamic language with dynamic type and messaging still have a future. Objective c, lisp and JavaScript have some of this. Not all will die out.

<comment><USER5> "Dynamic types" is a misnomer; these are runtime _tags_ in a system of "tagged" values endowed with a _single_ static type. Types apply statically to program expressions, not runtime values. "Messaging" similarly represents the input to a dispatch step-- usually one that introduces non-trivial pitfalls if you want to ensure that your code keeps making sense as it evolves (see "fragile base class" and the like).

Anyway, dependently-typed languages support these patterns _better_ than most other static languages do, since static types can trivially be reified as runtime-tagged data in such languages, while keeping the ordinary benefits of static typing for most of the code.

</comment></comment><comment><USER19> I don't think it's accurate to compare type systems and mathematics. When you write out a mathematical equation, you don't explicitly specify if the variable is a float or an integer or a set or a vector or a matrix as part of the equation, the reader will infer the type of each variable from the problem domain. So in fact, math is much more like dynamically typed languages.

>> We know types help us eliminate certain classes of errors from programs.

Yes and in my experience they often also introduce new kinds of errors, architectural errors (which are much worse). If you have a system which makes it easier for developers to pass around complex instances across multiple source files, they will use that feature and it will often lead to modules which have lower cohesion and tighter coupling which adds complexity and makes it harder to modify and maintain the logic in the long run. Rigid type systems also add complexity when integrating with third party modules which may use different type names for similar concepts.

The wisdom of dynamically typed languages is precisely that it is difficult to know what the type of each variable is so it forces you to follow the logic around (which is unpleasant but necessary). What is almost always overlooked is the human psychological effect; this unpleasantness involved in trying to keep a mental picture of the logic creates a strong incentive for developers to keep the logic as simple, modular/encapsulated as possible. This results in better software design/architecture overall.

I'm saying this based on decades of experience having gone back and forth between dynamically and statically typed languages. Programming is as much about human psychology as it is about logic. Dynamically typed languages force developers to be more disciplined and this mindset is extremely valuable.

Statically typed languages tend to put developers on auto-pilot. You get so caught up on types and catering to the compiler's warnings that you lose some common sense. Coding in a statically typed language feels a bit like having a boss who micromanages you and tells you every little detail that you need to implement. Coding in a dynamically typed language is more like having a boss which tells you the general picture of what is required and lets you figure out the details.

I think the mindset of self-reliance which comes with dynamically typed languages is very important when it comes to producing high quality code.

</comment><comment><USER20> Anyone know who wrote this?

<comment><USER21> I don't know, but I wouldn't be surprised if he did: [https://github.com/joelewis](https://github.com/joelewis)

</comment></comment><comment><USER22> I'm forever baffled by the complete inability of our industry to see time or care about seeing that our most precious resource is time.

One thing is true: if you're not proving correctness of your code -- formally or informally -- then you are living in entropy and at very high risk of inefficiently delivering value through software. Knowing how to call "correct" on code is paramount.

And also -- yes, static type systems allow for (partial) machine verification of these proofs.

The missing piece is the innate -- and immense -- cost in having to express these proofs formally in a machine-checkable way.

Static type enthusiasts typically downplay these costs but they are simply wrong. I am not talking about the cost of _learning_ how to code in a statically typed system--that should never be factored in. I am talking about the innate costs of formal verification (and strong static typing) that even the expert static typers pay. I have seen these guys work and they are delivering sub-optimally in time compared to the alternatives. Period.

I have been around the block with both static and dynamic typing systems and the latter by far optimizes for delivery throughput over time.

Formally proving correctness of your program has the upfront cost of formalizing the proof (to the degree required by the verification system) as well has having the effect of crystallizing your code in its current representation which makes it more difficult to (re-)factor for future uses.

Some of the (more reasonable) strong static type enthusiasts will concede that this kind of machine/type-proving is better done when the domain and code stabilizes. My hats off to these people for at least being honest about things.

However the next realization is that once code and domain stabilize the need/value for machine proving correctness (in typical business/data applications) drops substantially (for obvious reasons).

So the pragmatic value of strong type systems and formal verification is far lower than the proponents will have you believe. Of course we've known this truth forever but our industry forgets pretty quickly. Haskell and variants are on the rise in popularity; but make no mistake, if you are optimizing for overall delivery throughput over time -- even experts are swimming upstream with these languages.

Of course every time I point this out on HN I get downvoted -- but it kills me to think that a next generation of programmers are being misled down a path of formal purity with misrepresentative claims about the cost of using these tools in real business applications.

Just to dispel any idea that what I'm saying is philistinic, I am a mathematician/academic first, enjoy category theory, have written more than my share of academic proofs (including novel results), and think these tools are immensely fascinating.

But having been in industry now for 20+ years shipping web-scale and distributed data systems for business industries (what 90+% of us are doing, I imagine), where time is the most precious resource, I know with certainty that leaning on formal verification techniques (including strong static type systems) is an enormous tax compared to the alternative. That these tools work against fast-paced, iterative development.

It has also become evident to me that there is a vanguard of static type enthusiast who are not admitting (or perhaps do not understand) the relative cost of the pursuit. Who will point to a few null pointer errors (that, mind you, could be eliminated or reduced by other defensive coding techniques besides formal proofs) and use these to justify the herculean cost of their formal system.

If you're a junior or on the fence about static type systems - at least code in a weakly typed PL in which you can lean in one way or the other. If business outcome/throughput is what you value first and foremost, I guarantee you will gravitate more and more toward dynamic evaluation - especially as you realize the world of real business delivery produces constantly changing requirements and carrying out delivery in the face of purist formal modeling and proofs will be a substantial drag on what you can do for little relative benefit downtream.

<comment><USER23> I'm not addressing formal verification itself, but in the argument between dynamic languages and compiled type-checked languages, I haven't found the tradeoff as you describe.

I also have 20+ years in development and consulting, and I'm someone equally skilled in dynamic languages (particularly php) and compiled languages (mostly java, with scala and FP concepts mixed in).

My current long term project is something where I'm the sole person on the team capable of deeply understanding their two main sets of legacy code. Both have been in active development for around fifteen years. One is in php, and one is in java. Both have significant technical debt, with several efforts of "modernization" that have only touched parts of the codebases.

At this point, adding new features to the php codebase is harder. There are weirder runtime problems. The codebase is more difficult to understand. The side effects of any new features in the php codebase are more difficult to predict.

When developing features that have any hope of actually _succeeding_ and sticking around for a while, the truth is that area of code is going to be read, analyzed, and understood (or attempted to be understood) far more often than it will be written. So any initial benefit you get in writing speed is more than swallowed up over time in its difficulty to re-read, understand, and maintain.

After dealing with both approaches for several years, my opinion is pretty firmly set that the dynamic approach is best for prototyping, or for a quickly-written simple service that won't grow, or if you're perhaps a startup writing a demo and scrambling for your first rounds of funding.

But if you're looking at business features of any complexity, want to maintain them over a significant period of time, through a significantly changing number of eyeballs, and making a significant number of changes while leaving the codebase somewhat understandable... over the long run, the typed codebase will be easier and faster. I think the problem is that with typed systems, the costs are more explicit, but with dynamic systems, the costs are embedded in decisions like "That feature sounds too hard for that codebase, let's not do it (and thereby cede ground to competitors)."

<comment><USER22> I don't disagree with you about maintaining large unwieldy code bases being perhaps better in static type land.

Large unwieldy code bases have already ossified anyway so the productivity gain of dynamism is lost and you're simply swimming in complexity.

But my argument is that what got you the large unwieldy code base is a lack of skill set that no type system could protect you from.

With the right toolkit (which includes nominal static typing among many other tools) and expertise you are not being optimal by giving highest precedent to formal machine proof systems which is what strong static typing does.

<comment><USER5> Properly used, static typing actually enhances modularity and reduces unwanted coupling among software components. This means that a larger code base is far less likely to become practically "unwieldly" if static types have been consistently used in development. Even in exploratory programming where dynamic types may actually have some limited value, using them effectively requires a lot more "skill".

<comment><USER22> Thought experiment, in your mind what would better produce modularity — TDD or static type verification?

If you had to pick one.

<comment><USER24> Anecdata: in Python I used to (and still do to some extent) practice TDD very conscientiously because I felt it really helped me structure my programs well and get them "correct my construction". One of the reasons for moving to Haskell was that the type system has the same effect at a lower cost (once the barrier to entry of learning about the type system has been crossed).

</comment></comment></comment></comment></comment></comment><comment><USER25> Isn't there a Turing reduction that violates any guarantees?

        def square(x):
          maybe_terminate()
          x*x

</comment><comment><USER26> The thing is, the modern notion of what constitutes a type is 'class'. This stealthy switch from one to the other has made the concept of strong typing hard to understand and/or apply in practice, and with the addition of the idea of interfaces, late binding, etc. the problem of types in programming, stated in all its generality, became pretty much intractable.</comment>


Virtual Reality Takes Consciousness Research into Mystic Realms - <AUTHOR> http://sociable.co/technology/virtual-reality-consciousness/ <comment><USER2> VR is getting mystical with experiencing death before death, treating depression, time travel, and lucid dreaming.

What else can VR show us once the doors of perception have been cleansed?</comment>


PHP Built-in web server - <AUTHOR> http://php.net/manual/en/features.commandline.webserver.php <comment><USER2> Note that one of the main pushes for having this right in the core distribution was to improve our test framework. We can't rely on and end-user installed web server for "make test" since we have no control over the configuration and the current approach of faking GET/POST/Cookie data for the CGI version only goes so far. Having an actual server where we can test things like opcode caching where the first and second request to the same resource hit wildly different code paths is a big win. It is also helpful during debugging. The less moving parts the better when you are sitting in gdb or Valgrind trying to track down a problem.

For end users I think the most interesting feature is the ability to provide a router script that can wrap whatever frontend controller your framework is using. And some projects support it natively now. For example, in Symphony2 you download and untar it then just cd into the directory and start _php -S localhost:1234_ and off you go.

But please, don't ever use this as a replacement for Apache/nginx as a user- visible web server.

<comment><USER3> I don't understand the "make test" thing. If you're temporarily hosting pages for testing then doesn't that mean you have to also get something to pull those pages to validate them? If that's the case then why can't you just output stdout and validate the pages that way, with just some simple mechanism to pass post/cookie information as a parameter (much like how you would do it with wget).

<comment><USER4> > I don't understand the "make test" thing. If you're temporarily hosting > pages ...

That has nothing to do with user code or hosting pages. Most people install PHP using their package manager (ie "yum install php"). Some people and those that maintain those packages, need to compile PHP from source code (PHP is written in C). The guys who develop PHP wrote thousands of tests that make sure that the binary that is compiled works properly. Those are the tests being referenced.

<comment><USER5> Right, I think the poster you're replying to understands that. The question is that, given there's a command-line interpreter (php-cli), built as part of a normal build, which will execute PHP files and print the output, why do your tests need to go over HTTP at all?

<comment><USER4> > why do your tests need to go over HTTP at all?

Just off the top of my head, how would you check file_get_contents which can take a url as a parameter?

You can't just throw <http://www.google.com/> in there. You might be compiling on a machine that's not on the net, firewalled, etc.

It becomes useful for functionality that normally relies on an external http server to work.

The OP also mentions several more scenarios where it is useful and even necessary.

<comment><USER5> That's a slightly different scenario - you're exercising client protocol functionality. (Incidentally, you don't need a webserver for that, you just need a very stupid socket server that will return a file. Also, file_get_contents looks like it can access ftp/ssh/gopher URLs so if you need a webserver, you also need servers that speak those other protocols).

</comment></comment></comment></comment></comment></comment><comment><USER6> Man, this got so much flack from the PHP community that didn't see the power in having a built-in webserver. For some reason, people center on that it's supposed to replace Apache/nginx, which it's not.

Languages and frameworks aside, one of the nicest and most newbie friendly parts of Rails is that it's bundled with a webserver, so you can start playing around without having to setup any sort of dev environment.

Edit: I do agree that this should probably not be in the core php interpreter, though. Ideally, it would be a PHP library with a CLI utility, but with PHP's poor culture and adoption towards shared libraries ala composer/rubygems/npm, I think this is the best alternative.

<comment><USER7> Precisely. This will hopefully replace a lot of the "FTP it up to the server, see if it works" workflow I've seen in the PHP world.

<comment><USER8> To be honest: that was quite possibly the greatest part of learning PHP for me!

PHP was the first language I learned; the fact that I could deploy it to nearly _any_ shared host [of which there were a lot of freebies] allowed me to rapidly program and debug; which I find was crucial to my initial learning.

Hindsight being 20/20: of course I agree with you, now.

But I'm still not convinced that _young me_ would've been able to use the built in server. I certainly couldn't be bothered to setup Apache (et al) and a working PHP interpreter.

Rails is a bit different, since you learn about the built in webserver when going through their "hello, world" tutorial. If excellent tutorials surface for PHP, then perhaps I can see the "FTP-to-test" pattern being obsoleted.

To me: PHP's greatest asset was that A) I didn't have to setup _my own_ development environment, and B) there were so many [free] development environments already setup!

I'd learn to love setting up servers, but that came far later [in my chronology anyways].

tl;dr: FTP and common PHP setups actually removed a large barrier to entry for a young programmer. I think the "FTP-to-test" anti-pattern was probably one of the more useful ones in my toolkit when it came to my initial learning.

<comment><USER9> Wait, running the built-in server is one command (and no configuration), and it's quite reasonably claimed that Rails' equivalent built-in command is helping the adoption of Rails by people who are now in the position where you previously were.

It seems to me like it should be at least as easy to fire up the built-in web server as to learn FTP and sign up for some random shared hosting account, right? That is to say, isn't this even a lower barrier to entry than the FTP approach?

</comment></comment></comment></comment><comment><USER10> This is seriously so fantastic. In my case, the biggest barrier to me contributing to projects that use PHP is the pain of setting up Apache/nginx, making sure permissions are right on the directory for apache to serve it, setting up virtual hosts, etc.

This built-in web server has singlehandedly influenced me to actually look at using PHP for projects.

<comment><USER11> sudo apt-get install nginx php5-common php5-fpm is all you have to do :\

<comment><USER10> Haha, I knew someone would tell me "but it's easy to set up nginx and PHP!!!"

I really don't agree. "php -S localhost:8888" is much, much easier. Let's leave it at that.

</comment></comment></comment><comment><USER12> I used this last week to reverse engineer some PHP code supplied by a third party. Was very pleased how easy and non-invasive it was - just built PHP from source and ran the executable direct from the build tree. Swore at PHP much less than I would otherwise have done.

</comment><comment><USER13> You don't need a full server like apache or nginx to start developing in you home all you need is php

I like it is like in the rails/django world

<comment><USER14> "I like it is like in the ruby/python world"

<comment><USER15> I think in this instance, "ruby" is more accurate. they didn't say "it is an exclusive property of rails", just that Rails has it, which is true. It's more true than saying Ruby has it.

edit: removed completely presumptuous gender pronouns

</comment></comment></comment><comment><USER16> I can't remember where I read it, but I believe Rasmus stated that the original purpose of this was to simplify the PHP test cases. Since they couldn't assume that a user had a given web server installed, they had to use weird hacks to make PHP think it was running behind a web server and even then it couldn't test everything.

<comment><USER17> His reply on this thread <http://news.ycombinator.com/item?id=4502041>

<comment><USER16> Oops didn't see that he had already posted that.

</comment></comment></comment><comment><USER18> This is maybe my favorite new feature in PHP. In ruby I'm so used to just running shotgun locally and not having to install MAMP, XAMP, WAMP or any of those other things I used to have to deal with just to get a little web server working to develop against. Good job PHP.

</comment><comment><USER19> I had a go at a Rack/WSGI style PHP web server a while ago:

<http://getkelpie.com/>

.. it's using the mongrel http parser wrapped in a PHP extension, so it's pretty fast and reliable: <https://github.com/dhotson/httpparser-php>

I tried it at work and got pretty significant performance increase since it only has to initialize the framework at server startup instead of every request. We went from a baseline of 70ms to about 2ms per request.

</comment><comment><USER20> For those still using PHP 5.3, you can use <https://github.com/youngj/httpserver> (disclaimer: I wrote it) -- it's a standalone development HTTP server written in PHP that only depends on the php-cgi binary.

Even with PHP 5.4, I find it more useful for development than the built-in cli-server, since it gives me more flexibility to simulate the various directives in my nginx configuration files (e.g. gzip_static).

</comment><comment><USER21> Sometimes I feel like The Twelve-Factor App is basically a response to all the horrible things PHP makes you do. Now there's one less reason to hate PHP. <http://www.12factor.net/port-binding>

<comment><USER7> This isn't intended for production use.

PHP-FPM is, though, and it's been around for quite some time.

</comment></comment><comment><USER22> Wow, this is a big deal. Even though I don't work with PHP all that much anymore, I really wish I had something like this when I did.

</comment><comment><USER23> Well that could come in pretty handy.

</comment><comment><USER24> I can see how this can come in handy, but setting up a LAMP server on localhost is so easy nowadays that I can't help but think this is a little redundant. Sure you get a full-blown Apache install but honestly, calling that bloat is semantics on anything but the worst of developer machines. I wish they had spent the manpower working on core language features instead.

<comment><USER25> Core language features? Oh, you mean like all these guys? [http://nikic.github.com/2012/07/10/What-PHP-5-5-might- look-l...](http://nikic.github.com/2012/07/10/What-PHP-5-5-might-look- like.html)

<comment><USER24> I'm not saying things aren't progressing, all I'm saying is that on any project there's a limited amount of manpower, and how you allocate that manpower is important. Personally I think there are more pressing things to allocate manpower to in PHP than a built-in web server, when Apache is already so simple to configure for serving PHP.

Furthermore this kind of web server would only be useful for the most basic of projects. As soon as a person dips their toes into anything remotely complex, they're going to need their development server to mirror the production server as closely as possible, especially with things like php.ini and rewrites. So why not just set it up like that to begin with?

<comment><USER26> It is an open source project, I am guessing that one or more contributors decided they wanted the built in be web server.

There is nothing stopping others getting involved if there were other things they want to see in future PHP versions.</comment></comment></comment></comment>


Paper Airplane Designs - <AUTHOR> https://www.foldnfly.com/ <comment><USER3> Imagine my surprise when I'm reading down the HN list like I do every day and I stumble upon my own website. Thats a pretty cool feeling! Im happy to answer any questions people may have. This was my Angular learning project back when Angular just came out. I think Angular ended up being the wrong choice for this project, but it works and I learned Angular, so its all good.

<comment><USER4> Am I correct to assume all the designs are for US Letter paper?

(And not the A4 size common in the UK and elsewhere. [http://betweenborders.com/wordsmithing/a4-vs-us- letter/](http://betweenborders.com/wordsmithing/a4-vs-us-letter/))

I remember the frustration as kid getting a book of designs from the US and having none of them work quite right.

<comment><USER5> For the very same reason I wonder whether there might be a difference in taste between a metric recipe and an imperial one.

<comment><USER6> Fun story: when the Soviets tried to reverse-engineer captured B-29s bombers (into Tupolev Tu-4s) they had a lot of trouble because their production of sheet aluminium, rivets, etc. was done in metric sizes, whereas the B-29 used imperial-sized components, and thus extensive re-engineering was required to compensate the slight differences in thickness (and thus in weight and balance) of all components.

<comment><USER7> I wonder if this justifies the US adherence to the imperial standard - <USER2> it acts as a basic barrier to entry for other countries who use the "world" standard.

<comment><USER8> sort of like the use of analog comms on the Galactica right?

<comment><USER9> Not _quite_ the same thing, but since you mention Galactica and her non- networked systems, I believe watching this show should be required of anyone even tangentially considering work in an IoT project.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> In the 90's I went to a small middle school, the 8th grade class was 21 people. Once, the school had a contest in the indoor gym, we each designed paper planes and the one who flew it the farthest won a prize. We argued with teachers over an allowance for a little bit of tape, which some of us used just as nose weight. However, each kid was the one to "fly" his own plane, a big oversight.

Almost the last kid, when it was Sam's turn to "fly", he stepped up to the line, crumpled up his design very tightly into little ball, and hurled the paper mass as far as he could.

Strangely, I can't remember what happened or who won! But his genius observation of the rules stuck with me.

The plane I designed is not among these designs, but a totally square design that I had learned earlier from an origami book. This is the closest one: [https://www.foldnfly.com/17.html#The-Square- Plane](https://www.foldnfly.com/17.html#The-Square-Plane)

<comment><USER11> Similar story from a university aero course that ended with a paper airplane competition.

There were some remarkable paper airplanes, making amazing flights, all sorts of research and time went into developing the ideal model.

One guy comes up representing his team and he gets out a piece of rolling paper and a lighter. Tears the tiniest portion off the rolling paper, sets it alight, and then follows it with his finger through the air as it took forever to land on the ground.

I believe the incident led to a rule change for later years.

<comment><USER12> > follows it with his finger through the air as it took forever to land on the > ground.

Sounds interesting, but I'm confused. So is he walking in front of it, and the flame is pulled toward his finger? Did it travel the farthest that way?

<comment><USER11> No, apologies. He burnt the paper and then picked one of the ashes as his "plane"

His finger never touched the plane after it took "flight" just pointed to it from the side so that everyone could follow the "flight path."

Some classmates were upset, I was just impressed.

<comment><USER13> Ah, I'm guessing time aloft was the metric?

<comment><USER11> "Time of flight" only the definition of flight was something like unpowered and untethered off the ground. So floating slowly to the ground becomes "flight" by the definition of the rules.

<comment><USER14> Wouldn't the burning of the paper technically make it powered?

<comment><USER11> No, the burning of the paper removed a great of mass from the paper turning to to a brittle paper ash. After the fire was out is when the timer started, since the paper ash was so much lighter but the same volume its buoyancy in air was drastically increased causing it to "float."

The up draft from the flame wasn't utilized to power the flight, the fire was only used transform the original rolling paper into a "plane" by mass reduction through combustion.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Since this is going to be a great pass time for geekids, wanted to throw in a few resources for completeness:

Windtunnel to test: [https://www.instructables.com/id/Paper-aeroplane-wind- tunnel...](https://www.instructables.com/id/Paper-aeroplane-wind-tunnel/)

Project form: [https://www.sciencebuddies.org/science-fair- projects/project...](https://www.sciencebuddies.org/science-fair- projects/project-ideas/Aero_p046/aerodynamics-hydrodynamics/how-far-will- paper-planes-fly)

Another page with slightly different features: [https://www.origamiway.com/paper- airplanes.shtml](https://www.origamiway.com/paper-airplanes.shtml)

<comment><USER16> > Since this is going to be a great pass time

I thought this was a fantastic eggcorn[1], until I realized that it is the actualy origin of the word 'pastime'. So, it sort of is, but isn't at the same time.

[1][https://en.wikipedia.org/wiki/Eggcorn](https://en.wikipedia.org/wiki/Eggcorn)

<comment><USER15> Thanks for introducing me to a new linguistic trivia!

</comment></comment></comment><comment><USER17> Question: there is a "rule" separating "no cuts" from others, let's call it a purity class. Is "no arbitrary folds" also an established purity class? When I was a kid with too much paper at my disposal, arbitrary folds felt like chatting. Arbitrary folds would be any fold not defined by either a side or existing fold aligning with another side or existing fold or by a corner aligning with another corner. Many intermediate folds would be done just as guidelines for layer folds, and four the structural effect they would have after getting undone. A bit like the "only lines and circles, no measurements" rule in geometry.

<comment><USER18> Going to be tricky since the leading edge of the wing where it meets the nose is often 'arbitrary' in this sense.

<comment><USER19> Paper airplanes are generally symmetrical, which means you can begin by folding the paper in half and using that fold to determine where the nose is. Unless you mean something else?

<comment><USER18> I'm talking about the leading edge of the wings, where they meet the fuselage. How far up that is from the tip of the nose is often not based on any existing edge or fold.

<comment><USER17> The fold that separates the "fuselage" from the wing? Not the leading edge (except in one point), but you are right, that is the one where many otherwise non-arbitrary planes make an exception. My favorite designs, front heavy with a decoratively complex leading edge would usually have plenty of potential guidepoints for the fuselage fold though. Good times, bringing up those memories makes me wonder when exactly I stopped.

<comment><USER18> Yes, that fold, but specifically that leading point of it. Often the back can have a reference point, like having the edge of the wing meet the bottom rear corner of the fuselage. But yeah, the fold in general is often more arbitrary. But not really; you would try to fold a plane as consistently as possible, so something like 'begin the fold 1/8" from the tip of the nose' isn't arbitrary at all.

Similarly, you often don't want to fold right to a crease, as it can cause bunching. It's often a better idea to leave a mm or so of extra space for inward folds. Doesn't make the design less pure or anything though.

</comment></comment></comment></comment></comment></comment><comment><USER20> I would like to promote what I think is the ultimate source of this kind:

The Greatest Paper Airplanes[1], a virtual interactive encyclopedia for Windows 3.1

Of course, you can use it in the browser these days[1].

It goes through basics and history of flight, basics of paper folding, and gives you dozens of interactive, animated, step-by-step designs.

Loved it as a kid, and was thrilled to see it preserved online.

[1][https://classicreload.com/win3x-greatest-paper- airplanes.htm...](https://classicreload.com/win3x-greatest-paper- airplanes.html)

<comment><USER21> thanks for sharing this - the animated step-by-step is very nice and especially useful if you're following any kind of complicated design

</comment></comment><comment><USER22> Hi! There's a paper airplane I've made which I learned out of a book a while back - the book called it either a "condor" or "albatross", I forget which, but searching for either of those names turns up different designs. It's an excellent glider, and one of the few designs I know that start with the paper in landscape orientation. If you're interested, here's how to fold it:

\- With the paper in landscape orientation, fold the top corners to meet in the middle.

\- Fold the top corner [just created] down to the point where those two corners meet.

\- Fold the two new obtuse corners on the top to meet in the middle. Tape into place.

\- Fold in half left-to-right, so that the taped corners are on the outside of the fold.

\- Fold the edges back down to the centerline.

\- Unfold, and smooth out to give it the profile of an upside-down flattened W. The flatter, the better it will glide, but if it's too flat it will spin.

Launch by holding the back, as it has no vertical surface to grip on the bottom.

<comment><USER23> That book was "the gliding flight"

</comment></comment><comment><USER24> I actually "invented" another paper airplane design called the Nakamura Hammer (because it combines the designs of the nakamura lock and the hammer). I made it to the frontpage of Reddit, so that were my 15 minutes of fame. Here's the tutorial

[https://imgur.com/gallery/b2Q8X](https://imgur.com/gallery/b2Q8X)

It flies really really well inside.

</comment><comment><USER25> In high school we used to receive printed notices aka 'circulars' from administration to give our parents (do they still do this?) -- our classroom window overlooked a cabin used for temporary classes with a corrugated asbestos roof. After promptly turning my circular into a plane and flying it out the window, exclaiming "hey i got to the 5th row on the cabin roof!"

Thus began the hottest aerodynamics contest in my academic life, we experimented with so many designs, tried all kinds of crazy modifications.

The interesting thing was, our classroom window was an entire story higher than the cabin roof -- the usual "paper plane contest hack" of rolling a paper ball and chucking it as hard as you can was not very good compared to a functional aerodynamic design with some lift.

The "contest" ended when a week later someone reported our antics and the school was aghast to find 40-odd paper planes roosting on the portacabin roof and our entire class was given some stern warnings but luckily noone sold me out as the instigator.

</comment><comment><USER18> From one of the example videos on the site, I got suggested this fun video where the maker of the world record distance paper airplane a few years ago shows off and explains a bunch of different designs: [https://www.youtube.com/watch?v=2n4xq0DnbHI](https://www.youtube.com/watch?v=2n4xq0DnbHI)

The record flight is shown at the beginning, with more info on the plane at 13:55, but the whole thing is a fun watch.

</comment><comment><USER26> Fantastic! I love the design of this site: the way it greets you immediately with big thumbnails of actual paper airplanes.

I was flying some "Basic Dart" and "Square" planes (those are the only two designs I know by heart) with my kids the other day and I was thinking, "I bet there are a bunch of great designs online somewhere..." And here we are!

<comment><USER27> Agree! That is what I've liked more about the post. The design is just great. Very good looking, simple, and clean. The planes are nice too though :)

</comment></comment><comment><USER28> I grew up reading "The Ultimate Paper Airplane" by Richard Kline: [https://www.amazon.com/Ultimate-Paper-Airplane-Step- Instruct...](https://www.amazon.com/Ultimate-Paper-Airplane-Step- Instructions/dp/0671555510)

I didn't have the right tools or expertise to build most of his planes (most notably rubber cement), but I do wonder how these planes stack up against currently popular paper airplane models.

He talks a lot about his invention (and patenting) of the Kline-Fogleman airfoil, which creates a vortex that influences the laminar flow and increases stall resistance.

<comment><USER29> I have a vivid memory of how excited I was by the 60-minutes episode about this paper airplane, and I grabbed a copy of this book when I saw it in my college bookstore.

Making the various models was a lot of fun, although I don't think I ever obtained the specific weight of paper they mention in the book. That's still on my bucket list.

</comment></comment><comment><USER30> I wonder if anyone has attempted to use machine learning to try and build a better paper airplane. I feel like that would be super interesting.

<comment><USER31> If you give me a realistic physics environment to train an agent in I'll do it for you.

<comment><USER32> Hmmmmmm. I wonder if X-Plane would be capable of simulating that... they basically do an FEA model of flight, although I'm not sure if it would scale down appropriately.

<comment><USER33> Flight physics don't scale down (or up) well. It's the predominant reason small airplane and quad models have enormously unscalable performance characteristics and abilities.

Making it bigger doesn't "just work"... same for the inverse.

<comment><USER34> I think the physics mostly DO scale down, it's air density and gravity that don't.

</comment></comment></comment></comment></comment><comment><USER35> Very interesting, I wonder how regional these are.

For example I grew up with this one as the "basic" / default:

[https://www.origamiway.com/plane-nakamura- lock.shtml](https://www.origamiway.com/plane-nakamura-lock.shtml)

Notice how it has a high air time and distance. I used to launch them them from my 8th story apartment in the city. On a right day, some would take off and would be carried by the wind to where I lose sight of them.

<comment><USER36> Here in India, I grew up with the Basic Dart (from the OP site) as the default paperplane for kids to do. But the one you linked to was also pretty common, usually made by the "cool" uncles entertaining kids at parties.

</comment></comment><comment><USER37> This is slightly tangential to paper airplane folding, but I strongly recommend Duncan Birmingham's YouTube channel ("The Pop-up Channel"): [https://www.youtube.com/channel/UCx2M2bGHtXBszG6tuR_NIbQ](https://www.youtube.com/channel/UCx2M2bGHtXBszG6tuR_NIbQ)

Pop-up books are works of art, but they rely on a vocabulary of a few dozen mechanisms, each of which operates in relation to an opening fold between two pieces of paper or card. Birmingham is a great, systematic expositor of the analytical prerequisites for the wildly creative stuff you might come across in a bookshop these days (there's a boom in spectacular pop-up books, see [http://www.bestpopupbooks.com/](http://www.bestpopupbooks.com/))

I should add: pop-up books are still assembled by hand (in the Far East), not by robot; so if they seem inexpensive, there's a bit of a story there which might not flatter the book trade. A microcosm of globalization.

</comment><comment><USER38> World record plane: [https://www.wired.com/story/learn-how-to-fold-a-world- record...](https://www.wired.com/story/learn-how-to-fold-a-world-record- setting-paper-airplane/)

Throw planes around the world: [https://paperplanes.world](https://paperplanes.world)

</comment><comment><USER39> When I used to teach AP Computer Science, I'd have my students make paper airplanes on the first day.

I'd have them write down the instructions to make their airplanes. Then I'd follow their instructions in the strictest, most literal sense possible, resulting in some lopsided airplanes.

It was a great beginning lesson in algorithms.

</comment><comment><USER40> Love this one!

Over the last two years I made a lot of paper aeroplanes for my nephew, after that I started to build my own glider planes and now we're into RC planes.

If you want to get a bit more of a hobby I highly recommend Flitetest community, they made awesome things, and is a great resource to get kids into the hobby.

[https://www.flitetest.com/](https://www.flitetest.com/)

RC-Plane from cardboard pizza box [https://www.flitetest.com/articles/flying- wing-made-from-a-c...](https://www.flitetest.com/articles/flying-wing-made- from-a-cardboard-pizza-box)

Flite test Steam [https://www.ftstem.com/](https://www.ftstem.com/)

<comment><USER41> I've had a similar progression. Have you gotten into discus launch gliders?

<comment><USER40> Yep, also, we are starting to think to build a shuttle they are easy to build :-)

</comment></comment></comment><comment><USER42> what ever happened to the tube? [https://www.instructables.com/id/Tubular- paper-airplane/](https://www.instructables.com/id/Tubular-paper-airplane/)

<comment><USER43> I had success with that design as a kid. It was called "the bishop's hat" in the book I had.

</comment></comment><comment><USER44> I tried for the longest paper airplane flight in history - from the top of the Space Needle in Seattle. Unfortunately, the plane hit the anti-suicide mesh, lost all momentum, and from there went straight down. I took the elevator down, walked to the plane, picked it up, and threw it in the trash can. (Don't litter.)

</comment><comment><USER45> I got the German version of this from the library when I was a kid:

[https://www.worldcat.org/title/great-international-paper- air...](https://www.worldcat.org/title/great-international-paper-airplane- book/oclc/41144308/editions?referer=di&editionsView=true)

It has designs from this competition:

[https://www.youtube.com/watch?v=U8gWE8wHhkE](https://www.youtube.com/watch?v=U8gWE8wHhkE)

There is also a second book:

[http://www.worldcat.org/search?q=The+Paper+airplane+book+the...](http://www.worldcat.org/search?q=The+Paper+airplane+book+the+official+book+of+the+Second+Great+International+Paper+Airplane+Contest&qt=results_page)

</comment><comment><USER46> Suprisingly enough, this collection doesn't seem have the design most common & popular in Russia, roughly this: [https://www.youtube.com/watch?v=mrsxMqvHXkw](https://www.youtube.com/watch?v=mrsxMqvHXkw).

<comment><USER47> That's the de-facto design I used as a kid growing up in the US.

<comment><USER48> Also my design as a kid, turns out I'm Russian??

<comment><USER46> I never claimed this design to be Russian ;) I only said it is very popular there.

</comment></comment></comment></comment><comment><USER49> I've made a variant of the "tailed plane" for years--its one of my favorites. What's interesting to note on that one, I don't generally throw it normally like other paper airplanes. Instead, I place the front of the plane facing my hand, with my index finger and ring finger on either side of the nose, and my middle finder inside the crease of the nose. Then you just do an overhand fling, loosening your fingers about 2/3rds of the way through he arc. All the folds at the nose, makes the nose heavy, so it turns around and flies nicely.

</comment><comment><USER50> This is one I grew up with (as the dart & square plane alternative). If you fold the winglets as the instructions, you end up with an aerobatic plane. If you instead just gently bend the plane in half along the center line (so it looks somewhat arc-shaped), you get a pretty reliable glider.

[https://www.instructables.com/id/How-to-make-an-aerobatic- pa...](https://www.instructables.com/id/How-to-make-an-aerobatic-paper- airplane/)

<comment><USER51> As a kid, I only knew the basic design and the square. I almost always used the square, which I learned with two differences from the description on the website: I folded up the outer ~0.5-1cm of the wings as "winglets" (which seemed to help stability) and folded in a triangle of varying size in the back of the fuselage for trim instead of cutting ailerons into the wings.

On a windy day in the vortices behind trees at my elementary school bus stop, I had such a square glide for what felt like at least half a minute (unreliable narrator obviously) after launching to maybe 3-4 meters. That lucky random walk wouldn't have worked without the low sink rate of a good square.

</comment></comment><comment><USER52> When I was a kid a paper plane was just a fun DIY toy. Now I am almost 40 and I find paper planes have a lot of existential meaning. And they are a fun DIY toy.

</comment><comment><USER53> One trick I always used but never understood why it worked:

When you add a crease to the paper airplane, (say, folding a square corner in on itself at the nose or the tail), it weighs down that part of the plane. So if your plane is pointing up too much, you add a crease in the nose and it flies more level.

But why should adding a crease increase the weight of one section of a plane? You're not adding any more paper.

<comment><USER54> You are moving the center of mass of the paper. Imagine balancing a pipe cleaner on your finger, should be pretty easy, right? Now add a bend and see that you have to reposition the pipe cleaner on your finger

<comment><USER53> I'm moving the weight more toward the center of the plane, but the plane "appears" heavier in the front. This is the opposite effect, no?

</comment></comment></comment><comment><USER55> When I was a child, I had a book with many of these designs. I tested them all from the top of a nearby building's fire escape. My goal was always a long, slow, stable flight and I got the best results with the Square Plane and the Bird. These planes were able to glide all the way across the parking lot (about 120ft estimated using Google Earth imagery.)

<comment><USER56> I always aimed for (but rarely achieved) a long, slow, stable flight, never had anywhere high enough to test my better attempts. What I'd have given for an empty stadium to test in

[https://youtu.be/BV6EP9bBbac](https://youtu.be/BV6EP9bBbac)

</comment></comment><comment><USER57> I think Yasuaki Ninomiya, the retired Japanese engineer, could add some more expert designs based on his paper plane research.

[http://articles.latimes.com/1990-03-16/news/vw-465_1_paper-a...](http://articles.latimes.com/1990-03-16/news/vw-465_1_paper- airplane)

</comment><comment><USER13> I won my last company's paper airplane contest by making a dart with double thickness. I was disqualified, however, which seemed hella lame. My throwing strategy was to aim about 30 degrees upward and throw in a smooth motion, which seemed like the way to prevent it from going haywire.

</comment><comment><USER58> It would be fun to have a small electronics package that could turn some of these designs into RC flyers.

<comment><USER59> [https://www.poweruptoys.com/](https://www.poweruptoys.com/)

<comment><USER60> Wow, awesome. Have you tried it? My nephew would love this.

<comment><USER61> I tried I believe the v1 (just a dumb motor) and the v2 (with a rudder). Both were neat but the v2 was iPhone controlled and very, very cool. You need a LOT of room and it takes some time to get the hang of the throttle, which is your only real up-and-down control.

</comment></comment></comment></comment><comment><USER62> I found this design many many years ago, and it's always been my favourite for aesthetics: [http://www.members.tripod.com/~Yesitsme2/paperdc3.html](http://www.members.tripod.com/~Yesitsme2/paperdc3.html)

</comment><comment><USER63> The best one I've tried is called: paperang.

You can find instructions by searching: "paperang paper airplane".

There is a TED talk about it: [https://www.youtube.com/watch?v=VS7zcI_5Mp0](https://www.youtube.com/watch?v=VS7zcI_5Mp0)

</comment><comment><USER64> In childhood we knew one type of paper planes ([http://korki.lol/kak-sdelat- bumazhnyiy-samoletik/](http://korki.lol/kak-sdelat-bumazhnyiy-samoletik/)) and it looks like it is not here.

</comment><comment><USER65> I remember reading about some twins who made airplanes that would just sort of fly around on the thermal currents generated by their bodies. Never could figure out how that works but I have seen ones where you can fan the plane with a big cardboard.

</comment><comment><USER66> There was a windows "app" called The Greatest Paper Airplanes. Anyone remember that?

<comment><USER67> Internet Archive has the shareware version.

[https://archive.org/details/PAPERAIR](https://archive.org/details/PAPERAIR)

</comment></comment><comment><USER68> When I was a child I had a book that listed quite a few of these. It was so popular with my classmates in kindergarten that the school ended up banning paper airplanes except on "Paper Airplane Fridays."

<comment><USER69> I wonder how many engineers society lost because they banned that.

</comment></comment><comment><USER70> A feel-good movie to watch with the kids : Paper Planes - [https://www.imdb.com/title/tt3328716/](https://www.imdb.com/title/tt3328716/)

</comment><comment><USER71> I hope kids are still making paper airplanes and getting off their phones occasionally. Some novel designs here for me. Looking at these, I think I have been making my elevators too large all these years.

</comment><comment><USER72> I sure could use this 25 years ago to impress the whole school... However, I hardly can see how some of them get to fly straight, but I think that it's a question of trying it out myself.

</comment><comment><USER73> This is wonderful. Long ago MS Publisher had templates that allowed you to build paper airplanes. I remember discovering this as a kid in elementary school with my friends.

</comment><comment><USER74> Great site, going to try and interest my kids, but - no videos of the planes actually flying? I want to know what "acrobatic" actually means.

</comment><comment><USER75> What's the easiest one that does reliable loops?

<comment><USER76> I remember flying successful loops with a Barnaby back in my childhood; sadly, it looks like his book (How To Make and Fly Paper Airplanes, Ralph S. Barnaby) may be out of print.

I'm sure there are many newer books and designs these days, but that was the one I knew and loved.

</comment></comment><comment><USER77> The one I fold since 3rd grade is missing. The world champion in distance is missing, too.

</comment><comment><USER78> Hah, I can see at least one missing. But definitely going to go through this with my kids.

</comment><comment><USER79> As an owner of a considerable collection of books on paper planes I approve this website.

</comment><comment><USER80> Feats of engineering performed with just a sheet of paper. Amazing!

</comment><comment><USER81> Try to not be wasteful and don't use blank paper.

</comment><comment><USER31> 1-1-1-1-1-1-1-1-2

<comment><USER82> Those (apparently) are the input choices of the options on the upper left. The values update when you change the selections. Creative I guess.

<comment><USER83> It is a bit nicer looking than ?option_a=1&option_b=2&option_c=3 etc

<comment><USER84> I wish we can design the web better. Maybe a human readable breadcrumb instead of reply?id=18250367&goto=item%3Fid%3D18249755%2318250367

</comment></comment></comment></comment><comment><USER85> they've gone to the trouble of making video instructions for each plane but they don't show it flying? what the

</comment><comment><USER86> This is fantabulous! Thanks for sharing

</comment><comment><USER87> I see this website everywhere I go lol

</comment><comment> looper-life Was never fond of arts and crafts at school, but when it came to building something outta paper, here I was, all the time paper airplanes. I really love flying in general, so this was my escape into an imaginary world! Thanks for this article in input! Kudos!</comment>


Tips for Succeeding in a CS. PhD - <AUTHOR> https://sybrandt.com/posts/2020_03_30_tips_phd_cs/ <comment><USER2> Very insightful article! I like how you retrospectively analyze advice you were given. Maybe I will do a meta retrospective analysis in a few years :)</comment>


Sense.io exits - <AUTHOR> http://blog.sense.io/sense-joins-cloudera/ <comment><AUTHOR> After I made a popular post on Hacker News last year about funding for SageMath, the cofounder Tristan of the VC-backed company [https://sense.io/](https://sense.io/) kindly talked with me via video chat about his experiences with funding that company (thanks Tristan!). I asked him about open source, since SageMath is completely open source. It seemed like there was just no possible way at that point (last year) that they could even consider open sourcing anything in sense.io due to the funding strings that were attached. And it makes sense given the motivations of VC, which is to maximize the resale value of a company, which is largely based on what the company owns, which is partly their IP.

Also, previous discussion on Hacker News of Sense.io: [https://news.ycombinator.com/item?id=9226717](https://news.ycombinator.com/item?id=9226717)</comment>


Who Controls Diners' Data? OpenTable Moves to Assert Control - <AUTHOR> https://www.wsj.com/articles/who-controls-diners-data-opentable-moves-to-assert-control-11552644121 <comment><USER2> Let me just start by saying I am entirely on the restaurant's side in this, and believe that this just another attempt at vendor lock-in from OpenTable. Restaurants have been fighting for customer control with OT for a long time, and at the end of the day, I'm fine with the restaurant, who actually see me in person, talk to me, and serve me the food, keeping notes on me to improve service. OT, less so. I'm not particularly personally concerned about privacy in this space, but it seems much better to have this data split up in the hands of the people who actually see me in person, rather than the faceless tool trying to aggregate my behavior.

To add some color to this, I recently was shown my customer notes by the GM at a medium-high end Michelin starred restaurant where I've been a regular for a long time. There's some basic notes from the early days about the name of my partner I was dining with, and food allergies and preferences. There's also a long, long list over several years of every extra dish that was sent out (I generally get 2-3 extra courses at this place), with the goal of not duplicating those courses. The notes have tailed off for the past few years because, probably because everybody knows me and has chatted with me at this point, so they know they can just ask me for whatever, and that I'm a pretty easy customer.

So like I said, I'm comfortable with this level of information in the hands of the restaurant. Pretty much everyone I've talked to in the industry is interested in this information strictly for the purposes of better service - nobody has grandiose plans of ever using this data outside of their own restaurant. OT provides a nice service in standardizing and simplifying the reservation process, but I'm inclined to think this is an power grab to try to force restaurants to stay within their ecosystem - and frankly, at the end of the day, I don't much care if OT lives or dies, but I do care about my local restaurants.

<comment><USER3> I couldn't agree more! When I see that companies like GrubHub and their ilk have menus for restaurants that do delivery, I always look up what I want on their menu, then call the company directly and place the order over the phone. It takes about 30 seconds longer than doing it with the web interface and I can tell them things like, "extra this, leave off that." I also know that the tip is actually going to the driver if I give it in cash. These middlemen can take a hike for all I care.

</comment></comment><comment><USER4> I've been following this somewhat because I learned about Tock, a Chicago startup founded by one of the Co-Founders/Owners of the Alinea restaurant. [1]

Their founder Nick Kokonas is quite interesting and seems to have a bit of an ongoing fight with OpenTable, Tock even built a tool where restaurants can analyze if they're paying too much for OpenTable's services [2].

If it interests you, check out his interview on Tim Ferris' podcast, it's well worth the listen. [3]

[1] [https://www.exploretock.com/join/](https://www.exploretock.com/join/) [2] [https://medium.com/tock/weve-built-a-website-to-check-if- you...](https://medium.com/tock/weve-built-a-website-to-check-if-you-are- overpaying-for-opentable-there-s-a-40-chance-you-are-b5fe1c8c81aa) [3] [https://tim.blog/2018/10/18/nick-kokonas/](https://tim.blog/2018/10/18/nick- kokonas/)

<comment><USER5> I hate Tock, and my wife and I will not eat at any restaurant that requires that we use them. Eating out is not just about acquiring food. It's a social ritual, and paying for the meal at the end is an essential part of that ritual, the culmination of mutual trust between a diner and a restaurateur. Tock's pay-up-front business model destroys that trust. The not-so-subtle message to the customer is, "We don't trust you to pay." But that knife cuts both ways: if you get my money up front, why should I trust you not to cut corners on the meal that you provide?

I get that restaurants have to protect themselves against no-shows, and I have no problem handing over a credit card number so that they can charge a no-show fee. But paying the entire cost of the meal up front is a line that I won't cross. There are too many excellent alternatives out there still doing business the old fashioned way, thank God.

<comment><USER6> Ticketing systems like Tock are speaking to that mutual trust. Reservations are another form of mutual trust in the restaurant interaction. You're making a promise to show up and they're promising to hold a table for you. But that's a very uneven trust. You can bail with no consequence to you, while the restaurant gets screwed. I see no problem in leveling the playing field.

Besides restaurants are the outlier. Most experience-based services have a pay-up-front model: concerts, sports games, transportation, conferences, movies, etc. The reason restaurants generally don't is because the cost isn't usually predictable up front for each person. For fine prix fixe dining, it is.

<comment><USER5> > But that's a very uneven trust. You can bail with no consequence to you, > while the restaurant gets screwed.

Yes, that's true.

> I see no problem in leveling the playing field.

Neither do I. That's why I wrote:

"I get that restaurants have to protect themselves against no-shows, and I have no problem handing over a credit card number so that they can charge a no-show fee."

You are the second person I've had to point this out to. Good grief, doesn't anyone actually read the comments they are responding to (or downvoting)?

<comment><USER6> People are calling out that your argument is pointing to the wrong step in the trust interplay. A ticketing system is not at all about a restaurant not trusting you to pay at the end of the meal and 100% about guaranteeing that you'll show up in the first place.

As you say, you're fine with restaurants addressing the reservation trust imbalance, but you apparently don't like the way a ticketing system accomplishes that. Why? Because you don't like the way it feels as an experience?

<comment><USER5> > Why? Because you don't like the way it feels as an experience?

Yes. Exactly.

Imagine if you took the menu of the French Laundry and served it in a McDonalds. The exact same food. Would you still pay $300 a plate?

<comment><USER6> If the ticketing system significantly detracts from the experience for you, then you shouldn't eat at those restaurants. That makes sense. But if you're arguing that restaurants that implement a ticketing system lead to a decline in quality or actual dining experience, then you'll have to provide some evidence.

I disagree that restaurants that use a ticketing system lose their incentive to deliver the best experience they can. These aren't one-off encounters. Repeat business, reputation, reviews, and word of mouth are all based on the actual experience. If the food or atmosphere is bad, then a fine dining place won't last, regardless of the payment dynamics they have.

<comment><USER5> > if you're arguing that restaurants that implement a ticketing system lead to > a decline in quality or actual dining experience, then you'll have to > provide some evidence.

I am not saying that this has happened, only that the pay-in-full-in-advance model removes one of the incentives that keeps it from happening. It may be that the removal of this incentive won't actually change anything, I don't know.

> These aren't one-off encounters

In the case of high-end restaurants, they often are. Not very many people can afford to be regulars at the French Laundry.

> If the food or atmosphere is bad, then a fine dining place won't last,

Maybe. But at the extreme high end, a restaurant can let things slide and coast on its reputation for a pretty long time.

<comment><USER7> So what happens in the hypothetical that the food sucks and the bill for $300 comes to you. Do you just not pay?

You are implicitly believing in their reputation by selecting the fine dining establishment. I don't really do fine dining so excuse me if this is ignorant, but it seems to me you don't really have recourse after the fact.

Problem is that there are millions of potential customers all who may or may not be flakes. When business could be make or break by one reservation backing out, they have much more to lose way more often than you having an awful experience at a reputable establishment. Tock makes sense in this scenario but you seem like you're being completely unempathetic to the economics of the situation.

<comment><USER5> > So what happens in the hypothetical that the food sucks and the bill for > $300 comes to you. Do you just not pay?

The one time this actually happened to me we walked out before we actually got any food. But yes, we didn't pay (obviously). If we'd paid ahead it would have been a real problem.

> Problem is that there are millions of potential customers all who may or may > not be flakes.

Yes, I understand that, and I am not unsympathetic to the restaurant's need to mitigate this risk somehow. But fobbing 100% of the risk back onto the customer is not the right answer IMHO, and any restaurant that does this is not going to get my business. There are lots of other possibilities (50% up front, no-show fee, reputation tracking) that I would be happy to sign up for, but not that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> OpenTable says this is about customer privacy, but...

> [OpenTable] will block restaurants from giving competitors access to diner > data acquired through OpenTable unless they pay new fees

Ah. In any case, not sure why OpenTable believes they own this information. If I make a reservation at a restaurant, particularly if I follow through and actually eat there, I fully expect the restaurant to own the knowledge about that reservation.

<comment><USER9> > _not sure why OpenTable believes they own this information._

Probably within the terms and conditions that no one reads.

</comment></comment><comment><USER9> How about _I_ control _my_ data and _my_ preferences.

My meal is a one time transaction where you provide food in exchange for my money.

<comment><USER10> Easy enough: call the restaurant yourself then.

When you use a service like Opentable, it's hard to claim you thought it was a "one time transaction" that would be forgotten about when it shows your reservation history to you every time you log in.

<comment><USER9> > _Easy enough: call the restaurant yourself then._

Except many now use a service provider to manager their reservations. Once they have your phone number (to confirm) it's no longer a one time transaction.

<comment><USER11> You can state you don't want to give them your number when making a reservation. Of if you happen to find someone persistent about it and you really want to continue to give them your business just use a fake number

I've never had a restaurant actually call to confirm I was coming.

<comment><USER12> It's very common for restaurants to text to confirm these days.

<comment><USER9> So not only do you need a phone number, it must be a mobile phone ?

<comment><USER12> I'm talking about after having made a reservation through an app like OpenTable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Outline link to avoid paywall [https://outline.com/fMSNSn](https://outline.com/fMSNSn)

In this case it appears open table is limiting data access to third parties (I'm surprised this wasn't already in place).

I'm not sure what data OpenTable has or what they are now requesting restaurants pay to share.

<comment><USER14> Someone that works in the industry probably knows better, but OpenTable has your full history of your dining experiences booked through them. What restaurants you frequent, how often, what time you go, how large your party was, how often you failed to show up.

I believe when you booked a reservation the restaurant got to see all of this.

</comment></comment><comment><USER15> I previously worked at an employer who dealt with restaurant bookings. I'm not going to mention who they are, but it's not OpenTable.

One of the key things I built while there was around data importing. The burden of getting the data to us was mostly on the customer, but some customers had a seriously hard time moving away so we had to build custom tools specifically for some competitors.

One product would only let you download encrypted backups, but they refused to give the decryption key. In their minds, this was following their policy to let you have your data, even if it was only readable by them. We ultimately had to abuse their APIs to scrape the data out.

At least OpenTable is giving the option of exporting data, because not everyone in the industry does it, and the story above was not an isolated incident. We scraped data all the time, but only with the customers permission.

</comment><comment><USER16> If I give my email and phone number to OpenTable in order to make a reservation I am absolutely not giving the restaurant the right to scrape my data out of OpenTable and give it to SevenRooms with whom I have no relationship. I am 100% on OpenTable's side in this.

<comment><USER17> In the eyes of restaurants, your relationship is with _them_. As a result, they feel fully justified in taking it wherever they please. No service company wants to be at the mercy of an intermediary.

Of course, I don't trust restaurants and hotels to not abuse my info, so...

<comment><USER18> > As a result, they feel fully justified in taking it wherever they please.

Which is 100% abusing the relationship I have with them.

</comment></comment></comment><comment><USER19> OpenTable is misunderstanding where the balance of power lies here. I'm not their customer, I'm the restaurants' customer, despite the fact that OpenTable has maybe found a way to reduce a little bit of the friction in the situation. This is purely a play to lock people in under the convenient guise of protecting user data.

</comment><comment><USER20> When will we have a world where OpenTable has to signup to me? And I release/sell/donate none/some/all of my data to my friends/family/companies/whomever I want?

Who's working on this?

<comment><USER21> How do buyers trust you that your data is actually legit and not something you made up?

<comment><USER20> Finally, a use case for blockchain ...

Jokes aside, let the market figure it out. Authorized aggregators (Qualtrics, Nielsen) will emerge; ad tech will compete for your real data; correlations will continue behind the scenes between your behavior (the thing the companies actually own) and your data; maybe you never will, and we're back to guessing which half of your marketing is working.

<comment><USER21> any solution will need fb to authenticate that data is legit and FB will never provide such a service.

<comment><USER20> No, any solution just needs to incentivize people to share real data. If I don't share where I live, you can't make useful showtime recommendations, if I don't share who my friends are, you can't send me their cat memes, etc

The market will solve this, FB can play along or go jump.

</comment></comment></comment></comment></comment><comment><USER22> It's amazing that this is put up with. OpenTable provides a pretty trivial service but has good integration with point of sale and in no way have any business owning the customer relationship.

</comment><comment><USER23> The article isn't terribly specific but presumably dining and spending patterns of various sorts that can be valuable in the aggregate.

I have to confess that, as a user, I find it useful to be able to book the maximum number of restaurants through one or two apps whether or not they also support making reservations through other means. Especially on mobile, I'm not a big fan of navigating through often crappy web sites and potentially having to provide a bunch of info to find there are no reservations available at 7pm. OpenTable is just a few clicks.

<comment><USER18> > Especially on mobile, I'm not a big fan of navigating through often crappy > web sites and potentially having to provide a bunch of info to find there > are no reservations available at 7pm.

Me neither. That's why I call the restaurant instead of using their web page. The whole thing is done in a couple of minutes.

<comment><USER24> I'm curious if you've noticed that many restaurants no longer answer their phones?

<comment><USER23> I'm not sure that's anything new. Sure, I'll call a restaurant if there's no easy way to book online. But this doesn't work as well when I'm traveling overseas (language, cost of phone call) and, as you say, phone lines are busy, get put on hold, phone not picked up, etc.

Also, with an app, I can see upfront what my options are and potentially see if I have better choices elsewhere.

</comment></comment></comment></comment><comment><USER25> I control it because I almost never take the time to make reservations. In fact, places in which a reservation is necessary almost by definition means a degraded experience for me.

<comment><USER18> There are a number of otherwise excellent restaurants in my area that have stopped accepting reservations entirely and switched to a "first come, first served" model.

I stopped going to those restaurants because of the number of times that I've shown up only to be informed that the wait list is over an hour long and we've ended up having to eat at the greasy spoon down the road because we're hungry and have run out of time.

If I can't make reservations (directly with the establishment -- things like OpenTable don't count), I won't eat at the establishment. The gamble isn't worth it.

<comment><USER26> I think it's worse when you make a reservation, but it doesn't mean anything.

For example, my wife and I went to a PF Changs on a holiday. We had a reservation we scheduled at least a week ahead of time, but it meant nothing, we were put at the end of the queue. It wouldn't have made a difference if we never made the reservation at all.

<comment><USER18> Yes, but that's a problem with that particular restaurant, not with the idea of reservations. If I were bumped like that, I wouldn't go back (especially if we're talking about a chain restaurant) -- life is too short.

</comment></comment></comment></comment><comment><USER27> While there is plenty to complain about with OpenTable, I find their competitor Resy to be far worse on almost every dimension of privacy & data sharing. Meanwhile, Resy has been aggressively pushing to undercut OpenTable's price per reservation to get restaurants to switch over lately.

<comment><USER28> How is Resy worse? I've only used them once, as far as I remember; they seem to have been courting higher-end restaurants that presumably didn't want to put up with OpenTable.

<comment><USER29> Op mentions privacy and data sharing in particular, and there are 2 others in this tgread aledging bag faith on their part in that regard.

</comment></comment></comment><comment><USER30> Yet another example where a user data profile is created and anyone but the actual user whose data it is will claim that the data is theirs.

It's the (now-)unsavoury point of platform businesses, who step into the business relation between a user and a service provider to mine and aggregate and profile data to provide value in a surveillance economy. Would this even fly in GDPR-land, where you can only process data within the narrow confines of the actual business relationship?

<comment><USER24> OT could claim that they are a service provider that helps consumers discover restaurants they'll like, based on mining their reservation history.

</comment></comment><comment><USER31> I wonder if this applies to chains, or to situations where multiple restaurants are owned by the same person/company? Some of my favorite local restauranteurs own three or four places, with different focus, but often a lot of customer overlap.

</comment><comment><USER32> OpenTable should be replaced with an, er, open API standard.

</comment><comment><USER33> Do restaurants who use OpenTable usually have an analog option? (Eg: call and ask for a table?)

<comment><USER29> Open table is the exception, analog is the rule.

<comment><USER33> Yeah I'm just curious if it's replacing or supplementing

</comment></comment></comment><comment><USER21> lol. What a world we live in.</comment>


CanYa acquires majority stake in Bountysource - <AUTHOR> https://blog.canya.com.au/2017/12/20/canya-acquires-majority-stake-in-bountysource-adds-over-46000-users/? <comment><USER2> Bountysource being acquired by CanYa should give new life to the platform. Needed a kick and now it's got crypto roots so interested to see where this ends up</comment>