5 ms·

The little bit of haskell FUD in this article made me largely disregard the rest (although I've heard my share of horror stories about the software s big financ

The little bit of haskell FUD in this article made me largely disregard the rest (although I've heard my share of horror stories about the software s big financial institutions). Once you get past the different syntax I find haskell code to be extremely readable.

tluyben2 14y ago
Yep, it's a) only syntax (if you cannot get past syntax maybe a you need to get another job) b) a bad example in the article c) an example of how to make code unreadable which goes for every programming language. In general Haskell programmers strive to refactor to a point where you have balance between readable, performant and idiomatic Haskell.
- p4bl0 14y ago
  "Syntax doesn't matter… unless you're a programmer." ~ Rob Pike. I otherwise agree with your b) and c) points.
  - tluyben2 14y ago
    There is no need to torture yourself with insane syntax and I should express that probably differently, but I find the obsession over syntax usually a lack of skills or experience. For instance, there are hordes of programmers screaming they 'cannot do' Objective C because of it's syntax. That's silly.
Inufu 14y ago
Especially since this is obviously obfuscated Haskell. A more readable version: pow = 1 : [ 2*x | x <- pow]
- pdw 14y ago
  Or even pow = iterate (* 2) 1
ps258 14y ago
The code is literally used as an example in Uncyclopedia. http://uncyclopedia.wikia.com/wiki/Haskell#Haskell_Code_Examples http://uncyclopedia.wikia.com/wiki/Haskell#Haskell_Code_Exam... It's like using code from the IOCCC to make a point that C code is not maintainable.
RyanZAG 14y ago
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.
- tluyben2 14y ago
  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.
  - Woost 14y ago
    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?)
Maro 14y ago
I recently learned Haskell and am writing code in it on a daily basis, although I'm still a novice. In my limited experience, Haskell is like any other PL, you can write clean, readable code or a horrible mess. My major concern with Haskell right now is with maintainability/changability of code. One recent example that bit me in the ass was: I wrote an elegant solution to check whether a list of files exists, using sth like foldr (&&) True doesFileExist. Then I realized I really need to print out which file is actually missing, but only the first N to avoid flooding the user with error messages. At this point FP becomes a pain IMO, and it'd be much easier to add a counter variable and printfs in the imperative program and move on. Actually this is fairly common, think about adding printfs for debugging: not so easy in Haskell, as IO changes the type signatures of the function and its callers. So, in my limited experience, changing code in Haskell is expensive and its effect are not localized.
- emgreen 14y ago
  From my experiences with Haskell, it takes a long while to get used to Haskell, but once you do it really pays off, especially in the area of maintainability. It's actually one of the reasons I love Haskell so much. I've been where you are though, and I feel your pain - if you keep at it, it'll get good, promise. Some things I find help with maintainance : * the type system allows the compiler do a lot of work for you, * types have to be concrete rather than abstract, * if a little effort is applied the unit tests can be amazing, * everything's clearly defined, * codebases tend to be a bit smaller, and once you're used to it, more readable. In the particular situation you describe, maybe using the "take" function could work? Yes, the IO stuff can be tricky, I agree, but with practise it's not too bad, and separating IO from pure code gives all sorts of goodness back. There's always Debug.Trace if you need to do a quick bit of debugging by print statements. I feel the article was being unfair on Haskell there, after all the code example was being deliberately unreadable, and that's possible in any language. It's not really that hard: map (2^) [1..]
- michaelochurch 14y ago
  So, in my limited experience, changing code in Haskell is expensive and its effect are not localized. That's a feature, because it protects against spaghettification. Explained here: http://michaelochurch.wordpress.com/2012/12/06/functional-programs-rarely-rot/ http://michaelochurch.wordpress.com/2012/12/06/functional-pr... When a manager walks in with a new requirement, you'd rather be able to do it in 15 minutes than 2 hours, because managerial injections are annoying and you'd rather get back to more interesting work. Sure. I get that. However, once enough hands have passed over code, with hackish fixes thrown in to satisfy dipshit flavor-of-the-month requirements, then if it's easy to inject complexity without consideration of the loss of conceptual integrity, people will do so. What you get over time is spaghetti. It doesn't happen overnight. Almost no one sits down and says, "I'm going to write a bunch of shitty spaghetti code." Spaghetti code is rarely written by one person. It's an "all of us is dumber than any of us" phenomenon. Even Google has some spaghetti code, and I've never met an incompetent engineer at Google. (Project and people management would be a different discussion.) The nice thing about FP is that changing behavior (except for performance) actually requires altering an interface. In a statically typed language, this requires that you make changes elsewhere in the code to accomodate the new information flow. Yes, it's time-consuming, but it also forces you to think about how your change is going to affect the whole system. That's a good thing. Writing code shouldn't be easy, because reading average-case code is impossible. If it takes 50% longer to write code, but the result is that people can still comprehend it at scale, I call that a major win.

