Hacker News Reader

Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing?

I can't imagine where that sort of conclusion comes from. Building on a crumbling foundation seems to be just about the most proven, reliable way to ensure your software project won't survive more than a short time without needing serious effort just to maintain it and/or a big rewrite.

Much of the world still runs on C, a language that was created long before many of us here were born. Other languages have risen, peaked, and fallen into relative obscurity since then, yet C endures, because for all its faults, it is simple and predictable, the epitome of a sound foundation.

Large amounts of COBOL is still driving back office systems in large organisations. The cost of hiring people with the skills to maintain them is probably horrific, but those systems are still there, doing their jobs decades later.

You can still run applications from nearly 20 years ago on Windows today, in no small part because of Microsoft's persistent focus on compatibility and keeping the basics reliable over that time. Similar stories can be told in *nix world.

What major accomplishments in computing that have been built atop crumbling foundations can claim anything even close to the scale of success of these examples? You surely can't be talking about the move fast and break stuff philosophy that seems to drive everything at trendy software shops like Facebook and Google, or the kind of MVP/lean start-up hype we hear about ad nauseam on HN and the lasts-just-long-enough-to-exit web apps that result.

PHP is a "crumbling foundation" in exactly the same way DOS, Windows, COBOL, and C and C++ were, are, "crumbling foundations". I don't see how you are disagreeing with me. You are proving the point.

You aren't actually going to claim that Windows was well-conceived and theoretically well-founded, are you? Windows has been a never ending refinement on exceptionally shaky ground.

It seems like you're now arguing that PHP isn't a crumbling foundation -- a point that reasonable people could debate -- rather than that building atop crumbling foundations is by far the most successful ways to accomplish anything in computing, which was the claim I challenged.

Incidentally, my point about languages like C or operating systems like Windows was not that they are theoretically wonderful under the hood, merely that they provided a reliable foundation. C has been standardised for a long time and is widely portable. Code that was designed for early incarnations of Windows will often run with little modification even on today's systems because the essential underlying models and APIs have been diligently preserved over the years even as many other changes were going on around them.

I'm curious just what definition you're using for "crumbling foundation". Is it that old software doesn't break on it, in which case PHP/HHVM/Hack isn't a crumbling foundation either - Facebook is built on it, and Facebook is clearly still running.

Or is it that maintenance is difficult and programmers will run into all sorts of ugly corner cases and features that are just grafted onto each other? Because those apply to C and C++ and Win32 and Google and basically every other large software system as well. That's the point the grandparent is making - if you look at pretty much any successful, evolving software system under the hood, you'll see a byzantine mess of complexity, and it's a wonder that it ever works.

I didn't have some some specific, technical definition in mind, but if I were to try and pin it down, perhaps in software terms it would be something like "a dependency that is unreliable in the long term".

Clearly this isn't an absolute scale. As our industry evolves and we develop more reliable ways to achieve our goals, something that we regarded as being a relatively stable foundation in the past may no longer be regarded as such in the future when our standards have risen. Moreover, what constitutes "long term" might vary wildly among different projects.

I suppose my basic objection to the original claim (that building atop crumbling foundations is by far the most successful way to accomplish anything in computing) is that significant achievements in computing tend not to happen overnight but rather to develop over time, and the more stable your foundations, the better chance your project has of developing far enough to achieve significant things.

If you define "crumbling foundations" as "a dependency that is unreliable in the long term", then your conclusion is circular. Of course no long-term products will be built on crumbling foundations, because if a technology stack has long-term successes then, by your definition, it is not a crumbling foundation.

I think the other posters are using a definition of "crumbling foundation" as "one which most engineers hate, which slows them down through excess complexity". And by that definition, almost all successful projects are built on crumbling foundations, because the fact that the project was successful leads you to add features to it, and adapt it in ways that the original architecture didn't anticipate. This process only ends when the software becomes so complex that all further attempts at modification fail, at which point everybody hates the codebase and it is, by pretty much any definition, a "crumbling foundation".

I think it's funny that this whole thread is based on the initial haphazard word choice of reikonomusha yet he is not even a participant in the debate.

If you define "crumbling foundations" as "a dependency that is unreliable in the long term", then your conclusion is circular.

Not at all. I'm arguing that in computing, worthwhile results often take time to achieve, and therefore that foundations that are likely to be around for longer will improve the chances of achieving such results. Alternatively, from the opposite point of view, the odds of achieving something worthwhile go down significantly if you have only a short time time to achieve it, as inevitably you will if you are building on foundations that aren't themselves going to be around for long (whatever we choose to call them).

