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

141–150 of 228 posts

Re: Why I never finish my Haskell programs

#141

Post by dwohnitmok »

yogthos wrote: post #136
dwohnitmok wrote: post #135

Earlier quoted context omitted.

I'm somewhat wary of approaches like that. I feel like core.typed tried something similar (maybe McVeigh's approach does better inference of unannotated code?) and it's withering on the vine as far as I can tell. IIRC there's some theoretical hints that gradual typing from the direction of untyped to typed rather than the direction of typed to untyped is fundamentally less ergonomic (some type inference stuff becomes…

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 differ. The REPL is amazing, but I still want my ability to create closed world assumptions first!

Re: Why I never finish my Haskell programs

#142

Post by ajcodez »

jlebar wrote: post #106

I am not a Haskell programmer, but is this correct? (Poly a) + (Poly b) = Poly $ addup a b where addup [] b = b addup a [] = a addup (a:as) (b:bs) = (a+b):(addup as bs) Imagine a simple example, adding `x+2` and `10`. In OP's representation, these would be represented as the lists [1, 2] and [10]. That is, the first element is the coefficient of the term of highest degree. But doesn't this implementation add list ele…

Yeah it’s the cons operator so it matches the first element (head) of the list and next elements (tail). It would need a reverse and reverse back to work correctly.

reverse (addup (reverse a) (reverse b))

Re: Why I never finish my Haskell programs

#143

Post by dwohnitmok »

hota_mazi wrote: post #131
dwohnitmok wrote: post #45

Earlier quoted context omitted.

Haskell 2010 is pretty small. Comparable to say Clojure, but more complex than Scheme. GHC Haskell with the kitchen sink of extensions turned on is big. Very big. Sticking to Haskell 2010 with a few extensions that make known behavior more consistent (GADTs, NoMonomorphismRestriction, and a few others in that vein) is the best bang for buck in my experience.

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.

That's true. I meant size in the hand-wavy sense of "this feels complicated" (although the syntax part is also true in this case). For example there's a GHC extension to overload the meaning of a type declaration (DataKinds). This technically doesn't introduce new syntax but it's definitely a "big" extension in my book.

Re: Why I never finish my Haskell programs

#144

Post by ajross »

jerf wrote: post #61
ajross wrote: post #21

Earlier quoted context omitted.

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

OK, long form: you whooshed on the point of the linked article entirely. Software exists to solve problems, not to achieve some sort of aesthetic ideal. Time spent in pursuit of abstractions (or skill in the expression of abstractions) is wasted, by definition. You seem to be conflating the two. To wit: spending hours giting gud at Haskell doesn't translate to hours saved solving real problems (like the one in the link -- a straightforward list operation anyone could code in an imperative language in a few minutes).

And your inability to see the humor in that (or the expository value of a good quip) is... well... let's just say more evidence that you're head is pointed somewhere other than the correct solution space.

Re: Why I never finish my Haskell programs

#145

Post by tokyodude »

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 agree but I feel like the fact that it's a puzzle is a sign the language could be improved. Describing generic types shouldn't have to look like stl's or boost's implementation details. They are nightmares of "neat puzzle solving"

Re: Why I never finish my Haskell programs

#146

Post by AnimalMuppet »

jhayward wrote: post #86
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

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.

Depends on what library they're from.

Is the STL part of C++? Sure, it's a library, but it's a standard library - it should be there in every conforming implementation. Personally, I think of that as part of the language.

Is some vendor's RS232-port-handling library part of C++? I would say no.

In the same way, I think that Java's standard library is part of the language, and is in fact the strongest selling point of Java.

Re: Why I never finish my Haskell programs

#147

Post by taeric »

chongli wrote: post #108
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…

The blank canvas analogy is a good one but for the wrong reason. Think of the aspiring novelist with a blank stack of paper in front of them. The problem is not the freedom they have, it's their lack of discipline. It's far easier to write PR for an agency or injury reports for a sports blog than it is to write a novel. The reason so many programmers struggle with this problem is because nobody is paying them to writ…

Better than a manager, is a customer. Though, any stakeholder is probably better than none, which I believe is your main point. (And one I agree with.)

Re: Why I never finish my Haskell programs

#148

Post by thomasfedb »

sverhagen wrote: post #74
thomasfedb wrote: post #60

Writing elegant code that never works can easily take me twice as long as writing okay code that actually works.

You're phrasing that in a seductive way. "Okay code". Maybe that's good enough, right? Maybe not? Someone's "okay code" may be someone else's "bad code". I'm fixing someone else's "okay code" on a daily basis since it's riddled with bugs. Somehow I'd expect that if they would have had the mastery to write elegant code, they may also have been able to make it less buggy, or at least to make it easier for me to fix it.…

I think for me, "okay code" means that it's functional, debuggable, and up to professional sniff, but nothing flashy. As opposed to sexy-cool-trendy-meta-wow code.

Re: Why I never finish my Haskell programs

#149

Post by tomxor »

chongli wrote: post #108
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…

The blank canvas analogy is a good one but for the wrong reason. Think of the aspiring novelist with a blank stack of paper in front of them. The problem is not the freedom they have, it's their lack of discipline. It's far easier to write PR for an agency or injury reports for a sports blog than it is to write a novel. The reason so many programmers struggle with this problem is because nobody is paying them to writ…

> People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.

I agree, but perhaps discipline is not necessarily complete restraint... I think some rabbit holes are worth exploring, they can separate outstanding projects from mediocrity. Perhaps it's about choosing the right rabbit holes in the right projects, another way of achieving that is minimalism where you limit the scope and not the depth.

Re: Why I never finish my Haskell programs

#150

Post by bmurphy1976 »

hota_mazi wrote: post #137
yogthos wrote: post #107

Earlier quoted context omitted.

I find that the Haskell community is very friendly as long as you buy into their approach to solving problems. However, my experience is that if you question the effectiveness of static typing, or ask for evidence in support of the claimed benefits you'll get a very hostile reaction. The comment above where pka snidely claims that using any alternative to types amounts to yolo is quite representative. He outright dis…

Facts have been presented to you multiple times but your adoration of Clojure just makes you dismiss them outright. People who claim dynamic type systems are superior to static ones can be dismissed in much the same way flat earthers can because both choose to dismiss evidence they find inconvenient.

You know he can be wrong about some things but still make a valid point about others. How do you think this reads in relation to his primary claim about the Haskell community?

> People who claim dynamic type systems are superior to static ones can be dismissed in much the same way flat earthers can because both choose to dismiss evidence they find inconvenient.

Seriously. This only feeds into his narrative.

Post reply on HN