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

321–330 of 402 posts

Re: Leaving Haskell behind

#321

Post by consilient »

xwowsersx wrote: post #276
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,…

> The community went from Cabal (and the infamous Cabal hell) to Stack, and back to Cabal. I didn't know this. I've been away from Haskell for a couple of years. When I last used the language, Stack seemed like smoothest experience and solved many of the pain points with Cabal. The community went back to Cabal? What did I miss? :)

> The community went back to Cabal? What did I miss? :)

Cabal got better, stack stayed the same. It's more a cultural divide than anything at this point.

Re: Leaving Haskell behind

#322

Post by consilient »

chubot wrote: post #209
girvo wrote: post #60

Earlier quoted context omitted.

> I’m still thirsty for a PL that is essentially OCaml but with a better syntax. But that’s just me. Not just you, me too! In fact it’s why I went in deep on Reason when it arrived initially. Shame it never really got traction.

Me three! I came from Python (now with MyPy), learned OCaml and liked some aspects, was intrigued by Reason -- and also sad it seems to be in limbo. I also miss early returns, and break/continue. I would like "modern ML" / "Python with sum types" / "Rust with GC" language (indentation/braces doesn't matter to me). Many people seem to agree. Recently I found TypeScript is kinda fun for this, at least if you're startin…

> AFAIK TypeScript's type system can do everything in OCaml -- it's extremely expressive

Extremely expressive and unsound. And not just in a trivial "escape hatches exist but you should never use them" way - until you've been burned enough it's not at all obvious which operations are unsafe, and there are a lot of them.

Re: Leaving Haskell behind

#323

Post by MBCook »

pyrale wrote: post #224
Tainnor wrote: post #143

Earlier quoted context omitted.

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.

I don’t tend to run into that. But you should be able to fix it right clicking the pom and choosing Maven -> Reimport.

The number of times I actually needed to clean my cache I could probably count on one hand over the last 10 years.

Re: Leaving Haskell behind

#324

Post by consilient »

chubot wrote: post #199
andolanra wrote: post #187

Earlier quoted context omitted.

The former is referring to representing an AST using a GADT in order to include the typing discipline of the target language in the host language. For example: data Term t where Num :: Integer -> Term Integer Bool :: Integer -> Term Integer Add :: Term Integer -> Term Integer -> Term Integer IsZero :: Term Integer -> Term Bool IfThenElse :: Term Bool -> Term a -> Term a -> Term a With this AST, you can express well-t…

Ah thanks for the answer, funnily enough that's what I recently read here - https://dev.realworldocaml.org/gadts.html They have a bool / int expression language example. (And funny thing I'm coding up such a type checker and evaluator right now in TypeScript. TypeScript union types seem to be pretty expressive and useful for this problem.) However I'm STILL confused ... Admittedly I skimmed through the GADT chapter a…

> That's a little weird to me ... it seems to be confusing the metalanguage and the language being implemented.

Well, that's sort of the point. It's perhaps a little less important if you're writing a compiler for a separate programming language, but that's a relatively rare use case. GADTs are mainly used for implementing DSLs to be used elsewhere in the same program.

> Is the more abstract GADT solution supposed to "save" you some work of writing a type checker by somehow letting you reuse Haskell or OCaml's type system to express that?

Yes. Writing your own typechecker and integrating it into an existing compiler pipeline is a ton of work, easy to screw up, and a potential compatibility nightmare.

> I also wonder how all that is actually implemented and expanded into running code. The GADT syntax seems to get further and further away from something I imagine can be compiled :)

GADTs are syntactic sugar for constrained type constructors. So this

    data Example a where
         Example :: Int -> Example Int
becomes this

    data Example a = (a ~ Int) => Example a
which is then compiled to a type coercion in the intermediate language

Re: Leaving Haskell behind

#325

Post by chubot »

consilient wrote: post #322
chubot wrote: post #209

Earlier quoted context omitted.

