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

371–380 of 402 posts

Re: Leaving Haskell behind

#371

Post by [deleted] »

runeks wrote: post #335
ryukoposting wrote: post #297

In terms of tooling, Haskell has one thing that AFAIK no other language can compete with: Hoogle. Hoogle is amazing. You tell it, in Haskell, what you want, and it tells you, in Haskell, what you can do. It's extraordinary. Someone attempted something similar with Rust, and I even tried to make a Noogle (Nim), but it just doesn't work the same in languages where there's a clear divide between "passing arguments to a…

Hard agree on Hoogle — it's amazingly useful. But wrt. other tooling, I use haskell-language-server every day and it makes me so much more productive. Sure, it isn't perfect, but so much better than what we had just five years ago.

[deleted]

Re: Leaving Haskell behind

#372

Post by zzo38computer »

rowanG077 wrote: post #363
zzo38computer wrote: post #318

Earlier quoted context omitted.

I have used many different programming languages (including BASIC, C, Python, JavaScript, Java, Perl, PHP, Haskell, Lisp, and others), even with powerful abstractions (which I can understand how helpful they are), and I still think C is better, and mostly use C. There are improvements which could be made (and I have some ideas of such), but most of the stuff I have seen is usually just worse instead. Some GNU feature…

If you seriously think C is THE best programming language you should simply be banned from writing code. Seriously. C is completely memory unsafe, all languages which are memory safe surpass it by default.

I do not think C (or any other programming language) is the best programming language. However, I think that the memory safety often gets in the way, and that even if it is helpful (which it often is), memory safety is not the only important or helpful feature anyways.

Re: Leaving Haskell behind

#373

Post by chubot »

consilient wrote: post #336
chubot wrote: post #325

Earlier quoted context omitted.

I think if you're writing code from scratch, this doesn't really apply -- I'm talking about prototyping language implementations without any libraries at all, sorta like you would do with OCaml from a textbook (e.g. TAPL by Pierce) (I'm aware of all the terrible experiences people have with TypeScript in the NPM ecosystem. But TypeScript is a big, mature tool and you can use it in more than 1 way.) I just noticed the…

> But code written from scratch doesn't have that issue. I'd be interested in a counterexample -- is there a code snippet that passes the strict mode of the compiler, and doesn't interoperate with untyped code, but produces an unexpected runtime error? You'd think so, right? But no, typescript is deliberately unsound in ways that have nothing to do with gradual typing. Here are a few examples. Signatures written in m…

Great examples, thanks!! I typed them all into the TypeScript playground.

I agree this is weird, and seems to follow from TypeScript's heritage as "trying to describe whatever dynamic JS does"

I mean that's probably why I didn't use it for >10 years (in addition to its JS heritage). But I did find that there is an interesting subset, at least for playing around.

I think the JSON.parse() issue is fundamental -- it's not clear what they could have done better, and static languages don't really do better. There is a fundamental problem there -- type systems are interior to a process, while data is exterior (https://www.oilshell.org/blog/2023/06/ysh-design.html)

I'm going to read this static TypeScript paper -- https://www.microsoft.com/en-us/research/publication/static-... Hopefully that's a sound subset :)

Re: Leaving Haskell behind

#374

Post by js2 »

impulser_ wrote: post #312
dcow wrote: post #255

Earlier quoted context omitted.

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

Have you tried Rye? https://github.com/mitsuhiko/rye This is probably the best package manager I used for Python. It feels a lot like Cargo. It sticks to the standards of Python. No custom lock files ect. Uses prebuilt Python so you don't have to build it. Handles global installs easily.

> Correctly installed, rye will automatically pick up the right Python without manually activating the virtualenv. That is enabled by having ~/.rye/shims at higher priority in your PATH.

I dislike this pattern. I don't want every language/tool manager in my PATH all the time. I much prefer the direnv. I hook only direnv into my shell. Then I can do what I need with an `.envrc` in each project directory.

Re: Leaving Haskell behind

#375

Post by goto11 »

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…

Weird then, that amazing software like Minecraft is written in Java, while Haskell seem to be mostly used for writing monad tutorials.

Re: Leaving Haskell behind

#376

Post by kagakuninja »

chriswarbo wrote: post #231
kagakuninja wrote: post #217

Earlier quoted context omitted.

I think that is less about Scala 3, and more that the companies were not committed to the use of Scala, and would eventually move to some other flavor of the month language, such as Go or Rust. The transition to Scala 3 at my current job has not been an issue. Scala 3 is mostly the same language, with some nice new features which are optional. Our old projects are still on Scala 2, as there isn't a huge benefit from…

Library compatibility was preventing us upgrading from 2.12 -> 2.13; Scala 3 wasn't even on our horizon :(

By contrast, over the last 8 years I've migrated a number of small micro services up from every version of Scala since 2.10 with no problems, maybe some minor dependency hell with some of them. I've even upgraded a simple project to Scala 3 with no code changes.

It depends on what libraries you use. The big hurdles tend to involve macros and Spark.

Re: Leaving Haskell behind

#377

Post by [deleted] »

rowanG077 wrote: post #367
tome wrote: post #365

Earlier quoted context omitted.

It's not a shortcoming of the language; it's a shortcoming of the goal! You can't have both the goal of fine-grained effect tracking and the goal of not having to make fine-grained changes when effects change. They're incompatible goals in any language. The strength of Haskell is that it allows you to achieve the first goal if you want. Most languages don't (pretty much no other language, actually).

That's an extremely limited point of view. Just because Haskell allows precise specification does not mean it is impossible to disallow loose specification. In fact that's one of the strongest values of Haskell's type system. For example you can overconstrain your head function head :: [Int] -> Int But you can also just leave out the type signature all together to let the type checker figure out the most generic type…

[deleted]

Re: Leaving Haskell behind

#378

Post by Aerbil313 »

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

This whole thread is a discussion of ease vs. simplicity. Easiness is subjective, simplicity is not. We should not compare tools in terms of their ease of use. There was a famous talk on this, maybe someone can link.

Re: Leaving Haskell behind

#379

Post by tome »

rowanG077 wrote: post #367
tome wrote: post #365

Earlier quoted context omitted.

It's not a shortcoming of the language; it's a shortcoming of the goal! You can't have both the goal of fine-grained effect tracking and the goal of not having to make fine-grained changes when effects change. They're incompatible goals in any language. The strength of Haskell is that it allows you to achieve the first goal if you want. Most languages don't (pretty much no other language, actually).

That's an extremely limited point of view. Just because Haskell allows precise specification does not mean it is impossible to disallow loose specification. In fact that's one of the strongest values of Haskell's type system. For example you can overconstrain your head function head :: [Int] -> Int But you can also just leave out the type signature all together to let the type checker figure out the most generic type…

It's an interesting idea but I can't say I feel that would solve a problem I've ever had. In fact, I always completely annotate top-level definitions with their types. I never want them inferred. And I've never felt it too burdensome to fix up a call stack when adding a new effect. But if you consider that a weakness of Haskell then so be it!

Re: Leaving Haskell behind

#380

Post by Aerbil313 »

dcow wrote: post #257
kevin_thibedeau wrote: post #254

Earlier quoted context omitted.

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

I’m still waiting for Nix to mature and for its UX to improve.
Post reply on HN