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

61–70 of 228 posts

Re: Why I never finish my Haskell programs

#61

Post by jerf »

ajross wrote: post #21
jerf wrote: post #10

You can eventually "come out the other side" and get to the point where you write the general version correctly the first time. But it is some degree of work. I think it's a good exercise for a pro, but you can certainly live without it. The general principle does come in handy elsewhere, though. Doing the most useful work with the minimum power is a generally useful skill. I get a lot of mileage out of it in other l…

> You can [...] write the general version correctly the first time. But it is some degree of work. [...] Doing the most useful work with the minimum power is a generally useful skill. There's something wrong with that logic, but I'm too lazy to work out the proof in the general case.

When people wonder why my typical comments run on to multiple screenfuls, it's because I'm armoring them against this sort of dismissive snark. I was in between tasks today and lacked time to make it longer.

Re: Why I never finish my Haskell programs

#62

Post by aidenn0 »

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.

Figuring out what parts of the next 1000 lines of code you are going to write will benefit from an abstraction (and which abstraction that is) is a rare skill that comes only (if at all) with experience.

Re: Why I never finish my Haskell programs

#63

Post by icc97 »

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

I agree that this is one of the things that makes Haskell harder/scarier to learn, but I don't think that it makes it bigger.

Re: Why I never finish my Haskell programs

#64

Post by fnord123 »

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.

>These can be useful for investigating bugs or performance problems. They should not be used in production code.

Re: Why I never finish my Haskell programs

#65

Post by hhmc »

KirinDave wrote: post #38
sdegutis wrote: post #23

Earlier quoted context omitted.

I lost confidence in Haskell's ability to let me write something one way and safely refactor it later, when I found out that you can't use a ton of the algorithmic functions in the standard library because they do things all wrong.

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.

Re: Why I never finish my Haskell programs

#66

Post by pka »

fnord123 wrote: post #64
pka wrote: post #58

Earlier quoted context omitted.

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

>These can be useful for investigating bugs or performance problems. They should not be used in production code.

Well yeah, because a logging statement in production can fail (i.e. network connection drops). The type system forces you to deal with that fact instead of letting you write code that e.g. brings down your server unexpectedly because of some random log call.

Many would consider that a feature, but if you want to #yolo it anyway, like in most other languages, just use trace in prod and call it a day.

Re: Why I never finish my Haskell programs

#67

Post by dwohnitmok »

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.

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 semantically meaningful behavior from the program.

On the other hand, with the rise of stuff like OpenTracing and structured logging I think the Haskell community was pretty prescient about treating logging as an explicit side effect.

Re: Why I never finish my Haskell programs

#68

Post by yogthos »

pka wrote: post #66
fnord123 wrote: post #64

Earlier quoted context omitted.

>These can be useful for investigating bugs or performance problems. They should not be used in production code.

Well yeah, because a logging statement in production can fail (i.e. network connection drops). The type system forces you to deal with that fact instead of letting you write code that e.g. brings down your server unexpectedly because of some random log call. Many would consider that a feature, but if you want to #yolo it anyway, like in most other languages, just use trace in prod and call it a day.

The type system forces you to solve this problem in a very specific way by structuring your entire app around pushing IO to the edges. There are plenty of other ways to address the problem that work perfectly fine in practice.

For example, you can specify what should happen is IO fails in your logging configuration. This handles the exceptional case consistently and in a single place without forcing you to structure your whole app around it.

What's more is that there really isn't a sane way to recover from such a catastrophic failure. If your database goes down, or you lose a disk, the only thing you can do is shut down the app. It's not like it's gonna keep humming along with the logging failing silently.

This kind of hyperbole that your either solve all problems via the type system or #yolo is precisely what makes Haskell community so toxic in my opinion.

Re: Why I never finish my Haskell programs

#69

Post by xxxdarrenxxx »

[deleted] wrote: post #54
cortesoft wrote: post #22

Earlier quoted context omitted.

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

[deleted]

This, it's getting the figurative perfect sphere. I'd say a better term for doer is a pragmatist considering the implied personality. As for Haskell The whole concept of generalizing and purity is already perfectionistic-ly biased on a conceptual level.

Re: Why I never finish my Haskell programs

#70

Post by dwohnitmok »

wtracy wrote: post #59
dpratt71 wrote: post #50

Earlier quoted context omitted.

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.

In what way? Those are defined as part of the operator. I usually parenthesize them anyway just like I would for an equation.
Post reply on HN