Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

221–230 of 402 posts

Re: Leaving Haskell behind

#221

Earlier quoted context omitted.

I don't have any issues with Python's packaging ecosystem anymore, having settled comfortably into a pyenv+virtualenv+pip-tools as my "stack" after going around the block a few times. But even so, I must recognise how awful the experience is for new users. It's taken me years to settle into this system, and it can take half a day to get someone up to speed with these tools if they haven't used them. I also work a lot…

why do sometimes people say things like "and it can take half a day to get someone up to speed with these tools if they haven't used them" half a day is like almost no time at all half a day is just few hours, how is this a long time .. how is this any time at all makes me doubt myself a bit, am i too mediocre to think that way the previous line make more sense to me "It's taken me years to settle into this system" ,…

I don't think it's half a day to get proficient, it's half a day to hack something half working together so they're unblocked and can do the other stuff they want to do.

Re: Leaving Haskell behind

#222

Earlier quoted context omitted.

Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language. For some, things like Kotlin hit a sweet-spot. One can lean a bit more into a functional style, or they can lean more into an OO style and it's acceptable. Some are very interested in thinking in terms of Functors, Applicatives, Readers, etc... some just want map/filter/reduce. That's what the Streams API did for…

Kotlin doesn't get enough love. It gets derided by some Java developers for being too cutesy and sugary and it's not talked much about by the kinds of people who love to talk about Haskell, Lisp or Rust (no shade to these languages), but to me it's the most pragmatic language I've used so far.

> Kotlin doesn't get enough love.

Really???

It's probably the #1 language for new Android projects.

Re: Leaving Haskell behind

#223
My notes on using Haskell: mostly agree with the article, but I came to embrace rolling my own tooling, some abstraction on top of cabal. I use my abstractions, not what whoever would force on me. Use Haskell as your typed lisp.. with all the pros and cons.

On production use... Don't even get me started. Will work, but need shedding blood.

Re: Leaving Haskell behind

#224
post #78

Earlier quoted context omitted.

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…

I agree with some of that criticism (although I haven't had issues with having to manually delete files - if you do, I suspect it's a project that hasn't been set up with a proper maven/gradle setup but where all the build info is in some IDE config. that's an antipattern at this point but used to be very common). But I don't think it's necessarily about the tooling. And yes, Hibernate is just horrible.

Everything is in Maven and works fine in CI, which definitely does not use idea. But in some situations Idea believes the pom isn't as fresh as its rendition, unfortunately. I can live with some caching, but everytime that happens and the "clean cache" option doesn't work, I weep.

Re: Leaving Haskell behind

#225
post #51

Earlier quoted context omitted.

> I simply wanted to filter job offerings based on social utility rather than language stacks I wish more people did that.

In my experience the organizations that claim to have social utility fail at it and don't pay well. Language stacks are much easier to fact check.

You don't have to listen to orgs to make your opinion.

There are plenty of orgs that obviously produce a vital service for society, and they are usually starved of good IT people: health care, social services, logistics, electricity production & distribution, industry, agriculture, emergency responders, etc.

> and don't pay well.

:(

Well, the comp is still high enough to live a comfortable life, I just won't be able to bankroll a political party in the near future.

Re: Leaving Haskell behind

#226
post #24

Earlier quoted context omitted.

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

Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language. For some, things like Kotlin hit a sweet-spot. One can lean a bit more into a functional style, or they can lean more into an OO style and it's acceptable. Some are very interested in thinking in terms of Functors, Applicatives, Readers, etc... some just want map/filter/reduce. That's what the Streams API did for…

The meaning of my message wasn't that everyone should move to a functional language, but that Java devs shouldn't. The language has some decent features. Under all the OO patterns and abuses of framework, there was a decent core to save. My issue is that the community has declined to write their own "Java - the good parts", and tried to bolt half a dozen pair of wings on their supertanker because planes are faster than boats.

As a java-turned-haskell-turned-java dev, I can enjoy some OO programing, even though I prefer FP, but I definitely don't enjoy unprincipled FP riddled with side-effects, null pointers and built upon the quicksands of frameworks that are thoroughly unfit for that purpose.

Re: Leaving Haskell behind

#227

My notes on using Haskell: mostly agree with the article, but I came to embrace rolling my own tooling, some abstraction on top of cabal. I use my abstractions, not what whoever would force on me. Use Haskell as your typed lisp.. with all the pros and cons. On production use... Don't even get me started. Will work, but need shedding blood.

Typed lisp? Unlike Lisp, Haskell has enormously complex syntax, so generating code in it is a huge hassle.

Template Haskell is something to use only when absolutely necessary, while Lispers write macros without a second thought.

I considered your method of writing my own tooling, but have had a vague feeling that Lisp works better for this frame of mind.

Re: Leaving Haskell behind

#228

Earlier quoted context omitted.

Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions

It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.

Yes. I've been in teams where there has been gradle vs maven arguments.

Right now the Mac (M1 or M2) users in our team can't run our integration tests. It has been suggested that if we migrate our 50-100 services to Java 17 then the tests will work for them again. Trying to do this breaks the Gradle scripts, and the errors are so vague I can't tell why it's complaining.

Re: Leaving Haskell behind

#229
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 background (e.g. my last job used Scala extensively, but most had a Java background and treated Scala like a different syntax for Java; I had written more Haskell and ML, and treated it like an ML with JVM-gotchas). I highly recommend turning on all the scalac -Xlint options, using other linters like WartRemover, and treating the warnings as errors (annotations can silence the rare cases of "I know what I'm doing"; but there had better be a comment with a good justification, if you want it to pass code review!)

Whilst it's nice that there are loads of Java packages to import and use from Scala, it's usually a good idea to encapsulate them in a more "Scala-friendly" wrapper; e.g. to replace exception-throwing with `Try`, `null` with `Option`, etc. in order to maintain confidence in our code. With a little thought, and a sprinkling of Scala features (e.g. `lazy val`, by-name parameters, implicit arguments, etc.) such wrappers can end up being much easier to use than the original, too!

Re: Leaving Haskell behind

#230
post #24

Earlier quoted context omitted.

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

Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language. For some, things like Kotlin hit a sweet-spot. One can lean a bit more into a functional style, or they can lean more into an OO style and it's acceptable. Some are very interested in thinking in terms of Functors, Applicatives, Readers, etc... some just want map/filter/reduce. That's what the Streams API did for…

> Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language.

The ability to use pure functions is one of those hills I'll die on. Hearing that not all developers want a purely functional language is like hearing not all surgeons want to wash their hands, or not all accountants want to use ledgers.

Post reply on HN