Hack Isn't PHP
marco.org
marco.org
However, I've never really understood why people criticize or mock Facebook for pouring so many resources into PHP. For building cross-compilers, toolchains, and syntactic extensions on top of a language that is seen as a fundamentally weak foundation.
I mean, I DO understand all of those criticisms. I just don't get how the same people can then turn around and use CoffeeScript, TypeScript, Dart, and even Node.js on the server-side. Compared to a JavaScript foundation, PHP is bedrock!
No, they're different. Firstly:
- js is the only choice in browsers. for server stuff, you have an almost infinite choice.
- javascript has warts, sure. but if you stick to "the good parts", then it is possible to use in a relatively sane manner. the compile-to-js languages are trying to make it easier to use the good parts, and harder to use the bad ones.
- node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well.
As for the logic of using a single language throughout your stack, I would argue two points:
[1] It's a myth. If you are a professional software developer, you are going to learn multiple languages... and if you're a GOOD software developer, then this excites you rather than bums you out.
So you're using JavaScript on both the client-side and server-side. Okay, how do you get information from your database without learning SQL? Just stick with MongoDB as the only datastore you will ever use? Document stores are great for the things that document stores are great for (another tautology), but suck horribly when you try to shoehorn them into situations calling for a relational database.
What about the HTML and CSS knowledge you already need to work on the client-side? Do those "not count", because a JavaScript developer usually happens to know them? Nonsense. Doing real work requires knowing multiple languages, because different ones are better suited for different domains.
[2] I would argue that the skills and considerations required to do non-trivial work on the server-side are generally different from those skills needed to do non-trivial work on the client-side. You may be smart and/or experienced enough to master both domains, but you approach design and coding issues differently in those domains.
If you take a developer who is senior on the server-side, but is so junior level on the client-side that he or she barely understands the DOM, then they will struggle at first in the other context. Vice-versa if you take a senior client-side web developer and throw them into the backend world. You're going to need to learn completely different skills, quickly. I'm not convinced that clinging to your "home" language really speeds up that process, rather than impairing it.
The code sharing benefits are very real, while backend developers may need to learn a bit about the dom whereas frontend developers may need to learn a bit about sockets / file handles whatever, having a shared language (and libraries) is immensely powerful.
I work on a clone of CouchDB in JavaScript, it also works as an (immature) fully functional server side clone running 90% shared code.
The most used libraries in npm are shared between client and server, it has very real benefits
I still kind of like the idea though, of having only one source for (say) object definition, which is shared somehow between the client and server code. Being able to use the same unit tests to check my client side models as server side ones.
Maybe you could do it the other way around though - having your objects from your SQL Schema (or ORM, or whatever) generate the basic JS models... I dunno.
I totally agree that you need multiple languages, and that knowing multiple languages is incredibly valuable - and a lot of fun. I wrote a basic scheme in python for fun, and have a haskell textbook on my desk in front of me right now :-) - But I also feel that there should be some way that by using one language for all of your application logic (client and server side), there could be a benefit.
Sure, DOM manipulation is it's own weird thing - as is database querying, and document styling,- but the application logic that is done clientside and server side is very similar, I find.
Is there any language for which this is not true?
I may just be biased against PHP.
Facebook, at least, believe that it does have enough good parts to make it worth while, so my opinion is just that. My opinion.
I feel that JS has the following good points:
closures, anonymous functions & enough of the 'lisp-zen-nature' to be quite powerful. The prototypal inheritance is a bit weird, at first, and a little ugly on its own, but actually is quite powerful.
It's simple enough that any non-js programmer can pick it up pretty quickly.
PHP has all the usual well known issues, but has the following problems that JS doesn't:
a vast vast vast multi-level standard library, with many different ways of doing things (mysql, mysqli, pdo...) all of which are built in (or not, you can't tell until run-time). the various different php.ini settings which actually change how the language works (eg. 3 different 'escape to HTML' tags). although functions are 'considered bad practice' to use, there isn't a single source of truth on how to write it well. the documentation is a sea of misunderstanding and examples of how to abuse functions and do things which aren't non-obvious (the comments on each page). JS objects generally have methods attached for doing the various operations on them. php has a bit of that, but mostly external functions that you pass arrays or whatever to. That can be just a stylistic thing (being more 'c' like) but it also means you end up having to know - just to use the language at a basic level - that it's array_splice($a), sort($a), array_rand($a), strpos & string_replace, etc.
JS is really quite a small language. You can read crockford's, 'the good parts' in a day, including all the bits to avoid. PHP is a very big language. To write a 'the good parts' of it would require a much longer book, as you can't use the recommended parts without understanding pretty much of the whole language.
```s``s``sii`ki
`k.*``s``s`ks
``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
`k``s`kskI don thinkt that makes any sense. Should we also use js to implement the OS for the server? If js is good for server-side use it, if not use something else.
My main issues with php is that I dont trust the language and standard libraries to behave as I expect. There are simply to many strange type conversions, silent errors and strange behaviour going on.
We don't normally develop the OS ourselves, so what language it was written in is irrelevant. Same goes for runtimes, libraries, etc. If we're not responsible for maintaining it, it should not matter what language it was written in. Naturally, the "same language on client and server" argument can only apply to code we develop and maintain.
What is the benefit of using the same language on the client and server? That the developer only needs to know one language?
The server-side code you write has to interact both with the client and the underlying OS. So you should consider how language X interacts with both client and OS, in addition to the intrinsic qualities of the language.
If we adopt a modular approach to software development, then I don't see any universal benefit to using the same language for all modules.
js might be a good server-side language, but choosing it because it works on the client is the wrong reason.
I think PHPs speed is largely exaggerated here. The interpreter always used to be slow, and before the bytecode cache it was plain awful. Im pretty sure it only ever got away with it because so much of the standard library is thin wrapping. Is it really faster than CPython like for like?
"Most non-PHP developers judge the entire language by bad code snippets 'written' (mostly copied and pasted) by amateurs for PHP 4"
The old "stop hating on the only language I know! It doesn't have flaws, there are just newbies using it!"
There is plenty wrong with PHP, to this day. When people criticize PHP, they're not usually talking about PHP 4. They're talking about 5.4+. There's some seriously lunacy in the core language. Some of it is there for legacy reasons, and some is brand new.
It is a mixed bag. There are times where PHP is faster because it is closer to C, where as more python is written in Python. I once ran into a situation where it mattered that PHP's file_exists() is much faster than python's os.path.exists(). I have run into other cases where CPython is much better, such as python's heapq crushes a hand rolled PHP priority queue.
In practice PHP tends to be quite fast, because the standard solutions are pretty unambitious like thin wrappers around CURL, rather than actually implementing HTTP in php.
That (specific example) sounds incredibly intelligent to me.
There's one big, primary reason for it.
PHP is dumb.
You can't do clever things in PHP with the language, you have to all the clever things in how you design with it.
You can't overload functions or redeclare them later.
You can pretty much resolve a function at call-time, without worrying about decorators around it or about any meta-programming.
This makes for a fast VM in PHP, because it can make assumptions about function call-order much more than something like python.
I like Hack because it explicitly doesn't support[0] a bunch of cruft from PHP. It feels a lot to me like the BC-breaking PHP.next people want - easy to switch to for modern applications, but not hindered by supporting PHP 4 code. Bit early to start pointing fingers at it's future though.
Not that I think the former is good practice at all, but isn't the latter a kind of weird use of what is a valid variable name?
lambda _, _: None
gives
SyntaxError: duplicate argument '_' in function definition
but tools like pylint will silence unused-variable warnings if the variable starts with '_'.
That isn't what "good language" means.
Thats an interesting sentiment. The exact same could be said for languages like Go (Google), C# (Microsoft), Rust (Mozilla) and platforms like NodeJS (Joyent). In any case it doesn't seem like too much of a worry. Cassandra came from Facebook, and was well done enough that another company came in and picked up development when Facebook left it.
Other than the "web" bit, isn't that true of most new languages, where $proposer is google, microsoft, typesafe, mozilla, redhat, netbrains?
Should people feel more secure if instead of being built and used by one large corporation it was built and used by a single guy? Or should we prefer not to have a big company supporting it?
I saw Tumblrs 'original' code base and it's a giant cluster fuck that is full of horrible design decisions.
They are still in tons of technical debt because of it. So it's funny to see him give an insight on PHP. Kind of ironic.
Either way, Facebook’s HHVM is not for 99% of PHP developers. Most PHP developers need better cache coverage and proper SQL architecture and approach.
Execution speed is not a problem for most of them.
So what is a great language? If it runs the largest active user app on the planet (FB), the most widely used CMSes (WP,Drupal,EE), message boards, MVPs, etc. Why continue the hate, then end the article on how you've chosen it as the greatest option to run some of your systems.
Twitter, famously known as a Rails, now Scala, shop, has used php throughout its life (I know several php coders that have worked there). Their developer/documentation area is Drupal (acquia).
But moreover, as web architectures have become more distributed and JSON heavy, PHP has held onto its language position, especially with International devs.
As a CTO, not a employee, its also important to consider the salaries, roles of the people you need to build the platform.
SF Rails http://www.indeed.com/jobs?q=rails&l=San+Francisco,+CA&rbt=R...
SF PHP http://www.indeed.com/jobs?q=php&l=San+Francisco,+CA&rbt=Sen...
Then look at Non-US prices. Can't find a recent blog post where someone reported on salaries by language.
Quite honestly, there's only a couple or so languages that I would truly describe as "great".
compared to what? IMO an easy to learn language has very little surprises, is consistent and names things intuitively. Would you say that php as the language is easier to learn than ruby or python?
Not really true because HHVM has to run basic PHP before it can apply the Hack annotation. You can pull out the annotations and it's still PHP.
Seems fair - I do like the static typing of hack though. Weak typing has its place but it can become a real PITA (looking at you javascript).
Hahaha! Bigotry is funny! Hahaha!
A bit like PenIsland - or PenisLand. They get a lot of traffic from it.
I agree it is problematic if people are uncomfortable with the idea of gender reassignment and using that for humour. But then maybe that's a way those people use to get over those feelings of awkwardness and move to a place of acceptance?
However, the main reason is simply the fact that it's such a captivating example of unintentional humor, and what happens when you don't pay attention to your image. In many ways, it's the linguistic equivalent of the famous rabbit-duck optical illusion. It's curious and elicits a response when one realizes the double entendre.
It's hardly problematic, unless your definition of problematic is for everyone not to be dull as cardboard to every little example of unintentional humor in their lives.
I don't agree that it's bigotry though.
Transgender people have it tough. Give them a break.