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

281–290 of 402 posts

Re: Leaving Haskell behind

#281

Post by gmfawcett »

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…

Really, only the LSP comment relates to Java tooling. The other comments are about language, framework, and cultural issues. Not disagreeing with your observations, though.

Re: Leaving Haskell behind

#282

Post by gmfawcett »

xmcqdpt2 wrote: post #63
alex_smart wrote: post #49

Earlier quoted context omitted.

What is wrong with Java's tooling?

Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/refer…

Yes, Maven. Just embrace it, and move on: the decision will pay dividends.

Re: Leaving Haskell behind

#283

Post by dboreham »

mymac wrote: post #169
paulddraper wrote: post #118

Earlier quoted context omitted.

What dependency and backwards compatibility issues does Python have? That other languages don't?

Python software simply rots while you're not watching it. Either you make it a full time occupation, every time some library gets an 'upgrade' (with a ton of breaking changes) you get to rewrite your code, sometimes in non-obvious and intrusive ways. And every time the language changes in some breaking way you get to spend (lots of) time on debugging hard to track down problems because the codebases they occur in are…

> Either you make it a full time occupation

LOL Javascript enters the room.

Re: Leaving Haskell behind

#284

Post by gmfawcett »

grumpyprole wrote: post #270
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…

If Java is so great at solving these "simple" problems, then why do hugely complex frameworks like Spring exist? The language features of Haskell that you mention can describe your "simple operations" symbolically, you then just need to write a few different interpreters, one for real services, one for testing etc. No dependency injection, aspect-oriented programming or AbstractSingletonProxyFactoryBeans needed. You…

Strawman? Spring was not designed for solving simple problems.

Re: Leaving Haskell behind

#285

Post by epolanski »

Tainnor wrote: post #23
pyrale wrote: post #20

As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter job offerings based on social utility rather than language stacks), I definitely agree with the author's first point: the Haskell community values learning extremely strongly. That's great because you work with curious people that have always something to teac…

I've also used several languages and IMHO, Haskell's tooling is some of the worst. Language server breaks with random errors all the time for me, I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are), and so on. I have a project I work on from time to time, and I'm 100% sure that the next time I'll open it up, it will stop working again. Py…

+1.

I have in most years learned some nicher languages: Elm, Rescript, Racket, Common Lisp.

But nothing is even remotely bad as Haskell is.

Even just setting up an IDE to have basics like syntax highlight or go to definition is a giant chore.

On the official Haskell devcontainer offered by GitHub is nearly impossible to add any external dependency, so having a one-click shareable Haskell environment in the cloud (the very basic to onboard people on the language without wasting them days into having their own inconsistent environment) is a must.

Another thing that I feel sucks is the default documentation for Haskell libraries. Doesn't say anything useful at all, bundles few definitions here and there, 0 examples, and more often than not there's 0 documentation.

Re: Leaving Haskell behind

#286

Post by all2 »

swader999 wrote: post #265
pyrale wrote: post #20

As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter job offerings based on social utility rather than language stacks), I definitely agree with the author's first point: the Haskell community values learning extremely strongly. That's great because you work with curious people that have always something to teac…

I haven't seen better tooling than what's available for C#. Curious to hear from others who strongly disagree.

C# tooling is dense, but the build tools generally "just work" TM. Occasionally I have to purge my build artifacts because the build tool doesn't clean things up completely, but that is a small pain compared to working with python. Another commenter noted that Poetry is quite good and it is (I've noticed they added venv support directly into the tool - you still need pyenv to manage multiple venvs, though).

Re: Leaving Haskell behind

#287

Post by nologic01 »

js2 wrote: post #160
Tainnor wrote: post #23

Earlier quoted context omitted.

I've also used several languages and IMHO, Haskell's tooling is some of the worst. Language server breaks with random errors all the time for me, I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are), and so on. I have a project I work on from time to time, and I'm 100% sure that the next time I'll open it up, it will stop working again. Py…

It's weird how personal this is. Sometimes I wonder if it comes down to familiarity. I've been using Python professionally since 2000 and have never run into issues with its tooling. It's even easier these days: "python -m venv" and then pip are all I need in 99% of use cases. For local development I use direnv + pyenv. I typically develop on macOS and deploy to either macOS or Linux. I previously gave pipenv a try b…

I think complaining about Python's tooling has become like complaining about the weather in some cold and rainy country. Good for chit-chat and noding in resigned consensus.

In the meantime I cant recall any instance in the last five years (at least) where a project would fail to get going based on a simple venv and pip setup.

An exception is CUDA but I think we can agree this is not what you need to setup every day.

I wonder if that benign view due to Linux and people experiencing something very different in other OS's.

Re: Leaving Haskell behind

#288

Post by __d »

pdonis wrote: post #264
talideon wrote: post #146

Earlier quoted context omitted.

I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down. I've been settling on Hatch for most projects rather than using Poetry these days and Flit for smaller projects. It's managing to replace the mess of makefiles and shell scripts I used to have and supports standardised metadata. These days, I mostly use a combination of hatch, pip-tools (mostly when I'm dealing w…

> I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down First, a nitpick: it's pyproject.toml. YAML was considered for the language of this file and rejected in favor of TOML. Second, unfortunately, I'm not sure I share your optimism. This is an area where IMO the Python developers have never been able to do things right. In fairness, they are trying to support a lot…

100% agree re: TOML. Just ... why? Is there really something so compelling about it that makes it worthwhile being different to everything else?

The fact that the PEP was proposed with this, discussed, accepted, implemented and deployed with this is indicative of the failures of process that lead to many of Python's problems. Python3, async, threads, GUI toolkits, the whole mess of tooling ...

Languages and their ecosystems need someone to say "no". To maintain a pragmatic path forward for users of the language, not developers of the language. Python hasn't got this. With all respect to Guido, and now the core group, they let this slide way too often.

Re: Leaving Haskell behind

#290

Post by blueberry87 »

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…

What's your workflow for adding a new feature to something? In OCaml, with it's "high-tech language features like algebraic data types and ultra-strict typing", my entire workflow is: - Modify the types to add the new thing. - Fill in all the pattern matching cases that the compiler tells me I need to fill in. - Maybe write a little bit extra logic. And then i'm done, with a solution I know is type safe, will never crash unless i've explicitly let it, etc. How does this help with moving data? Well, wouldn't it be handy if the compiler could stop your program from crashing when something goes wrong, or you could have the compiler track where you've safely and unsafely done operations, or a million other things. Maybe this is too strong a statement, but if you can't see the advantage of that, I don't want to work with code you've written, because you're not doing everything you can to make it as safe as possible.
Post reply on HN