tluyben2 14y ago

Yep, it's a) only syntax (if you cannot get past syntax maybe a you need to get another job) b) a bad example in the article c) an example of how to make code unreadable which goes for every programming language. In general Haskell programmers strive to refactor to a point where you have balance between readable, performant and idiomatic Haskell.

p4bl0 14y ago
"Syntax doesn't matter… unless you're a programmer." ~ Rob Pike. I otherwise agree with your b) and c) points.
- tluyben2 14y ago
  There is no need to torture yourself with insane syntax and I should express that probably differently, but I find the obsession over syntax usually a lack of skills or experience. For instance, there are hordes of programmers screaming they 'cannot do' Objective C because of it's syntax. That's silly.

Inufu 14y ago

Especially since this is obviously obfuscated Haskell. A more readable version: pow = 1 : [ 2*x | x <- pow]

pdw 14y ago
Or even pow = iterate (* 2) 1

ps258 14y ago

The code is literally used as an example in Uncyclopedia. http://uncyclopedia.wikia.com/wiki/Haskell#Haskell_Code_Examples http://uncyclopedia.wikia.com/wiki/Haskell#Haskell_Code_Exam... It's like using code from the IOCCC to make a point that C code is not maintainable.

RyanZAG 14y ago

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.

tluyben2 14y ago
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.
- Woost 14y ago
  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?)

Maro 14y ago

I recently learned Haskell and am writing code in it on a daily basis, although I'm still a novice. In my limited experience, Haskell is like any other PL, you can write clean, readable code or a horrible mess. My major concern with Haskell right now is with maintainability/changability of code. One recent example that bit me in the ass was: I wrote an elegant solution to check whether a list of files exists, using sth like foldr (&&) True doesFileExist. Then I realized I really need to print out which file is actually missing, but only the first N to avoid flooding the user with error messages. At this point FP becomes a pain IMO, and it'd be much easier to add a counter variable and printfs in the imperative program and move on. Actually this is fairly common, think about adding printfs for debugging: not so easy in Haskell, as IO changes the type signatures of the function and its callers. So, in my limited experience, changing code in Haskell is expensive and its effect are not localized.

emgreen 14y ago
From my experiences with Haskell, it takes a long while to get used to Haskell, but once you do it really pays off, especially in the area of maintainability. It's actually one of the reasons I love Haskell so much. I've been where you are though, and I feel your pain - if you keep at it, it'll get good, promise. Some things I find help with maintainance : * the type system allows the compiler do a lot of work for you, * types have to be concrete rather than abstract, * if a little effort is applied the unit tests can be amazing, * everything's clearly defined, * codebases tend to be a bit smaller, and once you're used to it, more readable. In the particular situation you describe, maybe using the "take" function could work? Yes, the IO stuff can be tricky, I agree, but with practise it's not too bad, and separating IO from pure code gives all sorts of goodness back. There's always Debug.Trace if you need to do a quick bit of debugging by print statements. I feel the article was being unfair on Haskell there, after all the code example was being deliberately unreadable, and that's possible in any language. It's not really that hard: map (2^) [1..]
michaelochurch 14y ago
So, in my limited experience, changing code in Haskell is expensive and its effect are not localized. That's a feature, because it protects against spaghettification. Explained here: http://michaelochurch.wordpress.com/2012/12/06/functional-programs-rarely-rot/ http://michaelochurch.wordpress.com/2012/12/06/functional-pr... When a manager walks in with a new requirement, you'd rather be able to do it in 15 minutes than 2 hours, because managerial injections are annoying and you'd rather get back to more interesting work. Sure. I get that. However, once enough hands have passed over code, with hackish fixes thrown in to satisfy dipshit flavor-of-the-month requirements, then if it's easy to inject complexity without consideration of the loss of conceptual integrity, people will do so. What you get over time is spaghetti. It doesn't happen overnight. Almost no one sits down and says, "I'm going to write a bunch of shitty spaghetti code." Spaghetti code is rarely written by one person. It's an "all of us is dumber than any of us" phenomenon. Even Google has some spaghetti code, and I've never met an incompetent engineer at Google. (Project and people management would be a different discussion.) The nice thing about FP is that changing behavior (except for performance) actually requires altering an interface. In a statically typed language, this requires that you make changes elsewhere in the code to accomodate the new information flow. Yes, it's time-consuming, but it also forces you to think about how your change is going to affect the whole system. That's a good thing. Writing code shouldn't be easy, because reading average-case code is impossible. If it takes 50% longer to write code, but the result is that people can still comprehend it at scale, I call that a major win.