10 ms·

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling fou

by lbrandy 13y ago

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are still using PHP and MySql, improving both. And when we need to break things out, we head into C++, the queen mother of castles on broken foundations. > But at the same time, layering FP with a home rolled static type checking server (??) is bug prone and is certainly yak shaving (which they have time and money to do). Now they've written (1) a compiler to C++, (2) a compiler to VM byte code, (3) a corresponding runtime for each, (4) extensions to PHP, (5) a type checker, and (6) an inference engine. That's a lot of stuff. All languages, runtimes, and standard libraries (and databases, and source control, and on and on) are "broken" at sufficient scale. You're going to be spending time rebuilding things other people take for granted no matter who you are and what language and technology you are working in. The underlying assumption that a "proper language" gives you these things for free is completely false. > Writing correct type checkers and inference engines is kind of difficult. Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" language, but you consider writing a type checker to be "difficult". I think you might have vastly inaccurate pictures of what is and isn't "difficult". > That way, the compiler is now almost an engine to prove your code is correct. I don't see how the same guarantee can be made with something that is just cobbled together. Computing history is littered with dead projects from people who believed that anything less than perfect is unworkable or non-valuable.

goalieca 13y ago
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.
derefr 13y ago
> 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/ http://laputan.org/mud/).
- elgenie 13y ago
  > 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.
  - derefr 13y ago
    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.
    - DeGuerre 13y ago
      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.
    - ufo 13y ago
      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.
Silhouette 13y ago
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.
- lbrandy 13y ago
  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.
  - Silhouette 13y ago
    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.
lectrick 13y ago
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 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 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 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 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-documentation-clearly-says-raptors 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-juggling-and-strict-greater-lesser-than-comparisons 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.
- ghotli 13y ago
  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.
  - lectrick 13y ago
eloisant 13y ago
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.
bad_user 13y ago
> 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.
- gruntmaster9000 13y ago
  > 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_techniques http://en.wikipedia.org/wiki/Egyptian_pyramid_construction_t... Apologies for being irrelevant to the main point, but this is a tired myth.
  - bad_user 13y ago
    Interesting. Thanks for the link. Is Wikipedia great or what? :-)

by lbrandy 13y ago

goalieca 13y ago

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.

derefr 13y ago

> 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/ http://laputan.org/mud/).

elgenie 13y ago
> 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.
- derefr 13y ago
  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.
  - DeGuerre 13y ago
    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.
  - ufo 13y ago
    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.

Silhouette 13y ago

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.

lbrandy 13y ago
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.
- Silhouette 13y ago
  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.

lectrick 13y ago

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 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 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 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 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-documentation-clearly-says-raptors 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-juggling-and-strict-greater-lesser-than-comparisons 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.

ghotli 13y ago
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.
- lectrick 13y ago

eloisant 13y ago

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.

bad_user 13y ago

> 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.

gruntmaster9000 13y ago
> 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_techniques http://en.wikipedia.org/wiki/Egyptian_pyramid_construction_t... Apologies for being irrelevant to the main point, but this is a tired myth.
- bad_user 13y ago
  Interesting. Thanks for the link. Is Wikipedia great or what? :-)