hm interestingly, PHP still powers about 70% of the web! the web should have certainly crumbled by now ...

I'd disagree if you say PHP powers about 70% of the web. Web servers (and all other kinds of servers) are not written in PHP neither are protocols that drive the web. Operating systems are not written in it either. These (and many more) are what power the web, not web applications. Your definition of what "powers the web" is remarkablly wrong.

Facebook doesn't use web servers or operating systems written in PHP either, right? So if the language that web applications are written in isn't very important to the overall dependability of web applications, then it stands to reason that Facebook's choice of PHP for their web applications shouldn't be a problem either, right?

What point are you trying to make?

> What point are you trying to make?

I had this question in mind while reading your reply. What point are you trying to make with your comment? For my part I wanted to point out that it's unacceptable to say PHP powers 70% of the web. (Check my previous comment's parent.) It has nothing to do with Facebook. And I didn't allude to your inference that choice of language doesn't affect the overall dependability of web applications.

>I didn't have some some specific, technical definition in mind, but if I were to try and pin it down, perhaps in software terms it would be something like "a dependency that is unreliable in the long term"

In this case you are mostly hand-waving, and what you say amounts to "I don't like X language".

> It seems like you're now arguing that PHP isn't a crumbling foundation

I think you need to go back and read the message you replied to. He is not arguing that at all. He's pointing to a long range of other things that he is asserting are also crumbling foundations.

I'm appalled and little bit insulted that you group PHP in the same group with COBOL, C and C++ in terms of their foundation. COBOL and C were designed by some of the greatest pioneers of the field, and indeed PHP is built on C.

In the sense that any software written in C is built on C.

True, but a lot of PHP's ... design also reflects C, only that they warped it.

A few of the complaints about PHP (the inconsistent function library, for example) exist because PHP was originally a very thin scripting language layer for using existing C libraries.

Just because they are remembered as being first doesn't mean they were well designed, or actually pioneers. At the same time C was being written others were working on Lisp, and ML. It has taken nearly half a century for some of their innovations to be recognized as good ideas and taken up by main stream languages, while C was a small improvement upon existing language design.

C designers choose deliberately to ignore the other system level programming languages at the time, which already offered more memory safe constructs, in their quest for a portable macro assembler.

PHP could have been easily done in any language with native compiler toolchains.

Why would you feel insulted? Did you personally create any of those languages? In fact, did you personally create any language? If not, maybe you should't be quite so dismissive of the accomplishment it was to create PHP. Sure, it's not the best language out there, and valid criticisms can be levelled at it, but as they say: It's better to have tried and failed...

What you just said is plain stupid. So our language designers can be critical of other languages? Bullshit! Since programmers can vote with their feet and gravitate towards better languages (is it miraculous that almost all programmers have a distaste for PHP?) we should give reasons why we use C and not PHP. If they were equally crappy what would have been the cause of choice of one over the other? I can call PHP the worse language ever, and I don't need to have created a language already.

Given the widespread use of PHP for web programming, it seems obvious that in the domain of web programming, developers have voted with their feet for PHP.

Energetic amateurs. They've not reached maturity so that their votes should be counted.

Given that these supposed "energetic amateurs" have created an enormous percentage of the code that web applications across the internet run on, their votes automatically count. If PHP developers had never produced anything of value, that would be a different discussion.

>So [only] language designers can be critical of other languages?

Yes. Or rather, other people can be critical too, but language designer' opinions have far more validity.

