Everyone seems to be focusing on the PHP vs Haskell thing and seem to be missing the other points. Here's a summary:
Callbacks in Javascript make you feel more productive, but in fact you become less productive.
Design patterns in Java don't actually make much of a difference in productivity, but you think they do.
Templates in C++ seem hard but with a big payoff, but they don't accelerate productivity.
Unit tests in python do make you more productive, though it doesn't feel like it. Decorators on the other hand do not make you more productive, but they make you feel more productive.
In Lisp, macros accelerate both the feeling of productivity and actual productivity.
In Haskell, once your brain stops hurting you become productive. When you learn monads, your brain will hurt for a bit. While your brain hurts, your productivity declines. Once you get past understanding monads, your productivity grows at roughly the same rate as it did before you knew monads (in other words, monads do not accelerate productivity). Then you learn category theory, which has no bearing on your productivity but makes you feel less productive.
PHP is a bit of a cheap shot, stating that you won't become more productive over time but you will always feel super productive.
I'll take another tack and suggest that productivity today is more a function of what libraries might be available rather than language choice.
A language like Python has a massive number of really good libraries spanning a range of disciplines. Is it the "best" language (whatever that means)? Don't know. Don't care. You can get the job done and the ecosystem is huge.
I am not comparing Python to Haskell or anything else, just using it as an example. I don't use Haskell and wouldn't know how the libraries compare.
My only point is that when all the smoke and bullshit clears out the only thing that matters is if you can get the job done as required. If this includes a performance metric than language performance is important. If it does not, then library availability or other criteria might quickly become more significant.
From my own perspective, it would take a lot for me to choose anything other than Python for my work. When a platform mandates it --iOS native apps-- you have no choice. On embedded systems it's mostly C. When Python fits I can get shit done with it. Nothing else matters.
The graphs are not productivity vs language choice. They are productivity vs experience in a given language.
In languages with strong libraries, I'd expect a diminished benefit from experience. 10 years python experience doesn't make you much more productive in standing up a django application vs someone with 1 year of experience. Thus, the curve for python might very well be quite flat (since you start fairly high to begin with).
Lisp, on the other hand, may not start as high on the productivity scale. Because of its powerful macro system, the language can be tailored to suit your problem better than anything else.
That's what the graphs are talking about. How valuable experience is (and comparing it to how valuable we think our experience is).
A python developer with limited experience is likely to use too many 3rd party libraries in simple cases where they are really not needed. As the application grows this turns into a maintenance and/or performance nightmare.
Not to mention the fact that it takes experience to understand/troubleshoot/fix third party code. When things go wrong the dev with 10 years experience is going to be vastly more productive than one with less experience.
I am a python dev with >10 years experience and I manage numerous junior devs with limited experience, so I see this kind of thing all the time.
But are you actually gaining productivity when fixing third party code? Or are you losing productivity? I would say you are paying back the gains you got from using the library in the first place and therefore losing productivity. Granted, you generally come out ahead.
I think that's the plateau in most languages. You get to a point where you are fighting the language/ecosystem as much as it's helping you and so productivity plateaus.
I wasn't referring the the graphs anyway in regards to absolute productivity. Rather, I was referring to the parents claim that the library in python makes you more productive, which may be the case.
Also, "why wouldn't they be"? Whitespace is boring. Maximizing useful space on each graph would require a different scale for each language. Also, productivity in each space is varies widely limiting apples-to-apples comparisons across languages (even within languages this is tricky). There's no question that for some workloads Python is more productive than C++ or Haskell. The discussion is really about what the learning curve for the language is (hence the title).
It's funny that we feel PHP doesn't make you more productive, yet most of the web was running PHP apps until a few years ago when better languages gained momentum and we saw new web sites not built in PHP.
The decision to use PHP is not represented in the graphs. What the graphs say is that as you gain more experience with PHP you don't necessarily become more productive. 1 yr PHP experience == 10 year PHP experience.
I think your parent is referring to the fact that the Productivity graphed for PHP is the worst of all the languages, even at t=0 (except Haskell, which is shown as starting out with 0 productivity for a while.)
I also strongly disagreed with that for the same reason your parent comment did. The self-assessment bar is funny, but hte blue (productivity) graph needs to be way higher.
There's no absolute scale, so you can't make comparisons between the graphs. The only conclusions you can make from the PHP scale is 1) that (according to the author) PHP developers think they are a lot more productive than they actually are and 2) experience doesn't increase productivity substantially in PHP.
what makes you think the graphs aren't meant to be read on the same scale? By that reading the PHP productivity line could be 100x higher than the next-best language listed, but with self-assessment being 1000x higher than the next-best language listed. That is not a very sensible reading.
With the exception of pandoc, I don't recall seeing anything particularly impressive from the Haskell camp.
(Btw, this, actual stuff people use, is how I measure programming languages -- this metric takes into account communities, libraries, practical issues, etc all together, and ties them with practical results. It's my version of "let the market decide").
Darcs used to be the poster child for Haskell but then somebody came along and wrote a much better DVCS in C, of all languages. Draw your own conclusions...
Still use darcs to this day. Darcs is magical AND productive. I use a script to play back my darcs commits into a git repo so i can put my projects on github. I love you darcs, I love you.
You may want to check out Warp [1]. Another quite popular haskell project you may have heard about is this compiler some people use... is called ghc :) [2]
There are a few startups out there who use it as their core tech. It's a sweet spot because you don't have any legacy code to support and it allows you to slap together fairly stable code fairly fast, at least once you get to know the basic tools. E.g. picking up Yesod (which, to be fair, isn't something you'll do in a couple hours) gives you all of the niceties and rapid prototyping of a tool like Rails, plus the obsession with type safety that gives you that handy line of technical credit.
I can't imagine ever using Haskell for a startup. Unlike pg's python paradox, the only programmers I could imagine applying would be programming language theorists, toy programmers, and people who think they are productive (because arrows!), without ever having built anything ever. I would only do it if it meant I could hire John Macfarlane.
We've actually had a pretty good time hiring for both Haskell and Clojure, it attracts a certain type of developer that a team like mine likes to work with.
There are certainly applicants from the groups you mentioned, and we do our best to filter them out.
It's interesting to hire people for stacks that most programmers have no production experience with (and have pretty much no way of getting), but it's certainly been done before.
In my view the tech in a startup pretty much doesn't matter. You either make something someone will pay for, or you don't, and then you die whether you use Fortran or Coq. Thus you might as well make yourself comfortable for the ride and use whatever you'll enjoy building stuff in, something you won't be easily bored of using and teaching others.
If you get to the stage where you need to quickly bring up to speed hundreds of developers, you pretty much already made it and you're experiencing growing pains, that's a good problem to have. Most of your code won't survive that scale without a serious rewrite anyway. You'll deal with that when you get there. The vast majority of people will never get that far.
We use Haskell heavily at my startup and it's definitely a competitive edge and well suited to the many general programming problems we solve with it (amqp processing client, rest api, javascript heavy webapp w/ haskell web framework backing, db orm modelling, scrubbing and feeding data into influxdb, the list is long).
I know quite a few professional programmers who credit Haskell with making programming fun for them again (this holds true for me too and my production skill set includes php, c, c++, python, ruby, erlang, scheme, javascript, scala).
Yeah, I've got a similar impression. The only 2 things I care about are 1) productivity (time to finish a task) 2) how pleasurable is it to use a language.
And I just don't find Haskell (or Lisp) to be as productive as many would suggest, even if you adjust for matureness of the ecosystem. (Note: I have a moderate experience with Lisp, very little experience with Haskell and these days mostly program in Java, Julia and Python.)
I wrote the core of our system in Clojure a couple of years ago, which is pretty high in productivity and actually quite pleasant to work with. Unfortunately as the scale goes up (hundreds of web application routes, sharing code among multiple projects etc) it doesn't feel nearly as nice anymore, and having static typing turns out to be pretty handy.
Haskell to me felt exactly like what you described: I could get stuff done fast because of how few head-scratchers I'd experience. This is mostly due to type mismatches, and how much more well thought our my design needed to be upfront. I also really enjoyed the language because I could express fairly complex thoughts in a very succinct, and yet very readable fashion, mostly thanks to types being explicit and enforced at compile time. Code reuse and sharing across multiple applications is also a breeze, which is absolutely key once you get past the "single Rails app" stage and you start getting into two digits worth of tools, services and applications.
Oh ok, I can be wrong about Haskell. BTW, I really like Ceylon, it's very statically safe (more than Haskell I'd say) and very pragmatic (unlike Haskell IMHO, it doesn't seem to focus on maximizing productivity).
Why? You assume that little experience with Haskell is not enough to make conclusions about its productivity. I disagree with this assumption, I think you can sometimes make a moderately confident conclusions from little experience. And I understand I can be wrong of course.
The point of graphs like these (aside from making a joke) is to describe the learning curve. These graphs admit that the beginning of haskell is a nightmare, but claim that eventually you have "unbounded" productivity.
It seems rather hard to evaluate the tail end from "little experience".
It's an incorrect conclusion that requires further education and experience before you can be sure your subjective experience of productivity truly is that poor.
please, this is getting old. Haskell is one of those languages for people who want to show off how clever they are instead of just getting on with developing applications that actually do useful things efficiently.
I hope you are trolling. Most Haskeller's value getting things done over being clever and actually actively avoid being clever. In your other comment you point out that many of PHP detractors have not used it or have very little experience.
Do you have experience using haskell? If not, you are being hypocritical. Please stop.
>Haskell is one of those languages for people who want to show off how clever they are
Yes, that's what banks are most known for. Showing off how clever they are and not doing anything useful. Facebook and google certainly fit that profile as well right?
I am suggesting that your confidence is misplaced. Having little experience in something means you should have little confidence in your knowledge of that thing.
Really don't understand the pure hatred that people have for PHP, I'm at network engineer and I don't have any desire to become a programmer because I love my job, however I've wrote some very useful applications that myself and my team use on a daily basis to make networking easier for us.
For me it was simple to learn PHP and create something 'useful', basically every web server is capable of running it which makes my life a lot easier as well.
Surely the fact that someone can hack together code within a few minuets that doesn't profess to be a coder is a good thing, regardless of the language that there using?
There is no better programming language than the one you know.
I'm no mechanic and I have no desire to be one but I've changed my own brake pads, surely anyone can adjust their car's brakes and many other tasks with a few simple tools and a book.
I don't understand why mechanics say some cars are better than others.
Playing around with motorbikes is actually one of my hobbies, and I have some very nice and quite expensive Snapon tools which work wonders in the garage.
However I'm certainly not going to suggest that changing your breakpads was done incorrectly because my tools cost more than what I'm assuming yours did, or that I could complete the same job a bit quicker and therefore better.
Sure, if you're going to change break pads all day long for the next year I can suggest some very nice tools which might help you.
But instead I'd like to say well done on changing the break pads, I'd wish more people would use the tools that they have at there disposal, show some initiative, and do the same.
In addition to being obnoxious I don't even think your analogy is correct. Programming languages are the tools, and it makes sense a non mechanic wouldn't understand why some tools are better than others.
I used PHP 15 years ago for making my first web developments.
The problem with PHP is that it's like everyone's bitch. You can do whatever you want with the language. It really allows you to abuse it, and has some of the naugthiest features a language can have.
On those years, if you wanted to fire a simple script, to make a SQL Query on MySQL, extract some information and output a XLS file, you could choose between PHP, Perl, Java, C, C++, VB... So PHP was the only real option. Today we have Python, GoLang, (Ruby... bla bla bla), all of them have rich libraries and have great features too, but doesnt allow you to make a GoTo Statement (avoid Global Variables, and so on...), and well, are brilliant languages (Im talking to you Python)
Sidenote, I still remember fighting a day long with a bug in my code just to discover it was actually a PHP Interpreter bug, and I still remember how much the Language changed around the year 2002 when they simply stopped to be compatible (they tried very hard to transform the language from a shitty one to a decent one), today is not a naughty language as the one I used, but still I see it both as an offensive language, and with gratitude because when I was 16 and had my HostWay webpage I had two choices for my webpage: PHP or Perl, and damn PHP really introduced me to the world of programming.
This rant (not by me) explains why[1]. PHP is full of gotchas, things that make security hard, and areas that are likely to break and be really hard to debug.
There's definitely scope out there for a better effort to be made addressing the situation you raise, but PHP really shouldn't be the popular language that is is in that space.
Sure it may be a fractal of bad design, but it's unfair to say it has no productivity value. You can write plenty good PHP code that actually accomplishes things. (And this is coming from someone that hates PHP)
> but it's unfair to say it has no productivity value
Nobody is saying it has no productivity value. Even the "joke" isn't saying that - the Y axis isn't labelled - it's just suggesting a) productivity doesn't increase, and b) you feel much more productive than you really are.
PHP is full of problems that lead directly to security vulnerabilities if you aren't constantly aware of them and very careful when writing your code. So when someone who doesn't know those problems (most people) "hacks together" something that "just works", it is almost always providing a backdoor into that server. Once you do learn a little, you find that every scripting language is just as easy to work with as PHP (if not easier) and much safer. So why use PHP over perl or python or ruby or even javascript? They just aren't compiling into apache for no reason.
Generally speaking, tutorials in those languages recommend using the paramatized versions of the queries rather than string concatenation and manual escaping. The official docs from these more well-designed languages would have copious warnings against attempting to escape user input yourself, rather than having numerous functions baked into the language to help you do just that (e.g. `mysql_escape_string`, `mysql_real_escape_string`).
Reading a 10 year old tutorial on W3schools isn't the best place to learn current PHP, and it's not the fault of the language. PHP has moved on, if only the haters would too.
So your argument is that the dangerous extension is deprecated as of a year and a half ago? Given that PHP has been around for nearly 20 years, it seems like your evidence supports my argument more than yours.
> PHP has moved on, if only the haters would too.
Unfortunately it's not that easy. A lot of those tutorials are still being read by newcomers, and a lot of the web is filled with vulnerabilities as a direct result of official documentation recommending insecure ways of interacting with the database.
PHP may be "in recovery," but that doesn't necessarily mean the bad taste will magically leave everyones' collective mouths. The damage has been done.
The mysql extension is not dangerous in any way, don't spread FUD. The reason for not deprecating it sooner is that very large projects depend on it. These projects may have been ten years in the makings and aren't in any way unsafe because of the mysql extension. Software like WordPress and Drupal still use and support the mysql adapter and run on a huge percentage of the web today.
I agree a lot of people read insecure tutorials, but it allows even beginners to write fairly advanced web sites. If the choice is between easy and available and difficult and hard to use, I'd rather have the first option available. On the web, ideas, timing and execution is important, not how amazing your code looks on the backend. A lot of great software may not have been created had it not been for how easy PHP is to get started with. As a community we are trying to educate people to code properly. It's an ongoing process.
Actually yes - perl has a tainted mode (#!/usr/bin/perl -t) that force you to sanitize every input from the outside world. It does not do the work for you because it is agnostic to semantics (escaping for shell is different than escaping for SQL for example) but at least make you think about the problem.
So what you are saying, is that it's not actually widely used, or even useful in the scope of a web site? In that case, it don't see how it changes my original point.
>Does Perl, Python or Ruby have built-in automatic escaping and sanitization?
No, of course not. That's very much the point. PHP's broken attempt at that created security holes.
>On top of that all three of those languages require additional setup
No they don't. It is just that someone else has already done the setup for you with PHP at most cheapo hosting companies. Installing python is no harder than installing PHP.
>(Especially Ruby with RoR shudder)
You are comparing a framework to a language. Rails is no harder to setup than any of the PHP frameworks like zend or symfony.
Providing sanitization functions 10 years ago is broken to you? If you check my earlier post you'll see that prepared statements are widely used nowadays. Escaping functions like htmlentities() are also still effective.
You are right, there are a bunch of hosting company providing 0-config PHP, but setting it up in any distro is also never more than one command away, unlike the other languages mentioned.
Regarding Ruby and RoR, I can't even find a tutorial on how to run Ruby under FastCGI, and RoR appears to be the de facto way to run Ruby websites, so if having a framework is required to run any non-trivial Ruby website, then it has to go into the "hard to configure" part of the argument regardless of semantics.
>but setting it up in any distro is also never more than one command away, unlike the other languages mentioned.
No, exactly like the other languages mentioned. If you are seriously going to try to pretend installing python or ruby or perl is harder than installing PHP then you can't expect anyone to react as if you are being serious and genuine.
>I can't even find a tutorial on how to run Ruby under FastCGI
That sounds like a serious problem. I would suggest looking for a local "introduction to computers" type class. They tend to teach basic usage of windows and the web, including how to use google to search for things. I think it would help you a lot.
>and RoR appears to be the de facto way to run Ruby websites
While I'm sure the rails guys must be flattered, I don't know how you got that appearance. There's a whole bunch of frameworks, just like with PHP. And you don't need to use any of them, just like with PHP. But of course, you know all this and are just trolling.
For goodness sake people. You can take a comic as an attack on a particular programming language, but how is this useful? Maybe there is wisdom in this comic or not, but there is value in people reflecting and presenting a humorous point of view.
I have used all of the languages above and found the comic humorous and greatly exaggerated. But I think that there is something here. If you haven't really used the exalted languages in this comic please try them. You can only learn from the experience.
Also, if users of a particular language appear to be elitist, this does not say anything about the value of the language itself.
An open mind is going to be both happier and more capable.
As a primarily PHP developer, we get told all the time at conferences and places like this how awful we are. I actually wrote a fairly popular post not too long ago about a Haskell speaker being actively hostile against PHP developers. Our mantra has become "I can't hear you over all this work I'm getting done" I've worked in many other languages and nothing really compares for how quick I can knock something out in PHP that does exactly what I want. The code probably won't win any beauty pagents but the client doesn't care. Anyway came here to say the PHP chart is backwards. We hate ourselves but are super productive.
It's not that the developers are awful, it's just that the language makes it very easy to make really bad design decisions that come back to bite you if your project becomes large.
I think by "self-assessment" is meant something more like "self-regard", the whole being taken to mean that PHP programmers have a relatively high opinion of themselves, which is not justified by the code they generate.
I gather the author is perhaps not a native speaker of English, so perhaps this is a subtlety which has simply passed him by. As such, I've opened an issue on Github to suggest the replacement of the term. (Also another, to suggest the Javascript chart be updated to account for promises; I've somewhat less high hopes of that one, given that the author appears to be a disciple of the Haskell language family and to entertain the prejudices so commonly associated therewith, but who knows? It's worth a shot, in any case.)
>I think by "self-assessment" is meant something more like "self-regard", the whole being taken to mean that PHP programmers have a relatively high opinion of themselves, which is not justified by the code they generate.
I read it this way too, and this is what I'm disagreing with. I've seen far more programmers for other languages having a high opinion of themselves than PHP guys, which are more workman-like.
The worst offender in this regard would be some Javascript guys (and their n-th rediscovery of the computer programming wheel).
Joke answer: no. I'm not even a PHP programmer especially (though I've worked with the language in several occasions).
Cut my teeth decades ago, when the web was just starting, Perl was king, Python didn't have half of the stuff it has in 2.7, and AJAX wasn't even a thing.
PHP is the standard bearer for the expert beginner. People write something that seems to be working quite quickly, so they feel they "get it" and know what they are doing. And then they stagnate and stay like that for 5, 10, 15 years even and never learn more. And then when presented with things they don't know, they resort to anti-intellectual rhetoric and trying to convince themselves that those things are "just a different way of doing it but no better than how I do it" and stay there in their rut forever thinking themselves an expert.
This isnt even funny.Unless you want to take a cheap shot at PHP and glorify Haskell,the language everybody brags about but almost nobody uses professionally.
Oh wow lel so funny, 10/10, pease make more PHP jokes, they are so super funny. And you are right, too! Not a single PHP developer was ever productive and shipped a product. None. Never. And especially PHP devs walk around and proclaim "We are the elite! Our language makes coding fun and hip!!!!" all the time.
Actually, right in these comments PHP programmers proclaim how productive they are, how PHP powers half the web and how Haskellers haven't done anything practical.
So it seems your sarcastic rant completely misses the mark.
I've discovered elixir several weeks ago and fell in love. Dynamic functional language with great concurrency support and ruby syntax. Wow. Lots of other goodies, too.
Started a complete rewrite of my data analysis project in elixir and it is going great. I am nearly sure that my chemistry with elixir will stick for a long time.
Due to practical reasons javascript is my primary choice for small, short-term projects. As an example, meteor is really interesting. I consider JS to be a safe-ish investment of my time due to its momentum and huge ecosystem. It doesn't make me happy, though.
So, to answer your question my languages of choice are JS + Elixir.
Before elixir I've tried python, ruby, go, r, javascript, haskell and c. Btw, I consider programming in haskell to be a good learning exercise for understanding advanced CS concepts.
It seems that it interchanges "productive" with "writing clean code".
PHP is ugly but can be productive. Haskell is beautiful, but well, I know a lot of people encharmed by it, but no-one productive (i.e. delivering products quickly; it's not the same as solving pure, mathematical problems).
Interesting. I like working in Haskell precisely because it allows me to iterate faster than in something like Ruby/Java/Clojure/<insert-more-popular-language-here>. Granted, I'm not paid to write Haskell, but I think that's more ironic than anything else.
Perhaps someone from industry can confirm my feelings here.
I will [subjectively] confirm it. I've rebuilt two startups from Scala / Python messes with Haskell. Turn around time was counted in weeks (original build time was > 6 months), code is clearer, many unhandled edge cases were illuminated by the type system (some simply due to the rewrite), bringing in another Haskell programmer was painless and he was able to safely refactor the entire code base to make it even cleaner and robust while operating in production with zero regressions and no unit tests.
We can iterate faster, the type system prevents us from doing dumb, fallible human things, it makes it easier for other programmers to get up to speed, it is fast, the community is brilliant, and because of its static guarantees open source tooling (even if abandoned) is possible to use because of the aforementioned ease of coming up to speed, the type system is a stringent form of documentation, and you can tweak without fear of introducing regressions (mostly, I can't say all but definitely most).
Do you know alot of Haskell programmers? Because I'm enjoying my typesafe SQL queries, typesafe intra-application linking, typesafe templating, etc. Haskell is capable of far more than "pure, mathematical problems"—indeed, typed IO is a premier feature of the language.
edit: sorry, this was pretty defensive; I shouldn't have written this comment so hastily.
You know, C#/F# programmers are enjoying most of the above in spades, and the libraries are fully vetted and mature to boot; could say the same for Scala to some degree.
Can we say the same for Haskell? Let's take a sample: you say, "I'm enjoying my typesafe SQL queries"
There are 2 Haskell query DSLs worth talking about (read: that support joins): Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql); the former at first blush looks decent, but then you realize, whoops, no string based SQL interface (for those ultra complex db-specific queries business requirements demand, but cannot be expressed in the dsl), and no Oracle or SQL Server support -- yikes, bye bye enterprise; in fact both libraries officially support one single database, Postgres.
Also, given Haskell's lack of a module system (hello global namespace conflicts), the choice of operators is somewhat, well, hideous (Haskell itself remains beautiful though, at least in terms of concision).
Not sure how things are on the web framework front, but given the claims of achieving C-like performance, that Yesod and Snap basically face plant in a popular benchmark[1], one wonders where reality and the ideal world Haskellers seem to live in, meet.
Hi virtualwhys, won't have time to respond to everything but wanted to mention Esqueleto supports MySQL/Postgres/SQLite, they're mentioned in the testing section of their Hackage page https://hackage.haskell.org/package/esqueleto.
Re: the techempower benchmarks, my understanding is that they used an old version of GHC which didn't include the MulticoreIO manager or something like that. It's since been fixed [1] but it's been awhile since a TechEmpower benchmark (iirc round 10 was pushed back but they're now working on it again [2]).
> Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql)
On the contrary, Opaleye (lowercase "e") has been used in production to run multiple-hundred line queries with high performance. I gave the "idealized SQL" examples in the docs as a way of making the generated code easier to understand for readers, not to suggest that there is any performance loss. If you know of an example where the code generation leads to a performance loss in Postgres I would be interested to hear about it.
We don't use it at work so I can't say I've done anything at scale, but I was very happy with it making this internal-ish website for work http://heyzaphackday.com/hackdays
I don't think I had a single 5xx or 404 when developing it, and last I checked 1 500 error in production. I know it's a small site, but it's still pretty unlikely that I'd make a small Rails site without typoing something/misremembering a SQL column name/making a bad assumption about e.g. always getting a value from a cookie.
>I know a lot of people encharmed by it, but no-one productive (i.e. delivering products quickly; it's not the same as solving pure, mathematical problems).
Is this actually true, or is it "true in your heart"? Very few people use haskell for solving "pure mathematical problems". People use it for things like developing the fastest microkernel in existence, doing high volume trading, making games, and writing boring old web apps. References to "pure mathematical problems" and implying nobody is actually doing anything with haskell come off as sounding like second (or third, or fourth) hand FUD. We taught our PHP team haskell. They had their first project in production in three months. There's nothing special about math and haskell.
I don't imply that nobody uses it for solving practical problems. Just, I made my judgement based on:
- friends (I know, it may be biased),
- GitHub codes I use (and in general, popularity),
- blog posts on Haskell (I encounter mostly language-oriented; less problem-oriented like "let's make a 3d game", "web scraping", "machine learning", "web dev" etc).
Likely. Ideally with code tutorials/examples rather than "me and my friends changed X to Haskell and we liked it".
I mean, it's not I am anti-Haskell or something (it is clearly on my list things to learn), and I am theoretically-inclined (I did quantum physics and pure mathematics). Moreover, I am biased towards clever, succinct solutions rather that horrible code that "just works, somehow".
Yet, for practical problems I do things that work, even if it is JavaScript code, which is not even close to "pure" or "nice".
I'm interested. I probably wont ever use Haskell again, but it would be nice to see that there is more to the community than the self-congratulatory cleverness competition that I experienced.
To what? I'm supposed to link you to reality? How about since haskell is a general purpose, turing complete language, you demonstrate that there's some magical reason that it can only be used for "pure math problems" and nobody can be productive in it doing "real work". Why should a random nonsense claim be given the standing of fact and need to be disproved?
>friends (I know, it may be biased)
That's why I asked if it was true in your heart. Lots of people say things they think sound reasonable and believable based on other third hand information, but which are in fact made up. I have a very hard time believing you have so many friends into haskell and unable to write programs in it. Especially after teaching a bunch of PHP people who had never heard of functional programming (and half had never heard of types!) haskell in a few short lessons. Either your friends are some crazy statistical anomaly, or my developers are. Or perhaps your friends are apocryphal.
>GitHub codes I use
"I don't use anything written in haskell so you can't write anything practical in it" is a pretty poor argument.
>I encounter mostly language-oriented
Where are you encountering them? And are you sure you aren't just misinterpreting "practical" blog posts as "academic" because they mention something you don't want to hear like monads? Even most things I would assume you classify as "language-oriented" are still about solving practical problems.
That might sound scary to people who don't know haskell, but it is about solving a common issue with web development (and other server type programming) in a nice reusable library. Do you really think there's tens of thousands of people just sitting around writing haskell code that does nothing for no reason?
It would be interesting to define product as "dollars produced" or something of that sort. Then rank languages by net product and then by net productivity (net product over time).
I would expect it all to be heavily skewed towards high volume trading.
It seems like a lot of people love to hate PHP, and I am not the biggest fan of PHP myself but some of the arguments are a bit off. My current consultancy focuses on coming into companies in a last ditch effort to fix problems with startups, generally after they have failed some sort of technical due diligence when being sold. I get a fairly even mix of most languages (Ruby, PHP, Python, .Net, Java) and they all have problems in the wrong hands.
In 2014 (so very recently, this year), I was brought into a company that was just about to be sold and failed a technical due diligence. One of the red flags was that most of the engineers were in the process of leaving having "accomplished a dream and sold their amazing system to a large organization". They left for really big, well known companies rather than finish the technical due diligence and take an aqui-hire position.
A look at the code showed why. While these were all honestly rather Senior level engineers, they had written some of the most horrible Ruby, JRuby, and Clojure code I have seen in my career. Often it seems they decided well known and good frameworks were just "not good enough" so they decided to write and not maintain their own. Their list of technical sins was quite long but the last I will mention is that they never could decide, from day to day, what the right architecture was, so they just changed it, over and over, on a whim.
The point of this story is, languages don't write poor code, engineers do. I know that people will say, "But PHP has an ecosystem of Junior developers just picking it up and pushing out bad code and never really learning." This may be true, but it's actually just as true with Ruby, Python, .Net, and Java. Those languages, Ruby and Python in particular, are just much better at the PR game of making themselves look "more mature" than PHP is.
tl;dr humerous Haskeller takes steaming dump, rejoices; one may think that one is not being productive, and yet one's actual productivity sky rockets, whereas in other languages (exception, LISP) one's actual productivity is less than one feels, especially in the case of PHP where delusion apparently reigns.
Seems to be a riff on the text editor comic graph where emacs morphs into dragon-eating-its-tail recursion as one approaches unreachable mastery [1]
Say what you want but PHP is one of the most Rambo-bad-ass languages I've ever used. You toss everything to the wind if you want and you will still get a working product.
Few languages have that sheer "Survive" feel to it. For that alone I think PHP should be celebrated. Note: I'm not a PHP developer.
I think that most of the things people hate about PHP are the things that make it work. It doesn't force you into a particular paradigm, and it all but encourages mixing PHP and HTML together into one horrifying but incredibly convenient stew. It doesn't force you to write clean, elegant or secure code (you can, but it doesn't hold your hand in that regard.) A lot of it is still just wrappers around c. You're not chained to a package manager (although you can use one if you want) or a framework (although you can pick one of many.)
And yet, for almost everything people want to do when they want to put something on the web, it's not only perfectly adequate, but in some ways more efficient than other languages. Most of the web is still CRUD anyway. Take stuff from a database, iterate it, insert it into html, serve html. Or maybe do all that, and serve json instead. This is still far, far easier to do in PHP than it is other languages.
That said, as a professional PHP developer, there is still plenty about the language that drives me up the wall. I think anyone who works with it and is serious will admit there are issues with the language. But no one can say it isn't battle-tested, or that it doesn't make it easy to get something up and out onto the web.
> You toss everything to the wind if you want and you will still get a working product.
This is actually the reason that I recommend Haskell for startups. As another commenter said in this thread it gives you a line of technical credit so to speak. This is mainly because the type system and referential transparency (pure functions) makes it so easy to refactor and be confident that your code is still working.
PHP is just a language that so many of the so called programmers here like to bash. I doubt many have even used it, they take a quick look at the hello world and just write it off. But in reality, the language makes so little difference to most projects, it's more about the ecosystem, the jars for java, the packages for python, these are what propel a language to productivity highs. Imagine python without BeautifulSoup or numpy or scipy or any of a hundred packages I use daily. Imagine Java/scala without Mahout etc etc. The actual syntax is almost irrelevant to anyone that can articulate good software design in code.
It's like giving a pencil to Picasso and suddenly implying anything he draws will be shit just because he's not using paint. Utterly ridiculous arguments by the pseudo intellectuals here trying to convince themselves how smart they are for using Haskell. Meanwhile, real software developers just get on with writing good clean code in whatever language they want.
Sure, FB uses PHP but it's also very interesting to see how they've created things like Hack and Flow (built using OCaml, iirc) to improve the quality of their code.
This is the common rebuttal of PHP jokes - but pointing to a sole outlier is rarely a solid defense. Especially when they have created Hack[1] and HHVM[2]. So it's not entirely accurate to say they "use PHP."
>This is the common rebuttal of PHP jokes - but pointing to a sole outlier is rarely a solid defense.
Sole outlier? Hardly. Half of the web is powered by PHP, including tons of websites with huge traffic and usage.
>Especially when they have created Hack[1] and HHVM[2]. So it's not entirely accurate to say they "use PHP."
Hack and HHVM do not show some inherent PHP issue that something like Ruby or Python would not have.
Hack is mostly an attempt to add type checking/hinting to PHP. The lack of type checking would be the same if they used Python or Ruby or Node+JS or whatever.
And HHVM is an attempt at a speedup, to work at Facebook like economies of scale. Considering that plain PHP is on par speedwise with Ruby and Python, that's again not something that would be saved using those other languages. Which is why Google tried to do Unladded Swallow (for Python), Dropbox does their own thing, RoR companies invest hard on speeding up Ruby/Rails, etc.
TL;DR: Hack and HHVM may be proofs of some lack in PHP for Facebook uses, but are not proofs of PHP lacking things compared to other similar languages like Python and Ruby.
> Sole outlier? Hardly. Half of the web is powered by PHP, including tons of websites with huge traffic and usage.
Quality > quantity (just because a language is widely used doesn't mean it's well designed), a huge amount of this quantity are WordPress blogs, MediaWiki sites, or relatively low traffic e-commerce sites. It is not the dominant language of "tons of websites with huge traffic and usage."[1] [Facebook and Wikipedia are the notable outliers...so I'll admit I shouldn't have said sole outlier]. The "quantity" argument is also weakened by the fact that websites are not the only things programming languages are used for, and in terms of overall popularity it's use is a fraction of that of C or Java.[2] PHP also has far less job openings than Java or C# and only slightly more than Python[3] (I imagine Python will eclipse PHP fairly soon).
If you're interested in why so many developers consider PHP a poorly designed language I'd suggest reading PHP: a fractal of bad design[4]
> Quality > quantity (just because a language is widely used doesn't mean it's well designed)
I'm friendly to the argument that there are often better things than the popular things (and specifically things than notable advantages over PHP for developing software), but not to any pretense that PHP isn't "well-designed."
As far as I can tell, it's well-designed as a tool for moving in small conceptual steps from static web documents to dynamic documents to (nowadays, for those who want it) well-organized apps on easily available commodity hosting. There's little that competes with it here in terms of the deployment story and ease of the first part of the learning curve.
Moreover, despite the collection of warts and WTFs, it offers more or less the same commonly-used abstractions in its celebrated scripting siblings. Yes, yes, I know, there's all these differences -- you miss the syntax or Tennent correspondent blocks or monkeypatching or whatever is important to you. Rock on with that. Just don't be surprised when choosing PHP over Ruby or Python doesn't seem to turn out to make a difference between success and failure of a product/project.
> I'd suggest reading PHP: a fractal of bad design[4]
Like most good hit pieces, there's some truth, but it suffers from the focus illusion among other things.
> Half of the web is powered by PHP, including tons of websites with huge traffic and usage.
What powers the web: web servers or web sites/applications? If it's web servers then your claim that half of the web is powered by PHP is false because I'm—and I'm going to be honest here—yet to see/use a web server written in PHP.
I don't think that's a fair interpretation of what was meant by that quote. I think the point was that PHP has been used to great effect, regardless of what shortcoming it may have.
> Web servers would just server static sets of pages without some means to run dynamic code.
Web applications respond to requests. That's all they do. Web servers parse those requests and deliver responses appropriately. You're reducing the role of all intermediaries (DNS servers, caches, etc) and unfairly praising the web application. The web server serves both non-changing static files and the generated documents.
Facebook choosing to improve upon PHP is still, arguably, a (weak) argument for PHP as a language which is, at least, worth improving upon. Given their money and resources, they could have chosen to abandon it entirely, but they didn't. Maybe a more accurate form of this argument would be "Facebook still doesn't entirely hate PHP."
And even so, there are obviously plenty of sites, and even startups, using PHP, but facebook seems to be the goto for PHP advocacy in sort of the same way that a certain ranty blog post is for its detractors, neither of which really requires much effort to employ, or counter.
> Facebook choosing to improve upon PHP is still, arguably, a (weak) argument for PHP as a language which is, at least, worth improving upon.
Or you can look at it another way: Facebook regretted their decision and PHP potentially made the switch to a different platform so hard that they were forced to improve the language, rather than leave.
Don't forget that companies need to be able to justify the cost of moving from one platform to another. When you're employing people whose skillset is potentially limited, that's not always possible.
That's possible, although i'd expect a company with Facebook's resources to be able to justify a move more easily than others, if PHP turned out to be a bad enough decision to really matter. It's still one of the names practically anyone would want on their resume, so they wouldn't exactly be unable to find developers in any language they chose.
You're severely underestimating how much lock-in there is to a platform once you choose it for a product and your entire company is built around that one product.
The amount of effort needed to rewrite Facebook is insane. To rebuild the entire site, migrate the data, ensure everything is seamless to the users, fire all the now-useless employees and replace the workforce (with all its own re-training costs)...
A company like Google can gradually phase out languages they use in favour of others because they can prototype things in new languages in other products they own (Think Dart and Go). A one-website shop just does not have that option.
Fair enough. I've never worked for a company that actually decided to switch, much less one close to the size of Facebook. My assumption was just assumption.
HHVM is a different implementation,while Hack is a superset.
Now why,with the tons of money they have,they chosed to stick with it,I dont know. But it's 100% accurate to say they have some PHP code powering their website. But I bet they have as much java code deployed,and next to none haskell.
I admitted in another comment[1] that I shouldn't have said sole outlier.
But I find it surprising you're defending PHP if you feel popularity of a language is determined primarily by how well designed it is, as by that logic C and Java are way better than PHP.[2]
I am working on a commercial SAAS application written in Haskell. I have been programming computers since 1980, with solid experience in at least a couple dozen programming languages. I chose Haskell for this project because of its programmer productivity and runtime performance. I have not been disappointed. I am always amazed at how little code it takes to get things done. The Achilles Heel of too many languages and their implementations is concurrency support. Haskell had that problem licked ten years ago. Once my code compiles, I know it has few remaining bugs. It runs fast and there are enough good third party libraries to meet my needs.
So what's not to like about Haskell? It has a brutal learning curve. Not so much because it is hard, but because it is different.
If something hurts my brain, I don't want to do it; I don't care about the long-term benefits. Most humans feel the same way and that's why Haskell will never become mainstream.
No, it's not. Software developers are human. Being a professional does not always override human nature. Statistically, most "professional" software developers will not want to adopt a language with a high cognitive load.
And rightly so. Frankly, I think the only reason PHP keeps floating on is the inertia it has. All the investment in tools, existing codebase and developer experience are what keep it going, not language merits.
And yes, this means, that whatever you invest in, be ready to abandon it and move forward, preferrably sooner rather than later. After all, langauges are nothing but tools. Don't take them personally.
>And rightly so. Frankly, I think the only reason PHP keeps floating on is the inertia it has. All the investment in tools, existing codebase and developer experience are what keep it going, not language merits.
Considering the alternatives PHP is not bad at all. It's not like Python or Ruby are some pinnacle of language design.
It's main BS is a polluted default namespace, incosistent function naming, and a few semantic inconsistencies. It's not like any other language doesn't have its share of BS.
Plus what it lacks (a proper AST etc) it's getting. It has been improving ever since 5.0, and fast. Including getting a vast speed increase with 7 that will leave Python and co in the dust.
Well, it has closures, interfaces, dead easy reflection, traits, namespaces, etc etc, speaks to tons of systems, includes tons of batteries, has a great dependency manager, is dead easy to deploy, has a huge ecosystem and good tooling, etc.
The stigma around Haskell is quite unfortunate. Most complaints that I've heard leveled at Haskell are variations of "it's too academic". Given that those complaints usually come up when one is tackling abstractions like Functors, Applicatives and Monads, it would seem that the true sentiment is that "Haskell is too abstract".
Interestingly, I have yet to hear someone complain about abstractions like Collection, Stack, Dictionary, or looking at the ever popular OOP abstractions Class and Method.
Why is it that OOP is widely accepted[1], and yet Haskell-like FP has yet to take off? Well, I think I have an explanation for why this is.
The abstractions commonly used in Haskell are perhaps a bit "more abstract" than those seen in most OOP programming. Most people can intuit the value of collections/classes/etc., and those that can't are pushed in the right direction by the majority of the industry.
Compare the situation of popular imperative languages to that of Haskell: the utility of the former is easily acknowledged and has the support of the industry, whereas the latter is harder to fully appreciate without investing some time and has the industry actively suggesting that the abstractions are useless.
Haskell-like FP is, unfortunately, where OOP probably was when it was still "the new thing". "Why would anyone use this? Classes, interfaces, methods, messages... Too academic!"
And then OOP picked up momentum as people discovered the utility of encapsulated state, programming to an interface (instead of an implementation), the ability to isolate the System Under Test via mock objects... And then those that tasted the benefits worked really, really hard to shift the mindshare of the industry to accept these abstractions as "good things".
I hope Haskell et al will get there some day. The thing is, ideas like Monads are incredibly useful - just as useful as any of the more popular abstractions. They're just one more tool in the toolbox - if you don't know them, you might be missing out.
In an attempt to dispel the myth that abstractions common in Haskell are academic and useless for professional programming, I would ask one thing of you: please, please, please watch Tom Stuart's talk "Refactoring Ruby with Monads" (given at Barcelona Ruby Conference 2014): https://www.youtube.com/watch?v=J1jYlPtkrqQ
The abstractions are useful. Yes, just like any of the abstractions that you may have already mastered, they do take time to learn. It's an investment. I know the payoff might not be immediately obvious, but I promise that it's right around the corner. There's a practical, pragmatic reason Haskell is being used to great effect at places like ThoughtBot, Facebook, Skedge.me, and more.
[1] This is almost a given now: recruiters have often quizzed along the lines of "why is OOP a superior paradigm?"
I think the fact that Ruby didn't even make the list tells a lot about how far it has fallen in terms of mindshare. I have nothing against Ruby, its people or its ecosystem, but it's beginning to seem like a bit of a flash in the pan.
Peaked in 2009, now down to a third of that popularity. Other measurements might give you different numbers, but the same trend. As I said, I have nothing against Ruby, but it just doesn't seem to be holding its position.
How about C# vs F#? Both have great support. You'd think if people were 2x-3x more productive in a functional language, you'd get a lot of developers moving from C# to F# because both have excellent support from Microsoft.
Monads are a construct from category theory, and one with a particularly significant use in idiomatic Haskell, so I'd expect learning Monads as used in Haskell to generally precede a broad understanding of category theory for most Haskell programmers.
I'm productive in Haskell and I don't know category theory. I didn't "learn" monads specifically, I used them in my projects and gained an intuition for monads followed by memorizing the 3 monad laws.
I wasn't asking for any distinction from "a deep understanding of category theory". Neither "learning monads" nor "memorizing 3 rules and building intuition" stands a chance of being identical to that, though.
Yes. Continuing beyond monads to learn about category theory is mostly because it is interesting. It is definitely not a prerequisite.
The historical relationship is that Eugenio Moggi wrote a paper in 1988 "Computational lambda-calculus and monads" http://bit.ly/1x9uUHQ that used ideas from category theory to handle the semantics of programming language features. His problem was that the lambda calculus itself failed to adequately handle certain "notions of computation" such as side effects and non-determinism. This inadequacy goes way back to the origins of programming language semantics, starting with Peter Landin's 1964 paper "Mechanical evaluation of expressions" http://bit.ly/1rrBit3. He described a virtual machine (SECD) for evaluating lambda expressions, but had to add special constructs for handling assignment and jumps. In case you don't know what semantics is about, imagine that you had two small programs written in two different languages. How would you determine if they were the same? One way would be to demonstrate their equivalence to a common, mathematically sound, language. That's what Landin used the lambda calculus for. But it's only good for a subset of what we understand computation to be (particalurly what a Von Neumann computer is capable of doing).
That's what prompted Moggi to look to a more encompassing branch of mathematics -- category theory -- to describe semantics. In 1991, he wrote "Notions of computation and monads" http://bit.ly/1viXT6z, which is much shorter and more accessible, but essentially the same as the previous paper. Philip Wadler, one of the original authors of Haskell and long-time functional programming researcher and educator, was inspired by Moggi's work to write (several times) a tutorial showing how Moggi's "monads" could be applied to the restrictions of functional purity. For example, to simulate the incrementing of a global variable representing a counter (of some operation), one could use a "state" monad.
The monad of Wadler (and Moggi) is really pretty simple. First, you need a way of representing one of these notions of computation. In a programming language, this is done with types. Or to be more precise, a 'type constructor' since you will want the computation to be general. For instance, if your computation changes state (eg the counter above), you might want to construct a function type that given a value, takes a state (eg integer representing the counter variable) and returns a tuple consisting of the value and some new state. I should point out that my last sentence is what makes monads so confusing and challenging in languages other than Haskell. They don't have a nice way to represent what I just said. To use Wadler's notation:
type T x = S -> (x, S)
The second component of a monad is a function that takes a value and returns a "computation" (ie, the type described above). And the third component is a function that takes one of the computations and a function from a value to a computation and returns a computation. That's a mouthful, and it requires the language to support polymorphic types and higher-order functions. If your language does not or doesn't provide good syntax for them, then monads will be an elusive and difficult concept. But as you can see, a monad is just a pattern made up of these three things. That's all ... almost.
Because of the relationship to category theory, a monad (consisting of the three components) must also obey certain rules for how these operations are expected to behave when combined in certain ways.
In fact, monads are pretty cumbersome to implement, especially when there isn't good syntactical support in a language. But they provide a general solution to certain kinds of problems which is functional in nature.
Bad programmers are bad no matter the language... Why you don't waste your time writing an interesting post of your preferred language instead of make jokes about another ones? Maybe the answer is that you can't even write a line of quality code... you people the Nelson Muntz of code..
Callbacks in Javascript make you feel more productive, but in fact you become less productive.
Design patterns in Java don't actually make much of a difference in productivity, but you think they do.
Templates in C++ seem hard but with a big payoff, but they don't accelerate productivity.
Unit tests in python do make you more productive, though it doesn't feel like it. Decorators on the other hand do not make you more productive, but they make you feel more productive.
In Lisp, macros accelerate both the feeling of productivity and actual productivity.
In Haskell, once your brain stops hurting you become productive. When you learn monads, your brain will hurt for a bit. While your brain hurts, your productivity declines. Once you get past understanding monads, your productivity grows at roughly the same rate as it did before you knew monads (in other words, monads do not accelerate productivity). Then you learn category theory, which has no bearing on your productivity but makes you feel less productive.
PHP is a bit of a cheap shot, stating that you won't become more productive over time but you will always feel super productive.