Learning Curves for Different Programming Languages

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.

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.

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.

You should kill that misinformation with some Haskell experience ;)

> 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.