Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

Post reply on HN
Print view View original

131–140 of 402 posts

Re: Leaving Haskell behind

#131

Post by tome »

mananaysiempre wrote: post #55
pyrale wrote: post #32

Earlier quoted context omitted.

I've used stack+stackage, and I can still run all of my older projects. I agree that as a newcomer the choice is not evident, haskell is a small enough community that finding mentorship is not always evident if you don't know where to look.

> haskell is a small enough community that finding mentorship is not always evident I don’t know about today, but ten years ago the answer was to hop on IRC and you’d get all of your IRC-sized non-FAQs answered, however difficult they are.

It's still the case, as far as I know. Big list of channels: https://www.haskell.org/irc/

Re: Leaving Haskell behind

#132

Post by rowanG077 »

doyougnu wrote: post #127
rowanG077 wrote: post #95

Earlier quoted context omitted.

You misunderstand my problem. Add a logger to that fibonacci function. Potentially EVERY usage site now has to change, maybe even multiple layers. Adding a log in most languages is a local transformation. In Haskell it isn't, it can have codebase wide consequences.

Does every usage site have to change? You would alter fibonacci to be: fibonacci :: (MonadLogger m, MonadState (Int, Int, Int) m) => m Int fibonacci ... and now of course all callers must support MonadLogger. But instead of using the MonadLogger (or any mtl constraint directly) you should just be constructing an abstraction boundary with a type class synonym: class (MonadLogger m, MonadState s m) => MyMonads s m and…

I have seen this in the wild. The result often is that every function has a kitchen sink MyMonads constraint of which it only uses a tiny subset. It's death by a thousand cuts. If you make such a class for every monad combination you get insanely large amount of classes. It's simply unworkable. Which is why you get the kitchen sink monad pattern.

Re: Leaving Haskell behind

#133

Post by Tainnor »

bradrn wrote: post #88
Tainnor wrote: post #81

Earlier quoted context omitted.

You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?

Fair enough, though I’ll note that only I’ve given an up-to-date reference.

In that same thread that you've linked, other people have later replied arguing for why they prefer Stack so... I don't really think that you've given an argument that is persuasive enough to someone who is new to Haskell.

(And I'm not even that new to Haskell. It's just that I don't use it every day and when I come back to it and have to remember the weird incantations and dances I have to perform to make HLS not crash or want to overwrite my stack-installed Haskell version, I'm usually rather annoyed.)

Re: Leaving Haskell behind

#134

Post by nonameiguess »

bradrn wrote: post #88
Tainnor wrote: post #81

Earlier quoted context omitted.

You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?

Fair enough, though I’ll note that only I’ve given an up-to-date reference.

You posted a link to a forum. The official Haskell language "get started" page says to use both: https://www.haskell.org/get-started/

Re: Leaving Haskell behind

#135

Post by systems_glitch »

pyrale wrote: post #78
alex_smart wrote: post #49

Earlier quoted context omitted.

What is wrong with Java's tooling?

If you ask for my personal experience: - The community leans a lot on configuration over code, and that's annoying. Sometimes, a hardcoded string in your conf could have been a hardcoded string directly in the code. - Sometimes, dependency injection systems are so abstract that knowing which class is depended on in a specific runtime instance becomes a pain in the ass. - Your idea just won't load class x, the obvious…

These are job security features :P

Seriously though, the hours spent fighting dependency injection and Hibernate issues alone, when working on a really big Java project, could've been a full-time job.

For maximum fun, I once worked on a large ERP system that started out as a Struts 2/Hibernate 3/Jetty project and had an entire Rails app bolted on using JRuby. Some of the stuff in the JRuby side was injected thru Spring. ActiveRecord had to talk through Hibernate.

Re: Leaving Haskell behind

#136

Post by yakshaving_jgt »

rg111 wrote: post #117

