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

251–260 of 402 posts

Re: Leaving Haskell behind

#251

Post by chopin »

Tainnor wrote: post #144
chriswarbo wrote: post #116

Earlier quoted context omitted.

I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially…

> there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix) Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time. That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.

But that can't be runtime dependencies to your code?

I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.

Re: Leaving Haskell behind

#252

Post by grumpyprole »

chriswarbo wrote: post #116
xmcqdpt2 wrote: post #63

Earlier quoted context omitted.

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…

I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially…

Yep, SBT and Gradle make Maven look good.

Re: Leaving Haskell behind

#253

Post by codeflo »

systems wrote: post #207
movpasd wrote: post #174

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

Half a day to get something running that's a "one off" for you is insane. With a compiled language project, I'd download a binary. In Python, I need to reproduce the developer's setup. And I've yet to find two different Python projects where the official build instructions are compatible -- each one recommends a different environment virtualizer, a different runtime, different settings, and different C libraries that aren't part of the virtualized environment.

Re: Leaving Haskell behind

#254

Post by kevin_thibedeau »

movpasd wrote: post #174
js2 wrote: post #160

Earlier quoted context omitted.

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

I have issues precisely because of the misguided preference for virtualenvs in favor of traditional system package installation. It's obnoxious that pip now admonishes you for installing into site-packages even on a Debian system where that can't cause massive breakage. When you need isolated containers it's great. Everyone doesn't need a webdev focused, reproducible build for everyday shell life.

Re: Leaving Haskell behind

#255

Post by dcow »

movpasd wrote: post #174
js2 wrote: post #160

Earlier quoted context omitted.

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

As someone new to using Python professionally after having used it here and there over the course of 15+ years, I’ve run into exactly this problem. It’s pretty standard for a language these days to bundle the dependency manager and build tooling. Python still does this via shell infection. And since there’s 5 different ways to do it it can leave someone trying to figure out what the right vibe is in 2023 spending hours reading about the pros and cons of everything. And all that just to land back on venv+pip+requirements.txt.

Python needs a cargo. Is Poetry it? I’ve been meaning to try it…

Re: Leaving Haskell behind

#256

Post by tinco »

runeks wrote: post #84

> The way that Haskell-the-language evolves — well, the way that GHC evolves, which is de facto Haskell since it's the only reasonable public implementation — is that it gradually moves to correct its past missteps and inconsistencies even in pretty fundamental parts of the language or standard libraries. I would say that the biggest problem is that GHC is tied to a particular version of base (the standard library).…

> I still don't understand why this is necessary. Why must code compiled with GHC 9.6 use base version 4.18.0.0? Why should the binary that is GHC care about which version of the Data.List module the code that it compiles uses?

Because the underlying data types might be different, so if different libraries linking to different `base` implementations pass each other instances of `Data.List`. Imagine for example a Data.List Data.List, could you append the results of functions out of two different libraries to that list?

Re: Leaving Haskell behind

#257

Post by dcow »

kevin_thibedeau wrote: post #254
movpasd wrote: post #174

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…

I have issues precisely because of the misguided preference for virtualenvs in favor of traditional system package installation. It's obnoxious that pip now admonishes you for installing into site-packages even on a Debian system where that can't cause massive breakage. When you need isolated containers it's great. Everyone doesn't need a webdev focused, reproducible build for everyday shell life.

You really shouldn’t, though. If you use a dependency manager for some deps you should use it for all deps. Using a global/system cache would be great if dependencies were versioned and each script could specify which version is needed, but they’re not to my knowledge. And it’s all fun and games until some random install script somewhere updates a global dep and your stuff breaks and you don’t know where to even begin looking.

Re: Leaving Haskell behind

#258

Post by george_____t »

nonameiguess wrote: post #134
bradrn wrote: post #88

Earlier quoted context omitted.

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/

It's listed after Cabal as an "alternative", so a lot of people will presumably ignore it if they don't see any reason why they'd want anything else.

I personally wish that page were even more opinionated, but it's politically tricky.

Re: Leaving Haskell behind

#259

Post by george_____t »

jgwil2 wrote: post #183
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…

Haskell's tooling has put me off ever really trying to get into it again. However, I've dabbled in Purescript a few times and it always seems to offer a pretty smooth experience, especially if you're familiar with JS tooling.

It has been rapidly improving over the last few years, though this can mean it's difficult to keep up.

HLS (the LSP implementation) in particular is a pretty young project, and key compiler improvements which will help it improve are still landing.

Post reply on HN