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

91–100 of 228 posts

Re: Why I never finish my Haskell programs

#91

Post by owl57 »

xamuel wrote: post #34
dustingetz wrote: post #19

1) to me, this is the difference between haskell and Clojure 2) in the future, normal people will be able to code, so work backwards from that

>in the future, normal people will be able to code, so work backwards from that This. I'll never be able to understand certain programmers' insistence that imperative code is somehow unnatural or that "we're only used to it because of momentum" or whatever. For thousands of years people have been issuing imperative instructions to each other. "Wash. Rinse. Repeat."

> For thousands of years people have been issuing imperative instructions to each other.

This ancient culture is pretty strong, you're right. I've lost count of times I begged people to skip all this unreliable "turn right at the second intersection, rinse, repeat" and just tell me the street address long before I learned the word "imperative".

Re: Why I never finish my Haskell programs

#93

Post by cynicalkane »

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…

Former Clojure programmer here. I eventually learned I'd rather write neat little puzzles about static types than solve frustrating little puzzles on the root causes of runtime exceptions.

Re: Why I never finish my Haskell programs

#94

Post by antidesitter »

yogthos wrote: post #68
pka wrote: post #66

Earlier quoted context omitted.

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…

What makes you think the Haskell community is toxic? I usually hear the exact opposite.

Re: Why I never finish my Haskell programs

#95

Post by rictic »

codebje wrote: post #88
zengid wrote: post #79

Earlier quoted context omitted.

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 puzz…

Time spent with a type system buys you compiler-checked proofs of some properties. The important question is whether the time is worth the benefit.

One of many things that I love about the TypeScript type system is that it gives so much power to the author. It is the most expressive industrial type system I know of, but it also makes it easy for the programmer to say "I can't prove that this is true, just trust me that it is".

A nice side benefit is that this is also practice, so you can also gain skill. This is how I justify sometimes spending much more time with the type system than it would otherwise be worth when learning a new language or hacking on a personal project.

Re: Why I never finish my Haskell programs

#96

Post by agentultra »

The turning point for me was when I realized that these problems exist in other languages and are practically invisible. Without a good type system and inference you cannot hope to catch all of your type errors. You'll just write some unit tests and run your program many times until you're certain you've sussed them all out... until that pesky bug report comes in. Then you get to play detective!

I honestly don't have time left in my life for such meaningless drudgery.

With a type system I have the computer aid me in designing the program. It keeps me honest and ensures that I don't have type errors which are are huge class of things I'd rather not have to think too hard about.

When I program in Haskell I spend more time solving problems than fixing programming errors.

Re: Why I never finish my Haskell programs

#97

Post by gowld »

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.

In other languages, if the logging facility fails, you can simply continue running the program without logging. This works reliably enough across the world for many years that no one worries about log statements in production being unsafe.

Re: Why I never finish my Haskell programs

#98

Post by yogthos »

dwohnitmok wrote: post #90
yogthos wrote: post #72

Earlier quoted context omitted.

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…

Yup, there are always trade offs with every approach. A monadic version of transducers would be neat, and it would be fun to contrast them with the HOF approach in terms of pros and cons. :)

Re: Why I never finish my Haskell programs

#99

Post by gowld »

village-idiot wrote: post #80
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/... ).

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.

They fine inside a limited domain-specific scope, just don't go importing operators from many libs willy-nilly.

Re: Why I never finish my Haskell programs

#100

Post by gowld »

seanmcdirmid wrote: post #47
gabipurcaru wrote: post #5

I think the main reason is that there is no _actual_ problem that OP needs to solve. If there was one, then he would get pragmatic and figure out one of the reasonable solutions to this and move on with his life. Though it's true that Haskell is easy to put you into a mindset where you want to simplify and generalize the code as much as possible, leading to wasted time on overly general solutions. Which shouldn't be…

There are some languages that tempt more abstract navel gazing than others. I’m not sure about Haskell, but Scala tends to do that. Anyways, there is something about human behavior and language design that can lead “more is less” situations.

If you don't have a use case creating a need that your program solves, what's the difference between figuring out make a zygohistomorphicanedoreticular for polynomials and writing a working library that no one uses? Either way, you do whatever is fun for you. If you have an actual customer requirement, then that guides your prioritization and attention?
Post reply on HN