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

51–60 of 228 posts

Re: Why I never finish my Haskell programs

#51

Post by dwohnitmok »

klodolph wrote: post #33
mac01021 wrote: post #28

Earlier quoted context omitted.

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

Large in the sense that it admits many approaches to solving problems. https://www.willamette.edu/~fruehr/haskell/evolution.html

It's meant as a joke but as the author of that page points out, I think there's real pedagogical value in understanding all of the examples. You'll learn quite a bit of CS fundamentals independent of Haskell itself.

Then please do as the professor does when it comes to production code.

Re: Why I never finish my Haskell programs

#52

Post by jernfrost »

wtracy wrote: post #41

I have to ask: does the author not have the same problem in other languages? If not, why not? Any major language has dozens of libraries that do almost-but-not-quite what you want. Any language with support for mactos, templates, or generics offers opportunities to write unnecessarily generic code. (The authors of Spring managed to get into that tarpit even before Java introduced generics!)

I write in many different languages, but I would say this kind of thing depends a lot on the type of language.

With Go, e.g. I would not spend much time on this, because it is such a plain language. You just accept there is no fancy way of doing this and move on.

With C++ I found it a bit different. Either I mess around thinking there MUST be some way of solving this annoying problem only to realize there just isn't. Other times I find a solution but it tends to turn into a horrible ugly syntax mess, so you abandon it. I've pretty much given up writing anything elegant or fancy in C++. It just turns to shit so quickly.

Swift I found fairly straight forward to write. All the typical stuff that get me stuck in C++, never seems to pose a problem for me in Swift.

Julia is the language which ought to have thrown me into the Haskell problem described, as you can do a lot of crazy stuff with types and macros. I do to some degree but mostly Julia just does what I want it to do. I guess it is partly down to the core functions being well designed and that despite the flexibility it is still not as magical as Haskell, Clojure etc.

Re: Why I never finish my Haskell programs

#53

Post by rs86 »

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?

I don't think it is small or minimal but I believe it to be smaller than Scala

Re: Why I never finish my Haskell programs

#54

Post by [deleted] »

cortesoft wrote: post #22
galfarragem wrote: post #12

Earlier quoted context omitted.

Resuming: the typical Haskeller is a perfectionist. If I allowed, without blinking, my perfectionist self would ditch every language but Haskell. No other mainstream language can give you more control and purity. For a perfectionist this is opium.

It is a particular form of perfectionism. Other types of perfectionists might want to be perfect at writing programs as fast as possible.

[deleted]

Re: Why I never finish my Haskell programs

#55

Post by KurtMueller »

pash wrote: post #49

I think many beginning Haskellers have this problem. To overcome it, my advice is to write Haskell code with the knowledge that you can re-write it more readily than you can re-write code in many other languages. Write the code that fits the immediate application, and rely on the type-checker to make it straightforward to refactor when the need arises. I think that’s what many experienced Haskellers would say is the…

I know Elm isn't the same as Haskell, but these points are also used as a selling point for Elm. And more often than not, as with Haskell, the type system makes it possible to refactor a large program with the confidence that all the parts you replace will slot perfectly back into the original structure OR the compiler will yell at you until it does :).

Re: Why I never finish my Haskell programs

#56

Post by endgame »

ainar-g wrote: post #8

>I ought to be able to generalize this I've never understood this. Unless you write a library that you plan to publish, or already have actual cases where you need a more general solution, why spending time trying to generalise code instead of switching to the next task?

One reason is that more general types mean you can write fewer functions, and so the function that you do write is more likely to be correct.

The function `intMap :: (Int -> Int) -> [Int] -> [Int]` can do all sorts of crazy things that are not map. The function `map :: (a -> b) -> [a] -> [b]` can do far fewer crazy things, and just from looking at the type you can say that any `b` in the result list _must_ have come from applying the function to some `a` in the input list.

Re: Why I never finish my Haskell programs

#57

Post by 1000units »

xamuel wrote: post #31
kelvin0 wrote: post #9

Earlier quoted context omitted.

My tentative answer is this: someone who uses Haskell appreciates elegant solutions (a.k.a mathematical/functional) and is inclined to write things 'properly' once and they might also idealize that the functions they write will not only solve this current issue, but be useful to others and themselves in other programs ... thus going down the generalization and elegance rabbit hole. Of course, all of this is purely sp…

>elegant solutions (a.k.a mathematical/functional) Meanwhile, if you look at pseudo-code written by actual mathematicians or logicians, it's almost always imperative, full of side-effects and global variables. Sometimes they even use GOTO!

I was likewise surprised to learn few Haskellers have any interest in computing the cohomology of their monads.

Re: Why I never finish my Haskell programs

#58

Post by pka »

yogthos wrote: post #48
mac01021 wrote: post #28

Earlier quoted context omitted.

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

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.

Re: Why I never finish my Haskell programs

#59

Post by wtracy »

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/... ).

Even if the operators themselves don't count as "part of the language", the complex precedence rules around them certainly should.
Post reply on HN