Hacker News Reader

Comment by boothead | Hacker News Reader

I about 50% agree with you here. The factor that you're forgetting is the filter effect: Haskell is not adopted, it's learned after a thankless (there are no jobs) process of deep study. This means that the quality of available talent is of a much higher standard. If you adopt a technology with these characteristics, and you're one of the few who are hiring in this pool then you have a significant advantage!

The only risk in my mind is when the big boys figure it out and start gobbling up Haskellers! :-)

View on HN

Author here.

We've trained a few people up on Haskell at IMVU now, and I'm starting to think that learning Haskell is at its very hardest when you're building tiny toy applications and all you have for answers are google searches and books.

It seems to help a lot to root the learning process in a specific concrete goal, in an existing codebase that already has idioms and patterns in-place, and to offer direct access to people who have answers to newbie questions.

I'm really enamored with haskell, and you're hitting on exactly the problem I'm having.

Any advise on learning haskell out in the wild?

Hard work and practice in your spare time. Probably not what you wanted to hear, but that's the way most people do it.

Find a project to work on and someone to mentor you, talk to people at on #haskell and the mailing lists and at meetups.

I learned a lot about writing good Haskell code from working with Yesod. Since it's a framework it structures your code for you and exposes you to a lot of well-designed patterns. Yesod and Conduit are two of the best written packages I've come into contact with (though there are many many more) and simply following their guides has given me new insight into what high-quality Haskell code should look like.

I think this is a bad filter. I'd rather filter prospective employees based on an ambitious algorithm or a complex project they've done. Most of the people I know that like solving hard problems with novel data structures, algorithms, or mechanically-sympathetic implementations are averse to spending time on learning new programming languages. It seems to them (and to me) like focusing on bling rather than on substance.

Of course, this is a crude generalization, and obviously, anyone who's interested in learning any new, perhaps unappreciated, and difficult skill would make a good hire, and Haskellers are no exception. But I wouldn't filter based on programming language preference.

Wow, completely the opposite experience here. The majority of the prog. lang. enthusiasts I know are deeply into other aspects of computer science. They love high level languages because they can express their ideas so cleanly. Lots of devs are drooling over Rust because it allows us clean code with C-level control over memory layout and allocation.

The majority of PL enthusiasts might well be interested in other aspects of computer science, but I was pointing out the the converse isn't true: the majority of people interested in the more challenging aspects of comp sci are not necessarily interested in programming languages, which is why this would be a bad filter.

I drool over Rust, too, but I wouldn't switch my company's (little) C++ code to Rust tomorrow. Also, Rust appeals mostly to C/C++ programmers, who don't usually need as many OSS/OTS libraries as application-level programmers (and those, usually specialized, libraries they do need, either work with Rust or don't; if they don't, that alone would be a deal breaker).

People who risk their company's investment (or make any important decision) based on stuff they drool over, might need to get their priorities straight.

"Rust appeals mostly to C/C++ programmers"

As primarily a Scala programmer, Rust appeals greatly to me. It's basically the same language without cruft inherited from Java, and its much more amenable to optimisation that Java. For example, large heaps have unacceptable GC pauses, so projects like Cassandra invest a lot of effort into "off-heap" memory management (i.e. manual memory management). With Rust that just works a whole heap better (pun intended).

People tend to talk about "expressiveness" when discussing programming languages, which usually mean concision. I'm much more interested in what I call "expressive width", which means how high- and low-level can get in a language. PHP is little expressive width, because its runtime is so poor. Scala has good expressive width because I can play with threads, CAS operations, mem-mapped files, and even manual memory management (which is going quite far off-piste, but possible with sun.Unsafe). Rust has even more expressive width than Scala.