In other words, anybody can say whatever uninformed BS he wants (it's a free country). But that's no replacement for being an expert in what you're discussing.

>Since programmers can vote with their feet and gravitate towards better languages (is it miraculous that almost all programmers have a distaste for PHP?)

You'd be surprised. PHP is one of the most popular languages and one of the most used languages, so far from "all programmers have a distaste for PHP". So if we were to use that "voting" argument alone (which I find wrong), PHP should be considered a very good language. Not the intention you had, I guess.

While PHP has it warts, it's mainly the less pragmatic and more fad prone programmers that have issues with PHP, those who look for silver bullets and like to feel superior by choice of programming language, editor and the like.

As for programmers "voting with their feet", well, they don't do quite a good job at it. The best languages (like LISP, Smalltalk, OcamL, Haskell, to name but a few etc) are seldom the most popular too.

> but language designers' opinions have far more validity

Here's the case we're talking about the work of a language designer. By the way, not all people capable of creating a programming language have created one yet. Marc-André Cournoyer, who wrote the book that Jeremy Ashkenas learnt language design from to write CoffeeScript, has not created a language himself.

I also get a bit (not terribly, just a bit) insulted if somebody says "Beethoven sucks", because the person who said it is technically the same species as I am.

C was not build by the "greatest pioneers". Just succesful pioneers.

There were far more evolved and elegant languages at the time C was created (and during the time it took for C to rise, even more were made). LISP for one, but also languages with the same performance characteristics and systems programming capabilities as C.

C definitely wasn't seen as a "great language design" -- just a very useful and pragmatic one (e.g see also the classic "Worse is better" essay).

"Windows has been a never ending refinement on exceptionally shaky ground." No. Windows NT was a complete rewrite and it was " well-conceived and theoretically well- founded"

What you say is technically correct, which is the best kind of correct. However, fewer than 1% of Windows programmers ever talk to NTOSKRNL, and probably an order of magnitude fewer do it regularly.

Most of the time, you're talking to Win32/64 or high-level services based on DCOM or .NET, where the "well-conceived" and "theoretically well-founded" stuff doesn't turn up. You can go your whole career without knowing that there's a well-designed kernel under all that cruft.

I'd guess that less than half of Windows developers could say what the object manager does.

For more than half of Windows developers, if you told them there was an object manager, they would ask how you can turn off that service to improve performance.

This isn't true. Every Linux users encounters problems with drivers. By integrating them into the kernel we have an eco system where drivers are out of reach of many users and OEMs. Consider the difficultly in making a desktop scanner for linux. Additionally kernel changes can break a driver with little recourse on the OEMs side, you must simply bend to Linus's will. At the end of the day we suffer from Linux's driver architecture.

So true. Windows' services and drivers system may not be beautiful but it full on works most of the time and it allows even non pro Windows users to change basic stuff with far greater ease than Linux which is a real shame given Linux' potential for transparent usability (a potential it has had since the late 1990s but I have personally given up waiting for it to come true)

> Much of the world still runs on C

But these days, most interesting applications run on C++, which started from the arguably crumbling foundation (from C++'s point of view, not per se) of C, and grew organically over several major revisions into something hideously complex.

This trait of C++ is not a good thing, but the amount of successful software written in it seems to prove that it's not fatal either.

> You can still run applications from nearly 20 years ago on Windows today, in no small part because of Microsoft's persistent focus on compatibility and keeping the basics reliable over that time.

Layers of hacks on hacks to keep old software running correctly is exactly "building on a crumbling foundation", and probably the reason Microsoft is trying to get rid of Win32, having severely limited its availability on ARM in favor of the WinRT APIs. But I'd say the venerable success of Win32 demonstrates that the crumbling foundation works.

C++ belongs to my list of languages that I enjoy using, sadly it was build in quicksand foundations due to C compatibility as a way to make it mainstream.

Add JavaScript. Super crappy but its ubiquity for web scripting is really saving it some real bashing. When we finally have options, we'd relish in our freedom and say what it was like to work with badly written programming languages.

> This trait of C++ is not a good thing, but the amount of successful software written in it seems to prove that it's not fatal either.

That depends. It could also be argued that our current tools are limiting what we can accomplish and at some point we'll need a revolution, otherwise we'll hit a ceiling, just like when concrete replaced the need to carve and place rocks on top of each other.

For example living organisms are way more adaptable, more self-healing than anything we've ever built. Our own body should be a text-book example of massive parallelism involving trillions of independent agents that cooperate with each other. In particular, the process of wound healing that happens when you cut yourself is quite fascinating: https://en.wikipedia.org/wiki/Wound_healing

If we wanted to simulate the human body, or at least the human brain, since that's the most interesting part, somehow I'm not seeing C++ in that picture.

C, simple and predictable? You've got to be kidding me: http://lwn.net/Articles/586838/

It can definitely be simple, but if you're writing C you're compiling directly on hardware. If you change the hardware, your program will not run. That is literally the definition of unreliable.

That's a stupid definition for unreliable.

It's not, actually. The Mars Exploration Rover won't work underwater. That doesn't mean it's unreliable.

When your compiled C program sometimes runs on x86 and sometimes doesn't, that is the definition of reliable.

Reliability can be measured in successes and failures. Failing reliably is not necessarily a bad thing. Some things you build may or may not work on other hardware. That's unreliable. You assert, with confidence, that C will fail. That's reliable. You can rely on it failing.

Compared to C++

Compared to C++ a language made of explosions and guttural sounds is an elegant way of communication.

> What major accomplishments in computing that have been built atop crumbling foundations can claim anything even close to the scale of success of these examples?

Wikipedia and Facebook?

Yahoo!, too, is a heavy PHP user.

They're slowly moving to node and java for quite some time. I interviewed there a few months ago and they drilled me on java stuff.

Neither of those would even remotely qualify is accomplishments in computing. But they also are terrible examples. Facebook isn't using PHP anymore, that's what this discussion is all about. Wikimedia is terrible, and wikipedia is almost exclusively static content being served by squid.

What are we discussing? Are we discussing about the tool or the things made from tools?

Its like trolling a raw cast iron hammer used to build a furniture factory and then saying the whole factory is entirely useless just because some invented a stainless steel hammer.

We're discussing both. The original question posed was something like "what amazing stuff has been built on crumbling foundations", and the response was "wikipedia". I don't necessarily agree with the sentiment of the question, but wikipedia is not a good example of amazing technology.

A fair question is if they successful thanks to PHP or inspite of PHP.

Given a programming task, it will be written faster, easier, and in a more maintainable and less bug-prone fashion if it is not PHP.

The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job.

Let's begin.

1) PHP autocraptastically converts strings that look like numbers, into numbers, resulting in all sorts of weirdness like this: https://eval.in/111886

2) PHP 5.4's OWN TEST SUITE has 91 failures and only 70% coverage. There is NOTHING more "WTF" than that! Why even bother having a test suite?? http://gcov.php.net/viewer.php?version=PHP_5_4

