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

191–200 of 228 posts

Re: Why I never finish my Haskell programs

#191

Post by lmm »

rictic wrote: post #95
codebje wrote: post #88

Earlier quoted context omitted.

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

> 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".

I really wanted to like Typescript, but once you're thinking in HKT it's incredibly frustrating to have to manually translate a function into its flattened expansion (just like it's incredibly frustrating to use a type system without generics once you've used one that has generics). Every serious industrial language allows a programmer to say "I can't prove that this is true, just trust me that it is"; I suspect many people who struggle to start out in Haskell would do well to make a little more use of unsafeCoerce and unsafePerformIO (they would no doubt give themselves runtime errors, but sometimes the easiest way to understand why you had a type error is to run the code and see what the values are at runtime).

(I made a small hobby tool with ScalaJS and was amazed how easy it was, so I'll be advocating for that over Typescript).

Re: Why I never finish my Haskell programs

#192

Post by lmm »

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 think the very fact that this happens in Java - a deliberately simplistic language - is proof that it's not a problem with the language itself. If the language doesn't support particular constructs, all that means is that people will bikeshed over which pattern to use instead of which language construct.

Re: Why I never finish my Haskell programs

#193

Post by lmm »

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…

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

In Haskell you can write a function that does "unsafe" logging and handles exceptions if that's the behaviour you want. You can even make that function change its behaviour based on a config file if you really want to.

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

That sounds like an argument for including the IO effect in your whole program's structure like people usually do in Haskell, no? If you change a function that doesn't access the disk (e.g. something that just grinds out a mathematical computation) into one that does access the disk by adding logging, you have a new set of possible failure scenarios to be aware of and want that to be visible.

I appreciate that this all sounds very theoretical but it can easily lead to real-world failures. I've seen "impossible" control flow because of an unanticipated exception in a function that didn't look like it could exception cause production issues. I can easily imagine e.g. leaving data in a remote datastore like redis in a supposedly impossible state because your redis-error-handling code tried to first log that an error had occurred and that logging then failed because local disk was full.

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

Every time I've bypassed the type system I've come to regret it, usually when it caused a production issue. It's not hyperbole, it's bitter experience.

Re: Why I never finish my Haskell programs

#194

Post by [deleted] »

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.

[deleted]

Re: Why I never finish my Haskell programs

#195

Post by l0b0 »

AlexCoventry wrote: post #167
l0b0 wrote: post #138

There are lots of relevant programming aphorisms: "Write the simplest thing that could possibly work." "YAGNI." "KISS." You either have a problem you need to solve or not. If not, why do you expect the process to ever finish? This is one area where TDD really shines. You write a simple failing test and implement something that makes that test pass. If that isn't sufficiently generic you write another test, make both…

There needs to be a balance. You should choose an architecture which will accommodate predictable future needs without too much refactoring. A suite of unit tests can't help you much if you need to unmangle a bunch of severe abstraction violations between what you now need to be well-encapsulated components.

Actual red-green-refactor TDD results in the simplest possible code to solve a problem, IME. Over- or under-abstraction tends to be pretty well instantly recognizable when working with a well written test suite, and can then be easily and safely refactored away.

Re: Why I never finish my Haskell programs

#196

Post by yogthos »

dwohnitmok wrote: post #141
yogthos wrote: post #136

Earlier quoted context omitted.

Key difference here is that it's not aiming to be a comprehensive type system, just to catch obvious problems. So if it runs into something it doesn't understand it'll just move on and leave it as is. If it sees something it understands and it's incorrect it will give an error. Personally, I would find this very valuable because it would help catch many common errors early while staying completely out of the way. And…

Didn't core.typed try to do the same thing? Not provide comprehensive types but just as needed? I never really used it (a coworker did but ended up throwing it out I think). Even if it's exactly the same technically maybe it'll work out with a different set of social circumstances. Maybe if Circle didn't drop core.typed it'd be even more popular now. Never know about these things. Haha, well that's where you and I di…

Core typed requires you to annotate everything in the namespace, or add exclusions explicitly. This introduces quite a bit of additional work, and I suspect that's why it never really caught on.

I've read that the author is looking at improving inference in it, and at generating types from Spec, so it might still find a niche after all.

And I understand completely, it's all about perceived pain points at the end of the day, and we all optimize for different things based on our experience and the domain we're working in. That's why it's nice to have lots of different languages that fit the way different people think. :)

Re: Why I never finish my Haskell programs

#197

Post by Tarean »

Tarean wrote: post #180
hota_mazi wrote: post #131

Earlier quoted context omitted.

The complexity of a language has nothing to do with its size. Brainfuck or Whitespace are two minuscule languages that produce the most impenetrable sources.

> I'm from Microsoft and when you see Microsoft documentation it often says, you know, x y or z is a rich something, right. In this case Haskell - or ghc's version of haskell is a rich language. What does this mean? Sounds good, doesn't it? But it always means this, right. That it's a large, complex, poorly understood, ill documented thing that nobody understands completely. From a great talk by Simon Peyton Jones ht…

Linked the wrong talk, oups https://www.youtube.com/watch?v=uR_VzYxvbxg

Re: Why I never finish my Haskell programs

#198

Post by village-idiot »

gowld wrote: post #99
village-idiot wrote: post #80

Earlier quoted context omitted.

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.

It’s very hard to convince people to keep them in that limited scope.

Re: Why I never finish my Haskell programs

#199

Post by workleg »

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…

There's something very seductive about a chance to comment on posts like this one for a particular group of people. These posts whisper in your ears "the fact that you've had a hard time and failed to understand, learn and harness these exotic languages does not mean that you are not brilliant. Here's a blank canvas for you to convince others of same, perpetuating the perspective convenient to your ego, which got bruised by the hard task in the past" (all in good humor) Jokes aside, I code professionally Haskell every day all day long. I'm very productive and get more productive and love the language more every day. It's all about realistic expectations and commitment (just like anything that's hard). You cannot expect to learn and be productive in Haskell within a week/month or even a year. You need a lot of patience and dedication, but you will be rewarded, that i can promise.

Re: Why I never finish my Haskell programs

#200

Post by nextos »

tincholio wrote: post #156
nextos wrote: post #118

Earlier quoted context omitted.

In my case, I think it's because large programs always end up containing subproblems that can be better expressed in other paradigms than functional. And it becomes frustrating when I can't shoehorn them to the Haskell way of doing things. My favorite languages are, for this reason, multi-paradigm: Common Lisp, Mozart/Oz, Scala and C++. It's a bit like building La Sagrada Familia (and that's why it's depicted in the…

I agree with your sentiment, but I find the analogy to La Sagrada Familia funny, in that is has still not been finished, it's a black hole for money, and you can see, clearly, it's a hodge-podge of styles... All characteristics that might not be good for your software project.

It's not my analogy, it's CTM's [1]. A book that has cult status in some CS circles.

[1] https://www.info.ucl.ac.be/~pvr/book.html

Post reply on HN