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

Why I never finish my Haskell programs

blog.plover.com

Post reply on HN
Print view View original

71–80 of 228 posts

Re: Why I never finish my Haskell programs

#71

Post by sokoloff »

aidenn0 wrote: post #62

I see this a lot with intermediate lisp programmers; they spend so much time building ivory tower abstractions that the original problem is forgotten. I sometimes call this "bottom down" programming. Predicting the future is very hard; remembering the past is much easier. If you find yourself typing the exact same pattern for the Nth time, then it's time to refactor it into a macro or a function as appropriate. Figur…

“Bottom down” really resonated with me in my dalliances with both Common Lisp and Haskell.

Re: Why I never finish my Haskell programs

#72

Post by yogthos »

dwohnitmok wrote: post #67
yogthos wrote: post #48

Earlier quoted context omitted.

I think the complexity in Haskell largely comes from its advanced type system and laziness. For example, pervasive use of monads in Haskell is a direct result of encoding side effects using the type system. You can't just put a log statement in a function, you have to do a whole design exercise of how to push it to the edge of the application.

Eh... Monads aren't really just about side effects. They're really just a generalization of the threading macros in Clojure (sort of, at least I view them with the same motivation as the threading macros and their cousins in Closure). As for logging, if it's really just a log statement I'll sometimes just do the equivalent of `unsafePerformIO`ing it and not worry about it. All depends on what you consider semanticall…

I agree that monads aren't just about side effects, and lots of languages use monadic patterns. My point was that using monadic patterns is prevalent in Haskell specifically due to using the type system to track side effects such as IO. Clojure has monadic libraries like cats, that let you write Haskell style code, but they're not popular because in most cases you can solve the problem in a more direct way.

Re: Why I never finish my Haskell programs

#74

Post by sverhagen »

thomasfedb wrote: post #60

Writing elegant code that never works can easily take me twice as long as writing okay code that actually works.

You're phrasing that in a seductive way. "Okay code". Maybe that's good enough, right? Maybe not? Someone's "okay code" may be someone else's "bad code". I'm fixing someone else's "okay code" on a daily basis since it's riddled with bugs. Somehow I'd expect that if they would have had the mastery to write elegant code, they may also have been able to make it less buggy, or at least to make it easier for me to fix it.

Also, as with code that's elegant, or well-tested, or specified really well, aside from all those explicit qualities, all of these are also just additional touch moments for the author in question to discover and fix the bugs before it gets handed off, and to become my problem on some future date.

(Not saying you should gold-plate it into elegant code. Just saying that there is value that should not so easily be dismissed.)

Re: Why I never finish my Haskell programs

#75

Post by gizmo686 »

mac01021 wrote: post #28
yogthos wrote: post #26

I definitely find there's a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it's easy to get distracted from solving the actual problem by trying to do it the most "proper" way possible. This is also how you end up with design astronautics in enterprise Java as well where people obsess over using every design pattern in the book instead of writing…

I don't disagree in general but is Haskell a big language?

Haskell 98 is a simple language. Modern Haskell is not. Or, at least, the superset of modern Haskell that GHC implements is not simple.

Re: Why I never finish my Haskell programs

#76

Post by gizmo686 »

hhmc wrote: post #65
KirinDave wrote: post #38

Earlier quoted context omitted.

What? Other than strings desperately needing to be purged from the library, what are you talking about? Haskell has some really solid standard libraries, and it's extended library set has some of the most sophisticated algorithms packages in the world.

I'm not the commenter you're replying to, but I've often found the Haskell numeric classes (Num, Fractional, Integral etc) prickly. The almost , but don't quite, map to (mathematical) algebraic structures.

Having use Haskell for math programming, I agree with this sentiment. Haskell's standard classes are in an uncanny valley of matching the mathametical structures.

If you want to do that sort of thing with Haskell, I would suggest switching to the numeric prelude [0]

[0] https://wiki.haskell.org/Numeric_Prelude

Re: Why I never finish my Haskell programs

#77

Post by village-idiot »

This is me. I have a backlog of personal projects that I've slowly burned through and every freaking time I start with Haskell and end up in Rails. I love working in Haskell ... in theory. In practice I spend way too much time figuring out how to wrangle data into the correct shape when it would've taken me 30 minutes to accomplish in any other language I know, static or dynamic.

Re: Why I never finish my Haskell programs

#78

Post by village-idiot »

hhmc wrote: post #27

I'm reminded of one of my favourite HN comments on Haskell: 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.' https://news.ycombinator.com/item?id=7962612 Although it's not 100% applicable in this case (unless you argue…

Oh yeah, as I mentioned in another comment, this is me. The result is that I have a bunch of 20% finished Haskell projects, and a bunch of finished Rails projects that accomplish the exact same task.

Re: Why I never finish my Haskell programs

#79

Post by zengid »

hhmc wrote: post #27

I'm reminded of one of my favourite HN comments on Haskell: 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.' https://news.ycombinator.com/item?id=7962612 Although it's not 100% applicable in this case (unless you argue…

I think Rich Hickey described it pretty well when he said (paraphrasing from [0]) that static languages present the programmer with neat little puzzles to solve that feels like we're writing applications but we're just creating intricate types and abstractions. I think he has a point, but I certainly don't want to give up the benefits of static languages, like being able to catch all of my silly errors.

[0] https://youtu.be/2V1FtfBDsLU?t=39m44s

Re: Why I never finish my Haskell programs

#80

Post by village-idiot »

dpratt71 wrote: post #50
wtracy wrote: post #35

Earlier quoted context omitted.

Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell: https://haskell-lang.org/tutorial/operators

I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/... ).

On the whole, I consider user-defined infix operators to be a huge mistake. While the few common ones are great, the ability for every single library creator to add their own infix operator turns into a mess in the long run.
Post reply on HN