3) Why the fuck are all of these different things equal, and how does this NOT result in problems? http://i.imgur.com/pyDTn2i.png

4) String increment is dumb to begin with, but why does it not even match the behavior of string decrement? https://eval.in/60631

5) Why the hell can you jump back into a try block from a catch block? Recipe for disaster: http://phpmanualmasterpieces.tumblr.com/post/33091353115/the...

6) PHP comparison operators. I'm sorry, but this level of complexity might make you feel smart once you master all its idiotsyncrasies [sic], but it's actually dumb: http://stackoverflow.com/questions/15813490/php-type-jugglin...

That's a small fraction of not-thought-out PHP language features that result in REAL bugs and security holes. Which consume large swathes of programmer time. Which, apparently, Facebook can afford to swallow.

I'm sorry, but your position, as valiant as you are defending it, is literally indefensible. And I don't give a fuck how big Facebook is, they would STILL be better-served by switching SOME of their code to a different language. ANY modern programming language wouldn't suffer from this imbecilic, immature language design.

I can't fathom why you're under the impression that some code hasn't been switched to another language. Furthermore, your vitriol seems quite effective at undermining your thesis.

Fair enough. And to be honest, there was a single night not too many years ago where I wrote up an auction site that had most of the functionality of eBay, in a single night, in PHP (someone else had already done the frontend work, fortunately- I just built the backend).

You're making a mistake. The question is not whether to start a company with PHP vs language X. The company is long started. The question is not whether or not to poof into existence a port from all of FB to language X. That's not possible. The question is, given that PHP is the current language, with all its faults, will it it cost more (including all definitions of cost) to make the switch? How long will it take? Does it get the job done? How bad is the damage?

The question more pertinent to your argument is, did they make a mistake years ago choosing PHP? That's when the could have conceivably gone with language X.

BTW the types of stuff you're listing are documented here. So thorough it's amusing to read: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Why thank you :)

> The question is, given that PHP is the current language, with all its faults, will it it cost more (including all definitions of cost) to make the switch? How long will it take? Does it get the job done? How bad is the damage?

An excellent point. Which in fact is an argument in favor of modularizing your code as much as possible, as early as possible. There are tools now like Apache Thrift which make this easier: http://thrift.apache.org/

> The question is not whether or not to poof into existence a port from all of FB to language X. That's not possible.

And yet Twitter has slowly migrated on the backend from Ruby to Scala/Java. They still use Ruby for the frontend, though it's not clear to what extent, since they've also migrated to a single-page, fat client design on the desktop. And at the very least, their choice of using Ruby when prototyping, was at least sane.

I understand that large codebases can't be migrated easily. But you can migrate individual components when needed, if you have a modular, service-oriented design.

Also - building new functionality in PHP is indefensible, unless their code-base is one big monolithic hairball, which I doubt it is.

It's interesting how most people seem to attribute the quality and longevity of a software to the language it is written in or the frameworks it uses rather than to the amount of thought that was put into its design. Sure, the former is important, but largely overrated.