[Rust needs higher-kinded types before it will truly make me happy. I believe they'll arrive soonish.]

For your other points:

- P(interested in PL | interested in CS) != P(interested in CS | interested in PL).

Agreed, but I don't think it matters. Anyone interested in discrete maths (so, CS) will pick up Haskell quickly.

- "People who risk their company's investment (or make any important decision) based on stuff they drool over, might need to get their priorities straight."

Depends on your company's size and ethos. I'd rather have a few great people than a room full of monkeys, but I understand arguments that go the other way.

> I believe they'll arrive soonish

Depends what you mean by soonish... there's certainly no concrete plan for how to implement them yet (or even a vaguely sensible proposed syntax).

Many of the super programmers at google have PL research backgrounds! Like Jeff Dean. Most of the others are in systems, which are fairly aligned, and often both. Such PL enthusiasts are the last ones to try and switch the language being used.

> Such PL enthusiasts are the last ones to try and switch the language being used.

As a PL enthusiast myself, I agree with this.

By the time I had my first job out of college, I'd written programs in some twenty-odd different PLs, and felt comfortable with many of them. My employer needed me to learn SAS, so I did. They wanted some code written in Java, so I wrote it. Neither SAS nor Java is particularly fun to program in the way Haskell et al. are, but that's what they wanted, and I could do it.

There was a whole team of Java guys, and when asked to learn SAS they sat around bemoaning it and whining about how Java is so much better. "Why not just do it in Java?" they asked.

I've run into similar experiences at every company since. If people don't want Java, they want C++ or Perl. If someone writes a utility in Python, there are complainers. Some programmers will refuse to even use a particular program if it's not written in their language of choice.

In my experience, it's usually the people who aren't PL enthusiasts that are more opinionated about language choice, simply because they're less flexible.

That means it's a great filter, though, in one way—it has high precision but low recall. If you're building a smallish team on a lowish budget then precision is vital and recall isn't.

Assuming the remaining population is sufficient (which, for Haskell, for a smallish team, in a job that can be done remotely or is in a tech hot-spot, it probably is).

I'm a Haskell user and I find Rust really interesting. I know a goodly number of other Haskell users who are also interested in Rust too.

I don't think you're speaking from a lot of knowledge here.

> Rust appeals mostly to C/C++ programmers,

There's actually a lot of people who aren't coming from C++ too. A whole bunch of Rubyists are checking out Rust, for example.

That said, you're totally right that production Rust is probably a bad idea. You'd be user #4!

Haskell was inflicted on my whole CS class, and for that class P(avid problem solver|likes haskell) was mighty high.

As long as you can sample from a decent talent pool, I think it's a good filter. (Provided you only care about your outcome, not fairness to job seekers.)

I have to disagree on two points.

First, the implicit point you are making that ambitious algorithms or novel data structures are useful in industry. For the vast majority of applications this simply isn't the case.

Second, the argument that people interested in learning advanced computer science aren't interested in learning new programming languages. This goes against all of my experience; my friends who are most interested in advanced computer science concepts are exactly the ones who spend the most time exploring different programming paradigms as well.

I have one idea of what the distinction might be, though: learning different programming paradigms is very different from learning different programming languages. I certainly wouldn't want to waste time learning yet another Java or yet another Python, since as you say that would be focusing on bling rather than substance. If this is the distinction, Haskell comes out fine, as it is clearly a different paradigm from the mainstream languages.

learning another script language is totally different from learning Haskell. For the latter it requires much more than syntax translation, which is implied in your comment.

> I'd rather filter prospective employees based on an ambitious algorithm or a complex project they've done

I've never needed the former, and only have a little bit of the latter. I wish I had more of both, but I find I have to do hard stuff on the side.

What do you do, exactly?

This is my worry with Python. Its a good language, but it is too easy to learn.

I ofter read that Python developers are of a higher quality than PHP developers.

So downvoters, how do you differentiate a good coder who chose the language based on features and reputation, over a poor coder, who chose it "because its easier than Perl"?

The point I am trying to make is that I think there are benefits to having a higher bar to entry.

If you hang out a lot on reddit, this particular site is written in python, so there might be a bias. Python is also often chosen for entry courses in CS, while PHP is probably more picked up by people who need to know it for work, so it is not necessarly well understood by many of its newly professional users.

My guess is that python is a more well rounded language, with a nicer syntax, which enforces indentation rules (that's a plus for teachers). PHP only shows its merits after a while, and through good practices.

However, looking at the charts over at langpop.com, I don't see how people would choose PHP over perl for its easiness, given the wide difference of popularity. They just don't sit in the same ballpark (except for maybe a few specific markets).

I usually look at their code, which is often a good indication of whether they are a good coder or not.

I think it is pretty safe to say that the average quality of PHP developers is lower than any other language except possibly javascript. There's a huge amount of very low knowledge people in both camps dragging the average down. Comparing python to ruby or perl things seem pretty similar.

I've been hiring both Python and PHP devs. It's absolutely night and day difference.

I don't think you need to worry... YET.

1. Python is simply a superior language.

2. There isn't currently a "WordPress" type of project that is bringing in droves of awful Python coders.

Will it eventually turn sour? If things continue with Python, I think so. But the language and community will do a good job keeping things slightly sane. I think the Python community understands the importance on both fronts. Sure, bad programmers are everywhere. But bad contributing programmers need to be kept at bay and out of our favorite GitHub repo's.

In my experiences as a solo founder needing junior-level programmers, Python is currently in the perfect sweet spot for adoption vs. quality. It's largely up to us in the community as to how long that will last.

Python tries to make it easier to avoid pitfalls. In contrast to PHP or Perl, Python believes that

> There should be one--and preferably only one--obvious way to do it.

Even something like significant whitespace forces everyone to format their code similarly.

That's not to say an incompetent programmer can't write horrible code in Python, just that Python tries to make it easier to do the right thing than the wrong thing.

Which makes it quite ironic pg dubbed this phenomenon the "Python Paradox".

http://paulgraham.com/pypar.html

Reply on news.ycombinator.com