I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that.
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked php and got nothing for it.
It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!"
Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.
At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).
> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right?
Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"
I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?
> Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.
Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks.
It's probably worth mentioning that the regex-dna test time is kind of incorrect and provides an inaccurate view of what's happening.
Java-8 is using java.util.regex which is written in Java, PHP is passing the regex requests to it's own regex process which is actually a C package and performs a lot faster.
What we're actually comparing here is:
time(java.util.regex) > time(php compilation + c regex package)
PHP's execution performance is highly dependent on whether you are piggybacking the C implementations, or pure-PHP ones. That said, this is still a correct benchmark, if your use case involves a lot of regex.
Perhaps the problems are with the way the Java program is written and run?
Back in 2012:
"5) The idea is to help you understand that you aren't comparing what you say you're comparing.
If your intention is to compare time taken to grow a list, then shouldn't you start with lists that are the same size, and start with program heap that's the same size, and use the same max heap size?
user+sys for your Java program = 20.56s
But change
ArrayList<Integer> s = new ArrayList<Integer>();
to
ArrayList<Integer> s = new ArrayList<Integer>(8192);
I don't care about performance.
Unless we are speaking about orders of magnitude and my use case has an absolute need for performance.
If I only cared about performance I would write everything in assembly optimised for every specific architecture.
But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time.
For sure I won't start a new project using a language in which writing such abominations as accessing the database in the presentation layer is not even discouraged, but it is actually encouraged and taken as an example on HN in this thread.
Enjoy your marvellous php.
But please stop the bullshit that pushed a lot of people to use that franken-language rather than using a better approach.
Most professional PHP developers I've anecdotally worked with use a Model-View-Controller pattern these days, where the SQL is abstracted away in the model under something like Doctrine2-DBAL, Propel2 or PDO. If I was hiring for a developer and they suggested putting raw SQL in the view layer, I would reject them. If I received a pull request from my team which did the same, I would reject it.
You seem unnecessarily argumentative about this, almost like you're angry and I really don't understand why. There really isn't that much difference between languages like Ruby and PHP to warrant this and almost anything can be expressed in almost the same way, the only real differences are syntactic sugars and the "flexible" type system.
This exactly. Never been a PHP developer, but I did get handed a PHP webapp to copy some functionality out of for a replacement C# webapp. I was a little surprised to find out that it was written in a rather Rails-like architecture using some PHP MVC library, I think it was CakePHP. Rails was a hit, and a great step forward in web development, so naturally every other language copied as much of it as possible, including PHP. There may be plenty of weird quirks about the language still, but at least the architecture is much improved.
Many/most PHP platforms these days do claim to be either MVC or Rails-based or both. CakePHP is not a bad example there. There are however a few other very large projects whose take on MVC is lacking to some degree. Drupal is not bad, Joomla is worse, and of WordPress the less said the better. Note also that those projects are listed in order of increasing popularity.
Modern PHP frameworks and tools are good, perhaps even excellent. Composer and the PSR-# efforts have spurred a renaissance in code quality and interoperability, and PHP7 brings some truly impressive speed improvements. For those of us who aren't stuck supporting legacy code, that is. One of these days I will be working with a language whose syntax I enjoy, but until then the language that puts the "sin" in "syntax" will (for better or worse) keep getting the job done.
plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.
Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.
Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.
Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.
Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.
They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc.
It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite.
Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.
Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.
This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.
The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model.
You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!
Yeah, but you also have to fork a whole process per request to do it.
Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request.
I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
"fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms.
In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.
The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process.
But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.
It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).
Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain.
That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be.
i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale.
everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.
php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.
memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.
because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.
cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.
but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.
but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.
what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails.
I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.
So comparing PHP to Rails is a bit apples and oranges.
it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".
If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.
If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.
I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.
as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.
it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.
one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.
you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.
I feel your pain, I also worked on a large MMO style mobile game backend, but my situation was a lot better because as you say AWS is a lot more mature at this point.
Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.
As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.
Developers care about cognitive load, and people care about security.
Sure, they'll be some guy who's memorised all of PHPs quirks, but for most of us the inconsistencies make it hell to program, because you're always looking up stuff. As a result, writing secure PHP is possible, but far harder than it should be.
IMO the laughable security track record of e.g. Wordpress have damaged PHP's reputation more than anything else.
As a counterpoint, Facebook, one of the most secure companies in the world, is also the largest single PHP deployment in the world.
C is also a language with a frankly horrific security track record; at least an order of magnitude more so than PHP. But C continues to be used because it is a useful and relatively simple language despite its warts and pitfalls.[1]
Security is just as much a business process as it is a technical feature.
______________________
1. Granted, one of the major design goals of Rust is replacing C, but you get the point.
I think your comment about C is right, however in many cases mercifully the C code isn't facing the internet :) When it does, it can go very wrong, e.g. OpenSSL.
The extra cognitive load doesn't guarantee failure, it just makes it easier to slip up. Even with Python or Rust, you can put insecure code in there (e.g. with Python's subprocess.call(..., shell=True)). Realistically, strict modes and linters are always a good idea and can catch most of these pitfalls.
At which point did you decide not to read the comments properly?
The gist was that PHP was designed for web use, so it's almost always facing the internet. C on the other hand is very much multi-purpose. Both can be made secure, but maybe it's less effort using something that helps you with security (Hack, Rust, etc.).
(BTW, your comment contains a huge fallacy: Just because a majority of packets touches something written in C, that doesn't mean a majority of C code written is exposed to the internet. This is arguably the entire point of e.g. iptables.)
Doesn't it stand to reason that the people that actually know how things work under the hood are the people that care about such things.
You could say the same thing about cars people don't care about what sort of engine is under the hood or how it works they just want to go places! It doesn't then follow that all cars are the same and you are just as well getting any one of the millions of cars or even any one of the models out there.
You have a logical point for sure. I think it might be an apples to oranges comparison in this case though. I just don't know that building cars is the same as building websites and apps. I know Php and JavaScript can respond to an HTTP request. I don't know how to optimize an internal combustion engine. There's probably parallels in terms of expertise with software developers, but I can't be sure.
> I just don't know that building cars is the same as building websites and apps.
Indeed it isn't. "Maintenance" has opposite meanings in those worlds: maintaining a car means keeping its original functionalities still available; maintaining an application means letting it evolve.
> Only engineers care about programming languages. Seriously. That's it. No one else cares about them.
So what? Who else could care for something apart from those professionals using it?
Maintenance is the biggest part of software development. A wrong technological choice can turn my nice job into my worst nightmare. Why shouldn't I care?
I think the intention is: While they are important to us, languages are frequently distorted to the point that we believe that company success as a whole is dependent on it. Companies like Facebook flatly contradict that. I agree with you in spirit: Facebook would obviously prefer not PHP. But if the choice is: Learn something other than PHP or use language I know to test some idea, I think the latter is an obvious choice.
Runaway successes like FB are outliers. Failed businesses OTOH are quite common and usually have a number of causes where bad technology choices can be at least a factor.
You call it poor management in retrospect, but it's succeeding in spite of the tools when you're still doing ok. There's a lot of companies that exist in between failure and "Facebook" who don't have hockey stick growth curves who also can't afford needlessly higher technology costs, whether that's in infrastructure or staffing or opportunity costs in getting features to market. If PHP does't incur a higher cost personally, go for it, but it might be a strategic disadvantage later if you don't hit it big.
"Only engineers care about programming languages."
It's sadly quite common for non-engineers to make technical decisions such as what language, tool, or hardware will be used, and everyone else just has to live with it.
Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment?
Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least one that is a direct clone of Rails.
I to have seen plenty of companies flail and get bogged down because of technical debt and a just get it done culture. It's really hard to begin with a "yes it's a mess, but it works" culture and transition to anything else.
Plenty of A rounds have been spent trying to make a sand castle taller.
This is not unique to php - I'm sure you can do it right - but it's more common to it.
I've seen plenty of companies fail (or at least stall) because of technical debt. PHP certainly isn't to blame for that but it doesn't exactly lead by example either.
I think it would be hard to provide such an example. Mostly because most companies that fail don't do it because of technology but rather because of the nature of their product itself, people, or money. And language plays a part in it but not a particularly noticeable one. Another reason is that failures tend to be silent and we don't pay attention to silent things.
True. But they might have failed with any other choice. Technology is overrated. Yeah, it matters, Yeah it helps. But the right foundation won't save a shite product.
A truly good idea will generally find a way to succeed despite the technology it is built on, though. Look at Facebook, Slack, and countless others running PHP or Minecraft running Java and its apparently horrible code base (I've never seen it, so that is secondhand)
A number of things actually follow more logically than tech doesn't matter which is counter intuitive and counter to most other endeavors in life.
- We aren't very good at judging the relative virtues of tech
- Most tech is good enough to express most concepts even if not equally well. If its possible to express it even if it takes 3 times as much work and is only 70% as good you wont notice from the outside how much the tech mattered.
- Good ideas are worth enough money to throw enough time/money at them to be moderately successful
Delivering enough value to users, faster and cheaper than the competition, wins.
The language you use pay second- and third order dividends, but most battles are fought and won on first order.
I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production.
If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP.
What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.
For many use cases, this is not relevant to the end result.
For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site.
The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP.
In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers).
NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.
To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
> It falls apart when you have a large often-changing content.
Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
I haven't tried jekyll so I can't really comment on it. Im guessing it only generates the changed files everytime you push to git, no? As for your question, it depends on other factors too. Who are your users, what is your web app, is it an ecommerce site? Is the jekyll/git/CI workflow easier than just pressing a few buttons on the screen everyday? Those are the questions you should ask. jekyll might be obvious for us devs but we are a minority compared to the rest of the population.
Take HN as an example. This can't be done as a static site.
Or a simple guestbook or hit counter.
Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.
> large often-changing content. This is where PHP is still king of the web.
PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others.
I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks.
I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back.
From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
echo "<h1>hello</h1>" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well.
Hopefully you get the point.
(I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
I've gone one step further and created a template:
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked [insert language] and got nothing for it.
I know you're making a parody, but I think I agree with your parody.
I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position.
(It's not, by the way, equivalent to the statement "choice of language doesn't matter".)
Mind, I agree with you, but given the Holy Documents Handed Down By Our Lord and Savior, Paul Graham, HN... might not be the safest place to say it.
Edit: so, I'm clearly getting a lot of downs on this... maybe sarcasm in reference to PG was going a bit too far. Oh well. I'm not deleting or editing any of it, because that's sort of dishonest.
All three of the above communities (PHP, Ruby, and FnProg) are diverse enough that a PHP meetup in location A could be culturally similar to an FnProg meetup in location B, and so on.
you could definitely argue that a company using PHP nowadays would find it harder to find good engineers because the best ones who care about quality, performance etc don't want to work on a PHP app
I completely agree with this. There were a host of similar services when Facebook appeared in my radar, I was signed up to a couple of them. Its only because more friends signed up for facebook that it seemed to have a snowballing effect. It didn't seem in any way superior (well except compared to myspace).
In Germany, we used to have a VK-like social network aimed exclusively at university students that was big before Facebook even appeared. To this day I have no idea how that died so fast and hard, and how Facebook managed to overtake it when it hadn't even translated the interface. Ze English izn't zecond nature to all ze Germans.
Ah yes, the * VZs. From my perspective, there's a few reasons. One, my friends were very privacy conscious and would often either not sign up or use a weird name (like some people do). This made it hard to find people. Two, the user experience sucked hard. Third, they had different domains for different subgroups (I remember one for school children and one for students).
Finally, if you went travelling to any other country (except Austria or Switzerland maybe), the rest of the world had Facebook. So to keep in touch, you also needed Facebook, which had a better user experience. Why bother with both?
It's a testament to the poor state of the art in user experience for early social networking sites that Facebook had a (relatively) "good" user experience. It has always been horrible, except relative to most of its competitors.
Your template is far less interesting than the original statement. PHP spent a pretty long time as basically the lingua franca outside the enterprise world (and even some places in it), and there are still domains where it holds that title (e.g. WordPress alone outweighs many languages' ecosystems), so the phenomenon the parent was describing applies more to PHP than to some arbitrary language you could insert into this template.
I actually agree with the original statement. PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail.
"and miss all of the tremendous losers who picked php and got nothing for it"
certainly applies equally across all languages in my opinion.
The grandparent of your comment suggested that, yes, these projects were lifted up by PHP's un-fancy nature giving them focus. The parent of your comment was suggesting that, basically, the companies that have succeeded using PHP aren't any more numerous than we would expect to have come out of the massive PHP userbase even if PHP doesn't offer any advantages at all.
The observation that "PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail" seems to be responding to a nonexistent conversation in which people were positing that startups based on other languages don't fail. Nobody here is saying that other languages magically make your business succeed.
Precisely. This is classic base rate fallacy. If tons of people use PHP because PHP devs are cheap, there are bound to be a ton of successes despite the fact that it's a horrible technology in many respects.
Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided.
If you aren't following the PHP Framework Interop Group (http://www.php-fig.org) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altogether, and those that can't quite possibly can be worked around through configuration.
It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier.
PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintainable code. There's ways to mitigate the chaos.
True, I have seen one startup fail early because he couldn't find any (cheap) Django devs. He might have stayed around another year with the funding he had if he had gone PHP.
Lesson Learned: If you can't do it yourself, start with PHP (or something else with incredibly cheap devs, I suppose) until you get VC funding, then rewrite it using something other than PHP.
Money past a certain point is not an incentive. Retraining takes time. It's harder to land jobs for which one does not have relevant work experience. The PHP job market is larger than most other web programming segments, so work is easier to find. But sure, if you're hiring, I'd certainly prefer working with Ruby.
There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell.
If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?
> plenty of great server-side languages and environments
Depending on the type of project, I would choose PHP over at least some of the languages you mentioned; I guess "great" is not a significant quality when making architectural choices.
Just to be clear: I was thinking about factors like performance, choice of servers, how easy it is to hire good developers, library ecosystem etc.
EDIT: obviously the "awesome aspects" mentioned by GP are a similarly unsubstantiated claim ;-)
The .NET CORE is now open source and cross platform. Cross platform compatibility with the exact same source code, and the killer features/speed of C# makes its my personal choice for a server-side language. I would like to add that C# devs are not cheap and also seem to be slightly more limited in today's market compared to PHP devs.
If you are running .NET code in production on a non-Windows platform today, then you and your team are probably braver and more willing to work around issues than most. I hope that running .NET code on Linux becomes the common case, but I suspect that we are still a couple of years away from that.
It might not be exactly what you had in mind as 'in production', but it's probably worth noting that Unity uses Mono as a core component, and it seems to be fairly popular on non-Windows platforms.
If you are building software that will be deployed by a large number of users, having PHP provided by every $3.99 & up hosting company can't be underestimated. Languages like Haskell are nonstarters.
Disclaimer I worked on a large php app server that ran on about 50 servers and I miss it.
The documentation is really good. A model for programming language documentation.
Process per request is really simple to understand and scale. Your servers almost never crash completely, you don't get threads silently dying or run out of memory or thrash the CPU doing garbage collection.
It runs like a tank. It will, for better or worse, just keep running when more fussy languages would have seg faulted or shut down
The tooling, framework and libraries are very advanced and in active development
It's easy to train a programmer in php
It's close to the c library
The combination of a very flexible array/map and functional programming tools like map and reduce let you write pretty declarative code and development can be very fast
Php storm
Facebooks replacement runtime
I work with Java and Scala now which I also love but development is much slower and more expensive, whilst deployment is cheaper (less hardware for same request throughout)
Can you describe for me how the tooling, framework(s), and libraries are so advanced and excellent?
How easy is it to train a programmer to use PHP in a way that results in fairly secure, reliable, bug-free code? (Note my use of the word "fairly", knowing that there's no such thing as perfect security, reliability, or freedom from bugs.)
I do know that, for instance, TDD is possible with PHP. In my experience and observation, though, the available developer tooling does not even come close to that of (for instance) Ruby, so I figure I must be missing something if "the tooling, framwork[s,] and libraries" constitute a major advantage to PHP over other options.
Well firstly phpstorm is a very high quality. I can work with php code in various contexts such as running test suites, normal development and connecting to a live server. It definitely has good support for running and debugging test suites including unit, integration and functional. There is support for vagrant and docker as well.
The tooling is good because there are lot of users willing to pay for good tooling, but at the same time it can only exist if the underlying language supports the features needed.
I wouldn't say the libraries and tools give it a significant advantage over other languages actually, but it's a notable factor of php development that there is likely a framework and library for your needs.
Regarding training, once we had a reliable application and we'd figured out as a team some best practises regarding avoiding php's bad parts, how to avoid or detect and handle runtime errors and how to organize and layout code, it's a fairly simple matter to point a new programmer at these documents and code samples.
There's really not much to the language and a smart and/or experienced programmer can be productive in days. I'm not sure that's the case if you move someone from say c to Python or from Ruby to Scala.
PHP is about 1/3rd of my day job. Java 1/3rd, and support languages for ops (mainly Python and shell scripting) 1/3rd. Find myself commenting a lot on PHP threads in the last few days...
In my earlier days I did quite a bit of developer tutoring, and I have trained developers in PHP codebases on quite a few occasions, so I can speak to the training aspect first hand. I actually find PHP is fine to train developers in - certainly to produce simple code that is reasonably bug free, if not particularly high performance. The 'everyday' use of the language is usually quite straightforward - most projects don't deal with concurrency primitives, long running code, or low level interop. Scoping is quite straightforward. The only real gotchas are type coersion (use === for primitives or write comparator functions) and superglobals (use a library).
To be honest, JavaScript causes just as much confusion in my experience with scoping. Heck, a scarily high number of developers I know would struggle to implement a bug-free equals() method in Java.
As for tooling - here are some examples of good tooling in PHP:
- TDD and testing:
- PHPUnit (ubiquitous, fairly well featured - built in fakes, code coverage)
- Behat (BDD-style testing a la Cucumber)
- Codeception (DSL-based)
- All three tools have decent integrations with IDEs, can be run easily through Composer's CLI, can be combined with stuff like Grunt/gulp easily for file watchers.
- I haven't needed the really esoteric features in my Ruby projects so I'm probably not the best to judge, but I can't say that I find PHP testing tools all that lacking compared to rspec, cucumber etc. I don't feel like you need complex tools for good testing...
- Frameworks such as Laravel provide bootstrapping on top of e.g. PHPUnit that provide integration test componentry
- PHPDoc - ubiquitous, well documented, well supported by IDEs, linters, docgens
- PhpStorm (on par with the best IDEs out there), Zend Studio (very good IDE in its own right, eclipse-based), and Eclipse PDT are definitely servicable IDEs with good integration, good code inspections, good support for refactoring (especially now with PHP7 and it's further push into gradual typing).
- PDO - something most other languages have to be fair, but a language-supported SQL database engine abstraction layer is a must for working with SQL databases these days
- Gearman for task queues
Libraries and frameworks available in PHP are much the same as other languages in my experience, when it comes to stuff for the web. Not really much point going through them, suffice to say that there are some poor choices (Wordpress), and some good choices (Flysystem).
It has everything I need to know about the function clearly laid out. The behaviour of sort when elements are the same. A list at the side of related functions that I may want to look at instead.
I also like documentation that includes user contributions as these often add useful caveats and usage examples that don't fit well in the general documentation.
Php documentation is the worst. Some of the reasons..
1. They have exactly one set of documentation pages for all the php versions.
2. Another thing is that documentation can be quite wrong for even the fundamental stuff. I have seen a core developer blast out in reddit that "The documentation is wrong!", when the other party pointed them towards a piece of documentation.
3. Incomplete or shallow description. Go check out the documentation page for Exceptions in php and try to find information regarding the behavior of return statements in a 'finally' block. Now go an see the respective page in Python documentation and see how in depth the documentation is.
And having code samples is not exclusive to Php's documentation..
It's not just about the obvious "warts"; it's about the fact that PHP is not a well-designed language on the first place. A wart-free pig is still a pig.
Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.
That will never happen, you can't write code like this in Rust:
<!-- Snippet taken from an example of tightly-coupled and unmaintainable code in the Clean Architecture in PHP book[1] -->
<body>
<?php $results = mysql_query('SELECT * FROM customers ORDER BY name'); ?>
<h2>Customers</h2>
<ul>
<?php while ($customer = mysql_fetch_assoc($results)): ?>
<li><?= $customer['name'] ?></li>
<?php endwhile; ?>
</ul>
</body>
Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low.
The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the last years, fail to appreciate the effort behind projects like Symfony, and become completely foreign to the current best practices.
Why would I ever want to access the database from the presentation layer?
That you cannot write that abomination in rust for me it is a clear advantage, not a disadvantage.
And still I can't understand how can you compare php with rust.
A much more apple to apple comparison would have been with WebSharper.
Because when you're just some guy that wants an answer to the question "how do I get some things from a database into a web page", the answer that starts "Well first go set up a VPS..." and hits "There's this thing called MVC" somewhere in the middle is not something someone who just wants to put a list of things into a web page is going to listen to.
Then a month later that guy that pulled those couple things into a web page is going to go "Hey, maybe I could make a thing to manage those.". And he's going to learn more.
Then a month later he's going to have another bright idea.
And suddenly someone with no programming background is a PHP programmer, and he's putting together ugly but functional websites and everyone is looking and going "MAN PHP IS AN AWFUL LANGUAGE".
There's a huge contingent of people that are maybe moderately technically savvy but are not programmers and are not necessarily interested in deliberately becoming one. These are the people that end up setting up entire businesses in some Lovecraftian Excel sheet. PHP is a language with a learning curve (even for a non-programmer), not a learning cliff, and it makes it really easy for these people.
I don't know if you can do that in Rust (I suspect you can with some effort), but you can certainly do it in Haskell (with slightly different syntax, of course) using a library like Blaze-HTML5.
Your argument is a bit spurious; you're right insofar as you can't write PHP in a language that's not PHP.
That is my point. You require effort in an order of magnitude greater than with PHP in order to achieve the same result, which in the case of a beginner, is the difference between continuing their journey in programming or abandoning the ship.
You are failing to see the big picture and are taking for granted the plethora of initial setup you have to do to begin working with a language like Rust (ex. generating bindings for a database driver written in C if it doesn't exist in cargo), you were just nitpicking in the syntax of the previous example (which BTW, I took care to clarify it was an example of bad code to avoid people not familiar with PHP from getting the wrong idea).
It was my fault to say "you can't" in my previous message (see Atwood's Law), I really meant "it requires too much effort".
>You require effort in an order of magnitude greater than with PHP in order to achieve the same result..
An order of magnitude? Really? I don't think so.
Rust has a library (probably among others) called Horrorshow[1], that exports macros to do html templating.
You claim that it is easy in Php to do html templating. But you miss the fact that it provide zero sanity/security checks while doing so. You need to sanitize every one of those variables before inserting into the html stream.
You see, Php just trades off every bit of sanity and security for a little bit of ease of use. It is that simple.
Yes, an order of magnitude, in PHP we're talking about _minutes_ in Rust we're talking about _hours_ or even _days_ for a beginner programmer, ever tried to install Homebrew in a Mac to name an example? It adds at least a few hours to the equation with its dependency on Xcode unless you already know to just install the command line tools.
Remember that a beginner programmer doesn't always have a background in Computer Science, maybe it's a child, maybe a graphic designer, maybe an elder person or a housewife. Are you really expecting from a person foreign to CS to stop tinkering just because they can't write secure and performant code in your favorite language?
Again, stop taking for granted the initial process setup and all the gotchas that you already know, stop nitpicking in the example of templating and see the big picture: A beginner programmer being able to get instant feedback with little effort in their browser of choice. No initial project or repository set-up, no install for external libraries, no huge development environments (like Xcode or Visual Studio), no build process or compilation, no command line, just an app like WAMP (on Windows) or MAMP (which people accustomed to homebrew avoid) and a browser pointing to http://localhost.
PHP is not a perfect language, but it's neither the abomination people like you describe, too many people judge PHP by its former state of the art and are unaware of the progress it has had in the last years, many of the most popular issues are already gone or at least are too difficult to trigger, to name an example, PHP stopped having register_globals since version 5.4, and PHP 7 added strict type hinting, which throws an error instead of doing unexpected type coercions.
That doesn't mean that PHP is a better choice than properly-designed alternatives, just that it's less worse than before. I agree with the sentiment of using a well-designed language like Rust, but only when a project really requires that degree of security and performance (ex. writing a browser like Servo).
A bakery website written by the kid of a patissier doesn't require that degree of security and performance... Or are you really going to demand that child to use your favorite language just because you despise PHP?
So, you are saying Php is like LEGO and BASIC for web development. I have got no problem with that. Problem is that people using that in a professional setting and uses it to put stuff online.
>A bakery website written by the kid of a patissier doesn't require that degree of security and performance...
I don't think so. Everything that is put online need to be secure. One day it is just a bakery website. Next day it is accepting credit card numbers. And the kid who did this can get employed as a php developer based on this experience, and might build stuff like that for years, with out a clue in the world that they are using a toy language.
When I say "with some effort" I mean "with a bit of initial effort to create a combinator library and zero effort after that". I'm not familiar enough with Rust to be confident of that though. It's certainly the case with Haskell.
> I don't know if you can do that in Rust (I suspect you can with some effort)
You can, using some web framework crates, but PHP is many many years ahead from Rust in making web apps. And I'm not sure if its the right language for the web. You'd probably be fighting with the borrow checker and type system most of the time while the php dev is busy cranking out new features for his/her web app. There is also the problem of compiling huge websites.
Rust looks very complicated to me because there are "lifetimes" and you need to think where to put those single quotes properly. Not a language for a beginner.
Haskell doesn't support OOP if I remember correctly. And it is complicated too.
I never said it was for a beginner, just that it was well designed. Lifetimes are no more complicated than stuff you regularly run into in C++, though.
Python is a great beginner-friendly language, but that doesn't mean it's well-designed in other respects or appropriate for large software projects.
It wouldn't really make sense for Haskell to "support OOP" in the usual since. The OOP paradigm is mostly useful when you have mutability. Another way of looking at it is that you don't need OOP in Haskell because it exposes better ways of interacting with data that aren't present in most OO languages, like ADTs and Typeclasses.
Due to lifetime elision, you rarely need to explicitly write lifetimes. I participated in the last Ludum Dare game competition, my game never used an explicit lifetime.
That said, it is true that Rust has tricky parts. The domain is inherently complex.
> If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it.
This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
If I wanted to embrace garbage every day I would have skipped college and went straight to being a bum. Life is too short to "embrace the garbage" every day.
Not sure about that. Most companies biggest problem is finding talent employees and most experienced engineers will not want to work on a Php codebase especially one full of technical debt due to the variety of other options in languages which compile and miss out on a huge percentage of php problems before you even run basic tests.
> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick.
PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time.
It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP).
It was just files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
I'd argue it succeeded because it didn't require you to run a server. All those cpanel lamp ISPs mean sign in and upload code.
All other solutions, java, .net, node, python, Haskell, etc require you to run and maintain your own servers. A minor exception for CGI based solutions but those were all too heavy.
This comment just nails it. It is perfectly possible to have a well written code base in php. I don't understand whatever written in php is shit.
Some good programmers genuinely point out some of the pain points of php, but most programmers paint php as shit just to show off as a good programmer.
Most definitely you can write good code in soho like anything it is a language which you are free to write in however you like.
However Php allows for really sloppy code (not failing on index misses, undefined variables still running, each core part of the language handling errors completely differently) which unfortunately often gets pushed out when not ready because of business pressures. This often creates insurmountable technical debt later on. The amount of confuaing, messy code I've seen in PHP that would not even run on other languages is shocking.
The fact it has a super easy initial learning curve but progressively harder is not a benefit on big apps it just hides how many headaches it will cause you later trying to figure out the inconsistent core library once you are trying to do more than hack WordPress templates together
> It did one thing and did it better than anything else of the same era
I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
So much time wasted talking about the "right" way to build software, and the best technologies to use, taking positions to bolster your CV or make a name for yourself, and nowhere near enough emphasis on shipping useful, working software.
It drives me slightly nuts. Many people don't realise that technical debt is often a great problem to have because it means you've succeeded. They also want to live in this reality distortion field where they ignore the fact that the code they write today is tomorrow's technical debt because, for reasons I don't fully grasp, they think they're going to do it "right" this time. To quote from Garth Marenghi's Darkplace: "Uh-huh? Bye." In 5 years' time our successors will be wandering around moaning about the crappy code we wrote today, but only if we succeed.
If PHP is the fastest route you know to releasing something worthwhile then more power to you.
(Just to be clear though: I'm not advocating an end justifies means approach to all areas of life.)
Eh, you can do rapid prototyping-type garbage code in any language you are proficient in, as you can do the endless-architeture-meeting, special snowflake beautiful code, enterprise-level everything documented and automatically tested continuos integration and deployment to the most popular containerized/virtualized environment for a reasonable price of $millions in PHP or even bash or powershell.
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I work in C# every day. I love the language, I love Visual Studio, I love the application lifecycle management features of the ecosystem. There's very little I don't like, or at least understand.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
And any PHP thing could be easily prototyped in C# using MVC framework or such. 0 to http-response time is easily comparable if not even faster to what you'd have with PHP. You don't even need IIS. C# is a fine language and I have enjoyed it thoroughly before returning to PHP after some years, but you also can breed monsters with it. Cheers!
touch public_html/foo.php gets me to a http 200 with a valid php file (with the assumption that i already have a public_html directory with mod_php or the like enabled), how fast can you get a C# to http 200 ? :)
I have IIS running with c:\inetpub online (just like you have apache with mod_php). I put a valid foo.ashx up there and voila - the field is level. Okay, the invocation is a bit heavier,
<%@ WebHandler Language="C#" Class="Handler" %>
using System;
using System.Web;
public class Handler : IHttpHandler {
public void ProcessRequest (HttpContext context) {
... code ...
versus just
<?php
but, come on, it's not that bad/difficult, is it?
on an tangential note - I never had imagined i'd be defending the point that C# is as simple as any other language... Funny how life sometimes takes you to unexpected places.
After I use both php and ruby for the same employer over more than a year. I would rather say Ruby is more like a garbage language -- 1) twist syntax to allow people write the same function into different ways is not a cool feature, it is disaster feature which causes more for a team to sync. 2) Duck typing is not interface, don't kidding yourself. they are totally two different thing. 3) ruby attract a lot of master level people try to make the community better, however, the whole community filled with mediocre developers who cannot even understand Rail != Ruby, and also they believe ActiveRecord is the only persistence layer they can use, and stop learning write native database query script.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
I have worked on both (among many other languages) and I too prefer PHP, but I guess my opinion on Ruby is unfairly distorted by Rails, which I dislike a lot. I hear that Sinatra is nice, for example.
Yes, Django is in some ways similar to Rails but, at least, in Django I know how to exclude some parts of the framework (e.g. if I don't want to use Django forms, I'll just go on and use vanilla HTML forms, if I need raw SQL, I'll go for that rather than Django queries). I suspect that the same kind of thing is, at least to a certain degree, possible in Rails as well, however it seems harder to achieve because in Rails the components that make up the framework seem very tightly coupled. Obviously the opinion that I have formed may be distorted by the fact that I know Django/Python quite well, whereas I know little about Rails/Ruby.
EDIT: obviously I agree with you that, if you want more freedom and if you are not using many of the features that Django offers, then it would make more sense to use something light-weight like Flask, which is a very nice framework.
I think you are expressing some legitimate opinions about what kind of languages you like. Ruby, like Perl, embraces more than one way to do it. Some people like that, others find it irritating. Neither reaction is wrong. I think the same thing goes for your reaction to Ruby's lack of explicit interfaces. I find it liberating, you may not.
However what I find incorrect is the claim that Ruby is a garbage language.
Then again, maybe that is best treated as hyperbole, as an exaggerated expression of your dislike for it.
I agree with this as well, although this is about Rails. I still have a legacy project to maintain in Rails (a big project) but that is (hopefully) the last I see of it up close in my life time.
I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system.
There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class.
And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
That's because many dislike prototypical inheritance. It's perfectly usable.
As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
> Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE?
That is true only for low quality legacy code. I have always developed with all kinds of errors enabled and converted to exceptions (that means single E_NOTICE terminates the program with exception as it is done in Java).
Modern frameworks like Symfony 3 or Slim use the same approach. If you write a project using Symfony you won't miss a notice.
I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
I would imagine your doSomething JS function will fail and produce an error in the logging console because doSomething is probably not expecting to receive an undefined. Unless you've written it to handle that scenario and fail gracefully which is probably a good thing to do anyway.
Your whole example is silly. Stuff like this is why you write your PHP/JS/Python/Ruby code in a tool like WebStorm/PyCharm/RubyMine which does enough code analysis to realise you've made a typo and flag it.
In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword.
JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say:
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
charlie.name = "charlie";
charlie.addr = "baz";
var NewPerson = function(){};
NewPerson.prototype = charlie;
var bill = new NewPerson();
This code is totally valid. bill's prototype chain looks like this:
bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype
> A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype.
A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`.
Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them.
Consider your example, translated:
class Person:
name = 'bill'
addr = 'foo'
class Charlie(Person):
name = 'charlie'
addr = 'baz'
class NewPerson(Charlie):
pass
bill = NewPerson()
That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python:
class Person({name:"bill", addr:"foo"}):
#there's no syntax for object literals in Python
#such a thing doesn't even make sense: so I'm improvising.
pass
charlie = Person()
charlie.name = "charlie"
charlie.addr = "baz"
class NewPerson(charlie):
#note charlie is an object, not a class
pass
bill = NewPerson()
In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up.
In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
> In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects.
Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used.
e.g., if I saw, in JS,
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.)
In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".²
In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".
What material difference exists here?
¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects.
²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
Yes, but it's (roughly speaking) an instance of a "Class" class. In the "Person" example, the prototype of a "Person" object is another "Person" object (until the chain reaches an "Object", at least).
This code doesn't look good to me. What is the benefit of inheriting objects from objects instead of inheriting classes?
When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword.
(And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Your code can easily cause a bug. Imagine Person's constructor looks like this:
function Person() {
this.friends = [];
}
...
var NewPerson = function() {};
NewPerson.prototype = charlie;
Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...).
I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler.
Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless:
When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure.
> (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else.
> All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications.
Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else.
I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).
I am trying to write a code that is readable and maintainable instead of building complex abstractions. That is where Java classes fit perfectly (unless you are a beginner who had just read a book on patterns and tries to use every one).
I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple.
> When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used
Yet Javascript has neither of those.
> If you mean that mutating values should be avoided
> I am trying to write a code that is readable and maintainable instead of building complex abstractions.
My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic').
Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects.
Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator").
These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc.
> Yet Javascript has neither of those.
ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.
> For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
Idiomatic doesn't mean maintainable and scalable. Imagine you are working on a project in a team, not alone. How do you understand what kind of "lightweight" object you should pass to this function:
function foo(data) { .. }
When you have thousands of such functions you'll spend most time reading through their code to understand what type of argument they need. This means "idiomatic" javascript code works only when it is small in size. Once it gets larger you'll have to resort to old school non-idiomatic Java-like classes and a static typing system.
Regarding prototypal inheritance I don't understand how it is supposed to be used. Let's say we have constructors for objects User(name) and SuperUser(name, privileges). I understand if `SuperUser` is inherited from `User` (class-based ineritance), but I don't understand what is the meaning of SuperUser being inherited from some user charlie. Why `charlie` and not `john`? Why do I need an instance of common `User` to create a `SuperUser`? And as I haven't seen the explanation in above comments I guess you don't understand it too yet evangelize about it.
I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all. As an argument I can say that a helper method `Object.create()` that is required for object inheritance was only added in ES5 [1] and haven't existed in earlier versions. This is how you create objects from objects without classes and even without constructors:
var person = { name: null, greet: function () { ... } };
var john = Object.create(person, { name: 'John' });
var charlie = Object.create(person, { name: 'Charlie' });
var superCharlie = Object.create(charlie, { isSuperUser: true });
I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
>How do you understand what kind of "lightweight" object you should pass to this function
...and this is where well-documented interfaces come in.
>but I don't understand what is the meaning of SuperUser being inherited from some user charlie.
That was merely an example to express the difference: the idea is, instead of writing a class and doing things that way, objects are cloned from one another. If you want to create a user with special powers, you clone the user object (usually running a constructor function along the way) and give it whatever new functions you want. If you want to create more of these special users, you make them all have that one as a prototype. Typically, the prototype object is never actually used or altered from the defaults, as this would be confusing, and is given a constructor function to instantiate state. But it doesn't have to be.
>I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all.
Wrong. Object.create may be new, but prototypical inhertance is an important par of how the constructors you claim to be the way objects were meant to be created work. Function.prototype, the property which determines the prototype of objects created by a constructor, dates back to ES1.
>I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
Also complete nonsense. Prototypical inheritance was originally implemented in Self, a system developed my Sun Microsystems, and a descendant of Smalltalk-80, which certainly was designed for large applications. JS may have been built for writing simple for validation scripts, and it may be a deeply flawed language in some respects, but the fundamentals of the language, prototypical inheritance, true first-class functions, and lexical scoping, are all things that Eich got right. And given first class functions and lexical scope are still things that language designers have trouble getting right (I've got nothing against class-based OO, so I'm not including it here), it's even more remarkable that Eich did it properly in 1997.
It doesn't help to find a misspelled property (and doesn't prevent you from dividing by zero too). You need a static typing system like TypeScript to detect such kind of bugs.
> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either.
JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.
The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.
So when you do calculations with important numbers, you just push the results to the store without checking them and hope for the best?
NaNs can happen in any language with floats, it's just that some languages also use exceptions in some situations.
I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like the PHP-MessDetector (one of the rarest tool used by PHP programmers), PHP-CodeBeautifier (phpcbf) or PHP-CodeSniffer - Hopefully some open-source projects started using a StyleCI. Another things is database-related code. PHP developers tends to use ORM lately, but on five projects with Doctrine in 4 developers used it improperly messing with a 1000+-lined classes and storing annotation above the fields instead of file or even using Doctrine to get native database-connection via PDO driver to use query db with SQL only instead of DQL for any case. In google there is enormous list of articles about PHP optimization - the interesting thing is, that almost any touches the fact the PHP application should be "compiled" (cached) (e.g. for Laravel [1]).
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
To be fair, as a Python dev, I have inherited some real crap in Python as well. Though recently I had to import some data from a PHP website we have - boy that was another level of crapness (though the main problem was the database design, or lack of it).
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".
But that assumes this is the goal. The real goal is to get a nice looking CV with all the "advanced" entries, not to actually have a useful product or -god save us from this evil- an actual business.
Right, but the point I was making is that it isn't necessarily true that PHP is any better at getting to MVP based on number of successful projects alone.
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
When someone (maybe me) comes and rips out my bad code later, they're going to have the benefit of future knowledge. I don't know how my code will be used in 2 years and what the requirements are, but they will, because they'll be there.
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
Amen. The ironic thing is most people believe that the fashionable language/framework du jour they're using in their project is "high quality code" that will be maintained like that forever, while turning their nose up at PHP code that is "disposable" but in reality more likely to outlast.
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.