I think most of you guys are missing a crucial thing here -- how decisions get made. Facebook had two options: 1.) Rewrite all the PHP code in Java/Ruby/C++/whatever 2.) Write HHVM/Hack/etc to transparently convert the existing PHP code.

Option #2 ended up getting a lot of publicity for the engineers. If they chose option #1, not only is it a lot of hard boring and possibly error prone work, there is no chance for any of the engineers to get the type of publicity they are currently getting. All in all, engineers tend to work on whatever will make them get noticed, not necessarily the better technical choice nor what is in the best interest of the company... this is especially true in companies like Facebook and Google where there are a lot of very smart engineers doing relatively mundane work. So there you have it Hack/HHVM are all just publicity stunts, the more you feed it, the happier their PR gets.

> Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" ...

You don't need to rewrite anything (at least, not all at once.) Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules (or rather, with their HHVM bytecode representations.) Then treat the PHP code as a constantly-dwindling Big Ball of Mud (http://laputan.org/mud/).

> Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules.

We took a similar approach to what you described. Then we called it Hack.

This is what we mean by seamless inter-operation: the HHVM runtime understands both syntaxes and runs both <?php and <?hh code in the same process. Whether Hack integrates into the runtime at the parsing (current) or bytecode (future?) layer is an implementation detail.

But the syntax you've got now is effectively a superset of PHP, and comes with all the problems of PHP. You've effectively wrapped your Big Ball of Mud... in slightly different-colored mud. The whole point of a clean-break-targeting-interoperability like this is that you can stop using mud at all, and it'll still work with what you've got now. In fact, what other reason would you have?

If you mean that future versions of Hack will evolve to have a different syntax, while still targeting the runtime... then you'll still have code around from the intermediate era, and you'll have to interoperate with that too, won't you? You'll have PHP, PHP-looking-Hack, and actually-nice-to-code-in-Hack.

PHP's syntax is not what's preventing you from writing large maintainable systems in it. Many of the more successful languages throughout history became successful BECAUSE they used a syntax that's superficially similar to something familiar.

That's not to say that syntax doesn't matter, but semantics and pragmatics tends to matter more, despite Wadler's Law of Language Design stating that most people don't understand this.

I think you are putting way too much emphasis on syntax here. The important contribution of Hack is the type system and this is something that a syntactic-sugar translator like Coffeescript can't hope to achieve.

I also wouldn't count Clojurescript here. Its a whole different language that just happensto compile down to JS.

That is essentially what Hack is.

Very suitable name for a language then.

That's exactly what they did, that's what they are announcing here.

> Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing?

That's only because the currency for building things on top of crumbing foundations has been sweat and man-power. We aren't that far off from the Egyptians that were using hundreds of thousands of slaves per pyramid. It's a good thing that we've transcended the necessity for hundreds of thousands of slaves when raising buildings, don't you think?

And yet, here you are, claiming that building stuff with broken tools is the most successful way to accomplish anything in computing. Actually I view it as nothing short of a miracle, showing human determination in action ;-)

> All languages, runtimes, and standard libraries (and databases, and source control, and on and on) are "broken" at sufficient scale.

That's a fallacy. Just because both X and Y are broken, that doesn't mean they are equal, as some things are more broken than others and PHP is more broken than anything else mainstream (C++ at least has reasons). Also, I don't see how "at scale" changes things in PHP's favor, I really don't.

If you're trying to argue that "at scale" the level of brokenness converges to the same levels, then that's a stupid thing to say. After all, Twitter didn't had to build its own JVM and the stuff they run on top of the JVM is probably more power efficient than you'll ever be with HHVM. Probably saner too.

> We aren't that far off from the Egyptians that were using hundreds of thousands of slaves per pyramid. It's a good thing that we've transcended the necessity for hundreds of thousands of slaves when raising buildings, don't you think?

False, they were skilled, paid laborers: http://en.wikipedia.org/wiki/Egyptian_pyramid_construction_t...

Apologies for being irrelevant to the main point, but this is a tired myth.

Interesting. Thanks for the link. Is Wikipedia great or what? :-)

Facebook is a relatively mature company now that is in the business of making money. In fact, I would argue that [framework of the week] is more buggy and broken because it less well understood.

Actually Twitter has been pretty successful in migrating a good chunk of their codebase from Ruby to Scala.

Facebook can keep PHP for the thin web layer that renders the page, but they could have migrate the meat of their code to a safer and more robust language.