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

301–310 of 402 posts

Re: Leaving Haskell behind

#301

Post by valzam »

yw3410 wrote: post #248
reidrac wrote: post #195

Earlier quoted context omitted.

Scala has mostly all the issues the post is discussing. Perhaps once you're on Scala 3 you're going to enjoy stability, but your dependencies most likely won't give you that. And the JVM, and compilation times, and poor Scala 3 support on editors / IDEs. I prefer the Haskell tooling TBH.

The Scala community is incredibly committed to stability; every open source maintainer I know of in that space checks for binary compatibility when releasing as well as cross-compiling for multiple targets (Node, Web, Native) and versions.

The problem with scala is that the core devs seem to be working against what the community wants. At it's core it's still a research platform for many and it shows in the priorities for what gets included in Scala 3. Also while individual open source libraries are generally very stable and high quality the overall ecosystem is very fragmented and there is lots of churn (cats vs zio holy wars etc.).

Re: Leaving Haskell behind

#302

Post by inickt »

kajumix wrote: post #64

I have been using Scala. I have found that it can give you the best of both worlds. You can reason algebraically, and often after a refactor, if it compiles, it works. Type inference and monads works great too. You also get to benefit from being in the java ecosystem. In instances where it gets too esoteric, I can break rules and code more like java. I am curious what others think.

I have really enjoyed Scala for the same reasons. Has some escape hatches if needed, and a large ecosystem.

sbt drives me insane though, and is probably my least favorite part of the development experience.

Re: Leaving Haskell behind

#304

Post by root_axis »

d_burfoot wrote: post #267

As someone who uses a lot of "core" Java (ie not the messy ecosystem), and gets a lot of really complex stuff done with it, I read these articles about high-tech language features like algebraic data types and ultra-strict typing, and I think, what are these people actually doing ? The vast majority of software engineering consists of simple operations that move data from one place to another - from a DB to a JSON fi…

> The vast majority of software engineering consists of simple operations that move data from one place to another

All computing "consists of simple operations that move data from one place to another", that's essentially the foundation of computer science.

It seems you're trying to say "most software isn't that complicated", which obviously isn't true, in fact, the opposite is true: most software is a complicated mess.

Re: Leaving Haskell behind

#305

Post by yayitswei »

d_burfoot wrote: post #267

As someone who uses a lot of "core" Java (ie not the messy ecosystem), and gets a lot of really complex stuff done with it, I read these articles about high-tech language features like algebraic data types and ultra-strict typing, and I think, what are these people actually doing ? The vast majority of software engineering consists of simple operations that move data from one place to another - from a DB to a JSON fi…

The Blub Paradox is relevant here: http://www.paulgraham.com/avg.html

It's hard to know what you're missing if you haven't tried it. If you see patterns moving data around, it's nice to abstract those out. And higher-level languages give you more powerful abstractions.

Re: Leaving Haskell behind

#306

Post by cryptonector »

pyrale wrote: post #24
pooya72 wrote: post #14

If I had to choose the three big factors that contributed to my gradual loss of interest in Haskell, they were these : * the stylistic neophilia that celebrates esoteric code but makes maintenance a chore * the awkward tooling that makes working with Haskell in a day-to-day sense clunkier * the constant changes that require sporadic but persistent attention and cause regular breakages Valid points. Back in 2010-2012,…

> Take Java, for instance. It has added features like Streams, functions, lambdas, algebraic data types, records, and pattern matching. In a doomed attempt to escape the prison in which they were locked, the inmates defiled their language and adopted grotesque rituals inspired by the light they saw through the bars of narrow windows. They created an endless pit of suffering of their own, which is made tolerable only…

Funny to call voluntary insane asylum residents "inmates".

Re: Leaving Haskell behind

#307

Post by theCodeStig »

chriswarbo wrote: post #229
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…

Due to Scala's JVM heritage, it takes some discipline in order to have confidence in Scala code (e.g. that it won't throw exceptions, or return nulls, or do weird type casts, or overflow the stack, or have spooky action-at-a-distance, or have race conditions, or do inexhaustive pattern-matches, or not actually accept/return the types in its signature, etc.). This can be a tall order for shops which have a Java backgr…

This exactly.

The Scala community caters a lot to JVM/Java inter-op, and to recruitment of Java engineers. In the peak-hype days, Java compatibility, and Scala for Java engineers learning resources were a huge selling point for Scala. Now it is one of its greatest weaknesses holding it back. Even as late as June 2023, the second edition of Functional Programming in Scala is catered toward Java programmers.

Functional purity is an option in Scala (no pun intended), and the org/team must have the collective discipline to write pure code in-order to make it work.

Pure/lazy effect handling is not included, one must use a 3rd party library. There should be one, or a small handful of compiler options which would enforce purity by the compiler. There isn't. The -Xlint options are not easily discoverable. WartRemover is a 3rd party library, which doesn't get enough visibility. Some of the "good stuff" from Typelevel should be absorbed into the standard lib.

The numeric types are not ergonomic, there is no natural number type for example.

I haven't had issues with Haskell tooling, though I also use Nix. On the flip side, I've never heard anyone say "I love SBT". Yes there are alternatives to SBT (Mill for example), but again they suffer from low visibility. Martin Odersky has admitted faults with SBT, and praised Mill; yet, what does the Scala community push... SBT.

Re: Leaving Haskell behind

#308

Post by solidsnack9000 »

The author does a good job summarizing ways in which thinking through your Haskell programs is easier than in many other languages. There is a certain straightforwardness to it that, once grasped, is eye opening, appealing and fun.

Haskell opened the door for me to much more rigorous reasoning about correctness.

Re: Leaving Haskell behind

#309

Post by theCodeStig »

steno132 wrote: post #167

If you want to get things done, don't use Haskell. You'll be fighting against the type system constantly. You'll be asking questions on Stack Overflow only to get no response. You'll be rewriting software that's in other language's standard library. Productive programmers don't use Haskell.

The compiler/type system is your friendly assistant. Learn to use it, and it's your greatest asset.

Re: Leaving Haskell behind

#310

Post by kagevf »

mrkeen wrote: post #239
kagevf wrote: post #172

> the experience of code refactors via algebraic manipulation is still possible in other languages, especially in non-pure functional languages like Scheme or SML Wouldn't "code refactors via algebraic manipulation" require static types? How would this work in Scheme?

I think the requirement would be purity not static types, but I agree with your overall objection. (Then again, you need static types if you want to have pure functions, IO functions, and not mix them up)

> I think the requirement would be purity

Well, yeah, I think if I had instead said "if not static typing, then how would it be possible?" ... I had no idea how it could be done, but with something like purity - by which we mean deterministic functions, right? - I can at least start to see how it would be possible with Scheme.

Post reply on HN