Learning Curves for Different Programming Languages
github.com
github.com
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.
Wordpress, phpBB, Drupal, IPB, Joomla, vBulletin, Facebook, Yahoo!, DeviantArt, etc...
Now PHP making you a better programmer... that's a different matter.
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.
Lack of labeled axes.
Without labeled axes there is no sensible reading between graphs.
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.
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.
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.
(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").
But you're talking more about products than programming languages. Haskell contributed a LOT to programming theory.
Your every day coding is most likely using things coming directly from Haskell without you knowing it.
This is a feat in and of itself.
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 despise that people give their 2 cents for something they haven't experienced much.
>I have ... very little experience with Haskell
So, how would you know?
Do you have experience using haskell? If not, you are being hypocritical. Please stop.
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?
It seems rather hard to evaluate the tail end from "little experience".
Not always true, sometimes you can have a fairly good picture of something after a short time.
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.
* Statically safe metaprogramming.
* Well designed access rights (private, public).
I also really like the type system, very well designed.
Disclaimer: I do not have enough PL type theory under my belt to confidently make this argument.
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.
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).
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 don't understand why mechanics say some cars are better than others.
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.
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.
[1]: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
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.
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.
TLDR; Just ranting.
On top of that all three of those languages require additional setup. (Especially Ruby with RoR shudder)
Additionally, the mysql_ extension is deprecated since PHP 5.5: http://php.net/manual/en/migration55.deprecated.php
The official docs on the old mysql_ extension has large warnings advising people not to use it: http://php.net/manual/en/function.mysql-connect.php
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.
> 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.
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.
-- Maya Angelou
If PHP had moved on, it wouldn't want to be PHP anymore. Those haters have moved on: they did so when they decided to not program in PHP anymore.
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.
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.
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.
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.
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.
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 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).
</rant>
So it seems your sarcastic rant completely misses the mark.
Disclaimer: not a haskell, nor a php programmer.
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.
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).
Perhaps someone from industry can confirm my feelings here.
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).
edit: sorry, this was pretty defensive; I shouldn't have written this comment so hastily.
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.
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.
[1] http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...
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]).
[1] https://github.com/TechEmpower/FrameworkBenchmarks/commit/9e...
[2] https://github.com/TechEmpower/FrameworkBenchmarks/issues/12...
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.
(An aside: Esqueleto isn't anywhere close to typesafe, nor does the author claim this is one of its goals. It is trivial to produce crashing queries: https://github.com/prowdsponsor/esqueleto/issues/41)
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).
It was previously discussed on HN here: https://news.ycombinator.com/item?id=7472452
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".
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.
http://ro-che.info/articles/2014-12-26-monad-control-type-sy...
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?
I would expect it all to be heavily skewed towards high volume trading.
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.
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]
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.
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.
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.
It seems overly critical, but still funny (the Haskell one is probably the most spot on)
And after all, Facebook uses PHP and MySql
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."
[1] https://en.wikipedia.org/wiki/Hack_(programming_language)
But they grew on PHP. Those tools came to be after "a lot of time"
And of course they're not the only site that uses PHP (see all the Wordpress installations, etc)
So yeah,they basically use PHP.
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.
That's like saying applications written in C++ are "basically C" or Groovy is "basically Java."
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.
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.
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.
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.
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.
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.
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]
[1] https://en.wikipedia.org/wiki/Programming_languages_used_in_...
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
[3] https://gooroo.io/GoorooTHINK/Article/16191/Which-language-w...
[4] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
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.
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]
[1] https://news.ycombinator.com/item?id=8803088
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
And Haskell: https://code.facebook.com/posts/302060973291128/open-sourcin...
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.
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.
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.
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.
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?"
http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.h...
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.
If all the lines were accurate, would it have been funny at all?
I know a few Microsoft employees who got in trouble for using F# internally.
Similar style charts to that used by Randall Munroe in XKCD.
See also this D3 style for producing similar charts by Dan Foreman-Mackey. [2]
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.
[1] https://github.com/Dobiasd/articles/blob/master/programming_...