Comment by RyanZAG | Hacker News Reader

Comment by RyanZAG | Hacker News Reader

Parent Full thread

Readable to you after years of study of the CS principles and languages behind Haskell, but literally unreadable and undecipherable to the majority of current programmers. This is a major problem, even if you choose to ignore it and remain in an ivory tower.

That said, the actual problem described in the article has this issue at the very core - we have more software we need written than we have people who can write good Haskell. This means that a large percentage of software is going to be written poorly - and the only real solution would be to simply have less software.

Supply-Demand overrides this completely, and so bad software will remain. The true challenge is therefore making software that can be written by the semi clueless and yet still be decipherable enough to maintain. Java and C# seem to have cornered this market to great effect in the business landscape from my experience.

I think current language development trends towards functional programming is a mistake as it caters to such a tiny audience, and more emphasis should be placed on new languages that can force people to write good code.

Is this possible? Dumb example: If someone is hacking together computations of circles without knowing about PI, is there any possible way for a language to help here?

I think a language that can make it clear what the code is trying to do, even when written by someone who has no clue, would go a long way to being able to filter out and fix bad code quicker. If your code is in Haskell, it's going to take a lot of effort to work out what bad code is even trying to accomplish.

I disagree. In my experience, competently written Haskell is quite clear to most competent programmers.

I interviewed for jobs a few months back. When people asked me "solve this puzzle in any language you like", I usually used haskell. The solutions were just simpler and cleaner in Haskell than in Python/Java/etc. Apart from minor conventions they were unfamiliar with (e.g., "What's Maybe"), not a single interviewer had a problem understanding what I did, even though most had never used Haskell.

One company even had me demo some code I wrote (great interview technique, BTW), and I picked a Haskell project [1]. They literally stopped my detailed verbal explanations and told me: "no need to explain getFileHandleOrNothing, this all looks pretty clear and obvious. The only thing we needed an explanation of was your monad, the rest is clear."

You advocate that more emphasis should be placed on new languages that force people to write good code. That's what Haskell and other FP languages do.

[1] https://github.com/stucchio/Mp3FS

So you find the (far more real world) code of Inufu unreadable?

Edit: actually when interviewing people I show them some Haskell code and ask what it does. Most of them do, some answer that they don't know the programming language. Of course I don't give them very difficult stuff, but still; a lot of well written Haskell code is incredible readable, even for people who never saw it. Also, I really assume if you have a CS degree that you played around with functional languages and recursion. My disappointment with a certain country was that almost none (and I interviewed 100s in the past 10 years) of the Masters of CS from that country even have a clue what recursion is, let alone functional or logic programming languages.

Would something like the above code be on your interview? (pow = 1 : [ 2*x | x <- pow])

I'd probably fail it even though I do understand recursion. I don't know Haskell, and the above is rather cryptic to me. I can infer that it raises 2 to a power, but I'm not sure how it works -- both in how it's called (does that define a function? Pow(4) --> 16?) and the why (the last part defines the recursion I assume, but what happens when you need multiple args, and what does it mean?)

If the interviewer is not giving the opportunity that the code is just plain wrong and assures it's correct (which I say upfront) then people can be 'wrong' saying it takes an argument x and get the 2^ or it prints the number of 2^argument or that it will just infinitely loop. All of these are fine with me; you read the code and at least got the gist. It's not brilliant because the list comprehension looks like most list comprehensions in other languages so then you can know pow makes a list which elements are (ordered) 2^[1..n] numbers.

Edit: But to answer your question: yes, I would like to be asked. I did a lot of interviews from the employee side just because I was curious, and, at least in the Netherlands, they never gave me a test. Just looked at my (possibly fake if I wanted) credentials and said yes/no. No tests, at all.

Partially true, it has taken me a long time to learn haskell. However if you want to learn anything there is some upfront effort involved.

I don't get to write haskell at work, but I see its principles everywhere with an additional layer of cruft over the top. Examples include doing functional style programming in python, linq in C#, passing around functions and callbacks in JavaScript and trying to reason about side effects.

Reply on news.ycombinator.com