341–350 of 422 posts
E.g. the only way how I could find useful resources on how to run celery with fig was to exclude -gorgonzola.
Wanted: Backend developer. Must have 5 years of experience with Hack.
It's entirely appropriate and reasonable to say "I don't understand why Facebook would do this; please explain it to me." But it reflects a supreme lack of humility to say "I don't understand why Facebook would do this; they must be idiots, and when they, armed with inside information I don't even know I don't have, come to defend themselves, I will angrily try to convince them of the error of their ways."
If you think what Facebook has done here is stupid, why is that something to get upset over? In fact, why is it even something worth arguing about? You're not going to convince anyone who matters, and anyway you have nothing to gain by doing so: Instead, just short Facebook stock and be smug in the knowledge that, when Facebook announces next year that they're abandoning PHP in favor of a ménage à trois of OCaml, F#, and Clojure, you'll be able to say "I told you so".
Earlier quoted context omitted.
My impression is that Facebook mostly write their stand-alone services in Java or C++, and are using PHP only where they're "stuck" with it due to a large existing code base. Do you think Hack is a good language to start a new project in, compared to non-PHP languages? Are you using Hack for things besides the main web page?
Engineer working on Hack here. Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good things about the language. The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages, which usually have a compilation step. The crazy dynamic things you can do also occasionally hav…
I'm intrigued, because it's such a good idea (especially when null's originator claimed it was a "billion dollar mistake"), though Java doesn't have it. I'm wondering if there's some subtle problem with it...?
Also, how do you make your vim typechecker fast enough? Usually, even syntax colouring is local to ensure adequate performance - and a typechecker with inference/propagation would be very non-local.
:(
This was their opportunity to to get multi-byte strings right...
Earlier quoted context omitted.
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…
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 am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…
I think you're using a wrong metaphor. Facebook foundations can't be crumbling just because they're made in PHP. There wouldn't be Facebook as we know it today otherwise. You might say they used a "low quality" material to build them. I see Hack more as a better material, that can also bind with the previous one and make it stronger.
Earlier quoted context omitted.
Yes and the OP is criticizing the decisions being made now as "yak shaving." Could it perhaps be that the "yak shavers" made a conscious and well-reasoned decision to go in the direction of "extend PHP" vs "throw it all out and rewrite everything in language-of-the-month?"
My example, "OCaml", is not a "language of the month." Its roots are >30 years old and wasn't developed by someone in their basement over the weekend. As stated, Facebook even uses OCaml, among other languages, for good reason.
I detest PHP, but I've still more than once made the choice to do apps in PHP motivated by developer availability alone.
It's not a great language, but with some discipline it is also not nearly as awful as some people like to think, and you can make up for a lot of awful with the difference in ability to hire experienced engineers who know PHP vs. many of the less common languages.
They have best functional programming language geeks around and they made this?
I realize it must be shocking to see functional programming language geeks solving real-world problems in a pragmatic way. :-) Seriously, though, they wanted to move a large PHP codebase over to a better language, at the scale of a multi-billion-dollar tech company, in a reasonable amount of time. They accomplished this. What's the criticism here?
Earlier quoted context omitted.
Maintaining your own VM is no big deal. Compared to Facebook, HHVM is a tiny codebase. A team made of relatively small number of people (high quality, but low quantity) can and do maintain VMs like HotSpot and V8. LuaJIT is maintained by a single person.
> Maintaining your own VM is no big deal. As someone who has worked on a VM, I couldn't disagree more. It can take years to hash out things as simple as ideally performing primitives for a target architecture, and then things change . Add to that the complexity of optimizing compilers, specification of byte code formats and a consistent virtual machine memory model that can be relied upon across architectures, and th…
It's possible that they could eventually get a total rewrite to give a better return, but frankly I don't think you have any idea of the enormity of trying to convert a multi-million line production platform from one language to another.
In any case, one does not preclude the other. Arguably, many of the changes they have made, such as gradual typing, and their ability to now slowly introduce other changes without breaking their existing codebase, means they have a platform for slowly firming up their codebase and migrate it towards a position where a full rewrite (should they decide to do one in the future) could be made substantially less painful.