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

81–90 of 228 posts

Re: Why I never finish my Haskell programs

#81

Post by kuwze »

pka wrote: post #58
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.

http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-... For future reference, this isn’t a good argument for trolling Haskellers.

Right. If you want to troll Haskellers just ask about the runtime.

Re: Why I never finish my Haskell programs

#82

Post by rossdavidh »

I've seen this, and I've never had a Haskell gig. One of the best pieces of advice I ever got re: programming was, "don't write the abstraction until you've written three cases first". This is good advice in the intended way (you will write the abstraction better when you get to it), but even better because you probably often won't ever write three of the thing in question, in which case you shouldn't write the abstraction anyway.

Re: Why I never finish my Haskell programs

#84

Post by ianbicking »

I always felt very productive in PHP, because the only rewarding part of PHP is having made something. It never rewarded sophistication... but making a web site that did something WAS rewarding, so all my attention went to that part.

Calling Haskell an anti-PHP seems fair.

Re: Why I never finish my Haskell programs

#85

Post by acdha »

zengid wrote: post #79
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://y…

I think a key part is never losing track of the real goal so you can remind yourself what percentage of your time is going to things which anyone who isn’t a developer on your project would care about.

Re: Why I never finish my Haskell programs

#86

Post by jhayward »

wtracy wrote: post #35
mac01021 wrote: post #28

Earlier quoted context omitted.

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

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

Those are mostly library functions, not part of the language.

It doesn't seem any more reasonable to use them to declare Haskell a complex language than it would to have the existence of, say, a linear algebra library providing mathematical operators for Forth mean that Forth is a complex language.

Re: Why I never finish my Haskell programs

#87

Post by KirinDave »

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.

I'm curious what languages do it better. I'm looking for something new to learn.

Re: Why I never finish my Haskell programs

#88

Post by codebje »

zengid wrote: post #79
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://y…

His argument begs the question.

If you pre-suppose that describing types and finding appropriate abstractions aren't "writing applications", that is, they offer no value in the process, then spending time doing them is of course solving neat little puzzles to no benefit.

On the other hand, if you pre-suppose that types and abstractions offer some value to the process of writing an application, then solving those puzzles is adding value.

Calling types and abstractions a "neat little puzzle" is a diminution we could apply to other aspects of writing an application: implementing an algorithm to correctly process some data is a neat little puzzle presented by our test cases.

Rich Hickey would need to demonstrate the lack of value of types and abstractions for producing applications to make a solid argument here, and that I believe is a steep uphill battle, because Clojure would be a pretty terrible language if you took out the ISeq abstraction, and there's an awful lot of effort spent shifting the puzzle of "is this function being used right" from the type system game engine to the test harness game engine.

Re: Why I never finish my Haskell programs

#89

Post by wool_gather »

Barrin92 wrote: post #32
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…

Reminds me of one of Rich Hickey's talks where he states that people just love to solve puzzles, and that complex languages with, for example, demanding type systems trick people into thinking they are adding safety or value when in fact they're just outsmarting themselves. Often when I write something in Haskell I have this feeling. It feels satisfying to build up nice types and constructs but I don't know if it at…

> I can't really tell if I've invented the problem that I just solved.

Priceless observation, nicely done!

I was quite inspired by Rich Hickey's Simple Made Easy talk when I listened to it a last year. I think that's the one you're referring to. Excellent food for thought in that talk.

Re: Why I never finish my Haskell programs

#90

Post by dwohnitmok »

yogthos wrote: post #72
dwohnitmok wrote: post #67

Earlier quoted context omitted.

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.

Well the monadic structure is always there, it's just a matter of whether you use it or not :).

For the most part I admire the Clojure community's focus on data and wariness of higher order abstractions. Whether it be classes, typeclasses, or higher order functions, if you can express it with just data it's almost always better and most communities would do well to remember that.

On the flip side when there is a need for higher order abstractions, I sometimes find Clojure's standard tools to be lacking. Speaking of monadic structure being there whether you use them or not, transducers are a great example. I find them overcomplicated in Clojure, which I think is due to focusing too heavily on using standard function composition to compose them. I regard this as a bit of a trick or a coincidence. When's the last time you composed something with a transducer that wasn't just another transducer as opposed to an arbitrary function? In fact if you instead use monadic composition (i.e. compose `a -> m b` with `b -> m c` to get `a -> m c`, in this case `m` is just `List`) you'll find that transducers are just functions of the form `a -> List b` rather than higher order functions. And yes that `List` remains there even though transducers work on things that aren't just concrete collections.

I've been meaning to try to push out a Clojure library that shows this but haven't gotten around to it. Maybe this thread will be the kick I need.

Post reply on HN