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

181–190 of 228 posts

Re: Why I never finish my Haskell programs

#181

Post by misja111 »

amelius wrote: post #179
misja111 wrote: post #177

It's about Scala, not Haskell, but the gist is the same: at my company we're giving new candidates a live coding interview where they get one hour to write a very simple application using either Java or Scala. Candidates are free to choose between those languages. The funny thing is, that candidates who choose Scala are never able to fully finish the assignment. Even though the application is really simple, many don'…

So Scala is harder to write, but the question is: is it easier to read? (Since in general a particular piece of code is read far more often than it is written).

That's an interesting question although it's not directly related to the article.

I think it is definitely possible to write Scala code that is easier to read than the same Java code. However it seems that a large part of the Scala community does not see this as their main objective when writing code.

Sometimes the focus seems to be on writing code as terse as possible, which is not the same as readable. Or the focus is on making code more generic and abstract, which can be a useful goal depending on the use case, but it's definitely not the same as readable.

Re: Why I never finish my Haskell programs

#182

Post by HelloNurse »

emmelaich wrote: post #37
mlthoughts2018 wrote: post #3

In Haskell (and similar), the language offers the ability to really stab genericization in the heart in a good way, to do it the right way. But 90% of the time, you shouldn’t and it’s very hard not to. Not a matter of restraint, but the language makes it actually very hard to get simple things done unless you plug into the abstraction vortex. Conversely, languages like Java, C++ and Python (if you use classes), make…

True but I still manage to go down some rabbit holes in C++. I could use the older STL iterators, but nooo I use a range, with a lambda. Returning a tuple with tie and pair and some more stuff from the latest C++1x standard. And in Linux userland, I just want to check a pid but I invent some smart locking system to ensure I never get a false positive or negative.

In C++ the main actual rabbit hole of useless abstraction begetting useless abstraction is premature generalization from what you actually need to templates that can be used with types you don't need, which then proceed to kick you with implicit assumptions, type traits, unforeseen subtle type distinctions like those that come up in Haskell.

Other kinds of "stuff from the latest C++1x standard" tend to consist of relatively harmless novel ways to express something, usually not intrinsically complex and, when inappropriate, causing only localized damage (typically puzzling syntax or slightly wrong declarations with no impact on unedited code parts, even in the same class or function).

Re: Why I never finish my Haskell programs

#183

Post by pwm »

tannhaeuser wrote: post #171

Coming from Prolog I'm loving Haskell, but I'm seeing a special kind of "worse is better" at work here: that projects using innovative and sophisticated languages have a high risk of running into obsessive "getting it right" and "holier than you" mentality resulting into them often getting never finished, and even if finished, having a high barrier of attracting contributors. It's unfair and embarassing, but shitty l…

I'll put a slightly different spin on this: At my current job the system I'm writing is in PHP (for reasons...). In its core it's all about domain modelling with some workflow sprinkled on top. Haskell would be a near perfect fit, but it can be done in PHP. However the code itself looks very Haskelly. I have a growing library of domain specific types that are composed into larger and larger tree shaped ADTs all the way to the top level entities. Validation is mapping/folding these ADT trees where nodes are (type, data) pairs that are mapped to their instantiation or its failure. The workflow bit is essentially a couple of FSMs with conditional transitions where the condition is usually the existence of some type that fulfils its constraint. Etc...

Reading it back it sounds analogous to the classic saying of one can write fortran in any language. In my opinion having experience with Haskell gives you a mindset first and foremost. When you bump into a problem where this mindset is a good fit you can use that knowledge with whatever tools are at hand.

Re: Why I never finish my Haskell programs

#184

Post by m_mueller »

lasagnaphil wrote: post #169
m_mueller wrote: post #162

Earlier quoted context omitted.

which large software project has ever been ‚completed‘?

A lot of single-player (not online serviced) computer games could be regarded as ‘completed’: once they’re out on the store shelves, it’s pretty much done (although with the rise of Steam and continuous updates this is less of a case) That’s probably why many game programmers are more pragmatic in their programming practices: they have a concrete deadline to pursue, with a predictable subset of hardware for their pro…

point taken, a lot of software in the pre internet era could be considered completed - on the other hand there's always still going to be issues, so you could also claim that these projects are just abandoned.

In general I think software is more like a house than an art piece - it keeps adapting as long as people use it.

Re: Why I never finish my Haskell programs

#185

Post by m_mueller »

_0ffh wrote: post #173
m_mueller wrote: post #162

Earlier quoted context omitted.

which large software project has ever been ‚completed‘?

Strike the "large" in that sentence. I somewhat think that writing software is like painting. At some point you decide to stop, but you're never truly done. Also cf. Leonardo da Vinci: "Art is never finished, only abandoned."

interesting, I didn't even read your comment before writing my last reply, which says very much the same, just with less da Vinci in it ;)

Re: Why I never finish my Haskell programs

#186

Post by Fiahil »

vfclists wrote: post #178
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…

Mozart/Oz??? I never heard of it. Now there is another rabbit cave to spelunk in my search for the perfect programming language.

It's an academic-only language, mostly used for teaching students about programming. Anyone sane would not use it in production, as the output would likely be "ill-typed".

Re: Why I never finish my Haskell programs

#188

Post by lmm »

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…

> The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless.

I get paid to write applications in Scala that are often mostly CRUD. The temptation to overengineer is still there and still constantly needs to be fought.

I've seen the same thing happen in plenty of Java codebases too, mind. There it tends to be less "make this work for any possible Monoid" and more "make it work for any imaginable form that the user might want to build", but I think it's another facet of the same issue.

Re: Why I never finish my Haskell programs

#189

Post by LandR »

psergeant wrote: post #120
ianbicking wrote: post #84

I always felt very productive in PHP, because the only rewarding part of PHP is having made something. It never rewarded sophistication... but making a web site that did something WAS rewarding, so all my attention went to that part. Calling Haskell an anti-PHP seems fair.

The same author of the original explores this theme with Java: https://blog.plover.com/prog/Java.html

That perfectly describes Java (and C#).

It's the land of mediocritity.

Re: Why I never finish my Haskell programs

#190

Post by Zalastax »

gmfawcett wrote: post #109
endgame wrote: post #56

Earlier quoted context omitted.

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…

> you can say that any `b` in the result list _must_ have come from applying the function to some `a` in the input list. Morally correct... but consider the function `\f xs -> [undefined]`, which can be typed as `(a -> b) -> [a] -> [b]`. (Obviously it could be given other types as well.)

When discussing Haskell and theorems about its types it's common to simply ignore non-termination; if we don't ignore non-termination there's basically nothing we can say about Haskell programs at all.

Interested readers should check out Agda and Theorems for free!

Post reply on HN