I want to seriously invest some time into properly learn a functional language. My goals are simple- write small scripts, solve programming problems in sites like Codewars, Leetcode, Euler Program, etc. And yes, having the "functional enlightenment" or something similar. Which language should I learn and invest time into? Scala, Clojure, Haskell, OCaml?

Haskell.

Re: Leaving Haskell behind

#137

Post by ceddiexd »

Pannoniae wrote: post #6

Basically, the author's criticism is that the language is too powerful, too expressive, people try very abstract things, tooling is bad and no one cares about the language. There is something sinister in this - first, in the author's lamentations about bad tooling. Other languages require linters, formatters, static analysers, etc. because the language's built-in features and type system are sub-par. In Haskell, that…

Why use a programming language at all? Why not write everything in machine code for that matter?

The point is that Haskell's position on the abstraction spectrum is no less arbitrary than that of Go or C++. You cannot divorce the relative advantages and disadvantages of various levels of abstraction from the realities of maintenance, development time, readability, complexity, and yes, the fact that not everyone is as big brained as you, because by not writing machine code, you have already acknowledged that these realities matter.

I can just as easily come up with my own programming 'language' where there's a 1-to-1 mapping between a countably infinite set of characters and every unique Turing machine. Want to write a program? Find the right character. This is the most terse, most elegant programming language ever, but clearly helps no-one.

The best abstraction is the one that is the most universally understood.

Re: Leaving Haskell behind

#138

Post by otter-in-a-suit »

lihaoyi wrote: post #97

If you like Haskell but want something else, you really should consider Scala. It's not the same. But it has many of the same niceties around the rich type system, but with generally good tooling, the amazingly rich JVM ecosystem (tooling, libraries, learning materials), and a somewhat more pragmatic bent to it. Scala has a bad rep, justifiably so, due to a lot of its problems in the past: community, libraries, tools…

I agree. Scala is actually usable for real-world use cases on a much broader scale, simply by virtue of being on the JVM. I wrapped some of the (unergonimic-because-code-gen'd) AWS libraries in cats-effect just the other day, matter of fact. Some of the native libraries do suffer from this "stylistic neophilia" too, imo, but maybe not to the same degree as Haskell.

Also, Scala 3 made a lot of great improvements, although the tooling and library support arguably regressed w/ IntelliJ (I assume that's temporary) and some of the (on paper) positive changes - especially the whole type class derivation topic - make older articles and books _very_ confusing for people just getting into the language. I'd say making that migration happen in larger code bases and companies will continue to be a real-world challenge, but hopefully in the shape of a one-time effort, rather than constant changes.

Also, based on the username, I assume that the parent comment is by Li Haoyi. Funny how small the scala world is - I tend to see the same names (you, Alvin Alexander, Gabriel Volpe, John A De Goes) over and over. :)

Re: Leaving Haskell behind

#139

Post by consilient »

rowanG077 wrote: post #128
consilient wrote: post #122

Earlier quoted context omitted.

If you just want to add logging to existing operations, reinterpret them at the call site. Something like this newtype LoggedStateT s m a = LoggedStateT (WriterT s (StateT s m) a) instance (Monoid s, Monad m) => MonadState s (LoggedStateT s m) where get = LoggedStateT $ do val > lift (put s) (which is basically an ad hoc effect system) If on the other hand you want to reproduce the behavior of other languages, throw…

Which requires sweeping changes... In most other languages it's literally a one liner where you want to log something.

It requires changing the places where you instantiate your monad transformer stack, which you should have very few of.

Re: Leaving Haskell behind

#140

Post by JackMorgan »

Many of these reasons are why I moved to F# and haven't looked back (much). I sometimes miss Higher Kinded Types, but F# still has generics and if I'm being honest it forces me to write even simpler code then I would have in Haskell. I generally prefer this outcome.

However F# never feels "leet" like Haskell does. It's like Haskell, but all business. I get a lot done in F# and really enjoy it, but I'll catch myself looking back wistfully, like Haskell why couldn't we make it work. Sigh, the one that got away I guess.

Post reply on HN