Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell in Production

felixmulder.com

Post reply on HN
Print view View original

41–50 of 242 posts

Re: Haskell in Production

#41

Post by MuffinFlavored »

foopdoopfoop wrote: post #34
MuffinFlavored wrote: post #9

> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…

Sounds like you've barely programmed in Haskell and don't know what you're talking about. > It is extremely hard to learn Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something. You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started w…

> Sounds like you've barely programmed in Haskell and don't know what you're talking about.

You're right. I do not subject myself to Haskell because I can't fathom a world where JavaScript is less efficient than Haskell.

Re: Haskell in Production

#42

Post by dmitriid »

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

Re: Haskell in Production

#43

Post by tempguy9999 »

dukerutledge wrote: post #27
danharaj wrote: post #18

Earlier quoted context omitted.

Hey you. I'm pretty sure I know who you are :) I hope everything's going well! I definitely agree that there are many examples of ineffective Haskell culture. As a Haskell contractor I get to see how a lot of different shops do things. One thing I can't really tease apart is that most startups have a lot of engineering culture problems, and picking Haskell doesn't inoculate you from that effect. The main cultural iss…

This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that ca…

I had a similar experience with a different language at a startup where one programmer particularly would produce the most horrid code, use new features and libraries where they weren't needed, generally overcomplicate everything. He was smart as hell and made that smartness a liability for everyone else. The bottom line in a business is the bottom line; making money. He didn't understand that at all. No level of abstraction was too high, even trivial stuff. Dumb code that did the job well... dream on.

Re: Haskell in Production

#44

Post by dmitriid »

olah_1 wrote: post #26
rifung wrote: post #13

Earlier quoted context omitted.

> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part

>but what's wrong with the syntax? I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better. http://www.haskellforall.com/2015/09/how-to-make-your-haskel...

Awesome advice! Thank you for the link.

Sadly, the author of “Haskell in production” breaks many of the rules in part 2 and code reads like ascii-art :(

Re: Haskell in Production

#45

Post by tempguy9999 »

MuffinFlavored wrote: post #41
foopdoopfoop wrote: post #34

Earlier quoted context omitted.

Sounds like you've barely programmed in Haskell and don't know what you're talking about. > It is extremely hard to learn Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something. You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started w…

> Sounds like you've barely programmed in Haskell and don't know what you're talking about. You're right. I do not subject myself to Haskell because I can't fathom a world where JavaScript is less efficient than Haskell.

Then keep quiet.

I agree completely with @foopdoopfoop.

Re: Haskell in Production

#46

Post by cuddlecake »

brokencode wrote: post #21
epsolos wrote: post #17

Earlier quoted context omitted.

Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.

To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.

I remember when I started with Java at University.

Like, "hello, what is a method? What the hell is a class? Come on, stop kidding me, objects have methods???? How do I call them? Wait, how do I _write_ a method?"

Re: Haskell in Production

#47

Post by agumonkey »

dukerutledge wrote: post #33
maximente wrote: post #32

Earlier quoted context omitted.

in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. m…

> all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that. Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage indus…

Funny because I see fp as tdd^2 + IO on the side (npi) thus bringing all the benefits you like from oop. Only difference is I think a few decades of culture using these bu default leading to terse syntax and idioms.

Re: Haskell in Production

#48

Post by madhadron »

MuffinFlavored wrote: post #41
foopdoopfoop wrote: post #34

Earlier quoted context omitted.

Sounds like you've barely programmed in Haskell and don't know what you're talking about. > It is extremely hard to learn Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something. You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started w…

> Sounds like you've barely programmed in Haskell and don't know what you're talking about. You're right. I do not subject myself to Haskell because I can't fathom a world where JavaScript is less efficient than Haskell.

> I can't fathom a world where JavaScript is less efficient than Haskell.

You can't fathom a world where a compiler can more easily produce efficient machine code from a statically typed language with very few semantic corners than from a dynamically typed language with lots of sharp corners plus reflection? I think you may need to meditate on the task of compilation a for a bit.

Unless you mean efficient for the programmer, in which case you are mistaking the up front effort of getting things to type check for additional effort. Usually it spares you the same number of iterations in debugging and testing, and the type checker is a lot faster than running unit tests. Plus the first time you make a major refactor to a program by making the change and then fixing everywhere the type checker complains, and that turns out to be it, it all works, it feels like you just mutated into a superhero.

Re: Haskell in Production

#49

Post by weberc2 »

dukerutledge wrote: post #33
maximente wrote: post #32

Earlier quoted context omitted.

in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. m…

> all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that. Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage indus…

> There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc.

I'm not a big OOP fan, but I'm pretty sure Clean and SOLID are principles (or sets of principles), while TDD alone is a practice. I'm also not very familiar with Clean or SOLID, but I'm pretty sure they apply to Haskell as well, and I would expect that Haskell enthusiasts would ordinarily boast that Haskell allows (or encourages) them to write code that is more SOLID with less effort than other languages.

My criticism of Haskell is that there tends to be an obsession with writing the most SOLID/DRY/etc code possible at the expense of productivity. It's a code golf / ego culture.

Yes, this is cultural and not "built into the language" (quotes because I doubt there's a clear distinction between a programming language's culture and the language itself, but that's a debate for another time), but you can't unplug from the culture, because you need the ecosystem to solve any nontrivial problem (so you still have to interface with overly clever code).

Further, even if you could unplug from the culture (perhaps by writing everything in-house under your own improved culture), there are still no 'rails' that encourage naive, flat-footed, dumb code, and that's the kind of code you want 99% of the time. As far as I'm aware, there isn't even a clear standard for writing clear, naive code in Haskell.

Re: Haskell in Production

#50

Post by ben_jones »

foopdoopfoop wrote: post #34
MuffinFlavored wrote: post #9

> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…

Sounds like you've barely programmed in Haskell and don't know what you're talking about. > It is extremely hard to learn Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something. You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started w…

Counterpoint: learning your first language and learning languages later in your career are very different processes and learning Haskell with a background in OOP languages may be harder then learning it as your first.

> Arguments over programming languages often become emotional and skip past many of the practical business concerns that make programming languages valuable in the first place

Post reply on HN