Me three! I came from Python (now with MyPy), learned OCaml and liked some aspects, was intrigued by Reason -- and also sad it seems to be in limbo. I also miss early returns, and break/continue. I would like "modern ML" / "Python with sum types" / "Rust with GC" language (indentation/braces doesn't matter to me). Many people seem to agree. Recently I found TypeScript is kinda fun for this, at least if you're startin…

> AFAIK TypeScript's type system can do everything in OCaml -- it's extremely expressive Extremely expressive and unsound . And not just in a trivial "escape hatches exist but you should never use them" way - until you've been burned enough it's not at all obvious which operations are unsafe, and there are a lot of them.

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 'deno check' command I'm using turns strict mode on by default, so that's good.

https://deno.land/manual@v1.4.1/getting_started/typescript

All widely used gradual type systems are unsound because they have to interoperate with untyped code, and the dynamic checks to make it sound are too expensive.

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?

I guess by "unexpected" I mean that, at runtime, an operation is performed on a value which is not allowed, and the program fails

---

I googled and found this -- https://effectivetypescript.com/2021/05/06/unsoundness/ -- not sure I agree with some points, e.g. array out of bounds isn't unsoundness! The OPERATION is legal, but the data isn't, which isn't something that any type system will tell you.

Similar to divide by zero -- a runtime error does not imply unsoundness.

Also, casts can produce unexpected runtime errors by definition -- that's why they are casts, and you have to opt in! Bad article.

---

I think these are better examples: https://news.ycombinator.com/item?id=15659657

I believe Java has some of those too. Covariance / contravariance is a common source of unsoundness, but definitely not a dealbreaker for me

Re: Leaving Haskell behind

#326

Post by chubot »

brightsize wrote: post #315
chubot wrote: post #209

Earlier quoted context omitted.

Me three! I came from Python (now with MyPy), learned OCaml and liked some aspects, was intrigued by Reason -- and also sad it seems to be in limbo. I also miss early returns, and break/continue. I would like "modern ML" / "Python with sum types" / "Rust with GC" language (indentation/braces doesn't matter to me). Many people seem to agree. Recently I found TypeScript is kinda fun for this, at least if you're startin…

Have you had a look at Coconut? I don't know if it'll push all your buttons but whenever I hear someone who's reasonably content with Python but wants more FP goodies I always think of it. https://github.com/evhub/coconut . It's basically a superset of Python3 that transpiles into Python3 and is compatible with MyPy. I don't think I'd code Python w/o it ever again assuming I had the choice. The biggest negative for m…

I actually want the imperative Python style, but with sum types. So it's more like "Rust with GC" I suppose.

I used to write in a functional style, and then I wrote Python for decades, and my brain flipped. Now I like imperative code :) I guess it's all the usual things about liking break / continue / early return, local mutation, flat code rather than nested code, etc.

Re: Leaving Haskell behind

#327

Post by grumpyprole »

gmfawcett wrote: post #284
grumpyprole wrote: post #270

Earlier quoted context omitted.

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.

Maybe. I've seen few Java apps that don't use Spring or something similar. The parent described a simple domain, arguing it is the common case, but nonfunctional requirements like testing typically make the problem more complex. So I dispute that Java is good enough for the common case and that nothing from Haskell would be beneficial. Incidentally, Java's leadership agrees.

Re: Leaving Haskell behind

#328

Post by pharmakom »

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…

How do you build a bundle for Linux from macOS? In my experience this is only possible with Docker, and is a huge weakness of the Python ecosystem. Would love to hear solutions.

Re: Leaving Haskell behind

#329

Post by movpasd »

dcow wrote: post #255
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…

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…

I've tried Poetry, the CLI is nice and user friendly to be sure, but it has many flaws that made me ultimately avoid it.

In my opinion, it tries to be far too "magic", hiding everything about the virtual environment and dependency management within it. This means that if anything breaks (and it does break!), I find it basically impossible to fix it without wiping everything and rebuilding the environment from scratch.

I find the documentation nice and clean to look at but somewhat clunky to navigate and very incomplete or not explicit enough — especially for beginners. For a tool that seems to want to be a "one-stop shop", you need to know a good deal already about Python packaging already to navigate it. The lack of explicitness also makes it hard to troubleshoot (as evoked above).

These are by far my biggest complaints, with the below bring mostly minor gripes.

Additionally, it seems to be targeted at library developers rather than applications (a distinction which to be fair none of the Python ecosystem makes, to the detriment of DX). This doesn't usually end up being a big issue as it's reasonably easy to "librarify" applications, but it's something else to learn. (Not every project wants wheelification as its end goal.)

The usage of pyproject.toml is nice, but the semantics of the file isn't quite as standardised as one might hope, especially when it comes to reflecting the package you're writing in the virtual environment. And the documentation around pyproject.toml is scattered and sparse. (A PEP is not documentation!)

I've complained a lot, so I should round off by saying that Poetry is a commendable project and I have high hopes for it; but as it exists now it's just too rickety for me to recommend it. But others may disagree, and by all means I'd give it a try for your next project.

My personal recommendation remains pyenv + virtualenv (or venv) + pip-tools, with simple projects just using a requirements.in files and then moving to pyproject.toml once it reaches a modest degree of maturity.

Re: Leaving Haskell behind

#330

Post by Pannoniae »

mathisfun123 wrote: post #303
Pannoniae wrote: post #289

Earlier quoted context omitted.

that lisp is a perfectly usable language for writing cool and usable things :)

what exactly is hn usable for other than aggregating links and text comments?

If it wasn't an usable and/or interesting thing, you wouldn't use it...
Post reply on HN