8 months of OCaml after 8 years of Haskell in production

Links
#94

Trying to politicize programming communities has caused more harm than good.

I’ve also seen plenty of young people at ZuriHac and know a fresh graduate who just started their first Haskell gig.

4 Likes
#95

If your point is that we should all collectively stop striving for a better functional programming experience and instead go for boring high-paying jobs in companies that don’t care, then I don’t think you’re in the right space.

I don’t know why the community cares this much about industrial adoption. In my mind the best example of industrial adoption within Haskell is Snoyman’s work, that’s how we got a yaml library that uses JSON parsers and an xml-conduit library that cannot parse anything large because there were “no plans on working on optimizations” back in the day. This system produces tools that are good enough for a specific use-case, but they’re not good enough for the community as a whole.

It’s not just this, the tools and libraries should reflect Haskell’s vision: pure, composeable and concise, no hacks or shotcuts taken. The performance of an individual library matters only in terms of asymptotic analysis, the actual speed comes from the application doing the bare minimum of work required at a reasonable pace.

The ecosystem doesn’t need a plethora of XML parsers with no supposed go-to, it needs the definitive XML parser. It doesn’t need the hacky json-stream on top of the gargantuan post-parser that is aeson, there should just be a minimal JSON parser library that does everything in an extensible way. I shouldn’t have to invent lazy radix trees from scratch in a lazy programming language.

The same applies to Cabal’s internal design, which from the outside looks like 15 years of “things that worked” mushed together and I wouldn’t be surprised if it’s half the reason why the Cabal dev team is this swamped.

3 Likes
#96

You might be happy to know that we have been working on the new tar release, which now supports long filenames, symlinks, 8GB files etc.

This library has been in an awful state for over a decade. The main user was Cabal and for its small use case it was “good enough”, but not for anything else.

It’s a great example of the lifecycle of many Haskell libraries, which never make it beyond PoC stage.

I find it hard to comment on the reasons. I’m not even sure if it’s that different in other languages.

Tbh, I think the Haskell ecosystem would be far worse off without his contributions.

Although I have very different opinions in certain areas, fpcomplete seems to be (or was) one of the few companies in Haskell land who actually care about user experience.

8 Likes
#97

Hmm, this sounds more like a praise for encapsulation. Internal details are hidden from outside, so theoretically each component should do their job independently. Of course in practice it can break - it is not perfect. However, the same can be said for everything else. After all, you have to test the finished product again, to see that the constituting parts work in harmony.

In fact, we can see this kind of ‘modularization’ working in software industry at large. Cloud service providers, Operating system, Database, Supporting applications, and various web services… et cetera. IMO, this is alike the towing hitch production industry as well. Each part company produces specific part, and the hitch assembler company gathers them to create a finished product (which will be sent to car company, I guess). Yet, each company might not practice modularity discipline internally.

Well, rather, I am saying that one shall not develop clinging to a language. Be as flexible as possible, and prepare for the high possibility that languages and ecosystems that you once loved could vanish in a few years.

Career wise, IMHO (and I am less certain about this one but) a better approach would be to leave programming industry as a whole. The software industry does not have a good outlook once you exclude AI. Tech industry has been growing for long time, and it is basically everywhere now. Can it expand further? Maybe, but I am noticing some ripples suggesting otherwise.

#98

As always, everything is already politicized; the people that can ignore it are just the ones that are currently in control and/or currently benefitting.

7 Likes
#99

Unfortunately for me, I feel myself being quite aligned with the author of this post recently. I love so much about Haskell, but lately I’ve pulled away and I’m not sure I’ll be coming back.

I recently gave Rust an earnest evaluation and realized it really works quite well. The type system is not quite as strong as Haskell, and it has some annoyances which Haskell handles better (such as Result types and the ? operator, which is sort of like a Result specific do notation), but overall it’s been pretty fantastic.

I moved to Haskell because I wanted a type system that catches the majority of my bugs, and Rust definitely does that well. Ive been using it for just a few months now but I haven’t been hit by a runtime crash that didn’t involve me deliberately ignoring error cases.

But I think the big thing I’ve enjoyed more about it is that the libraries are more ergonomic. The libs always work in a simplistic way. I haven’t hit a scenario where it was awkward of painful to implement the functionality I want to write. E.g: Yesod requires all kinds of weird stuff to get routes setup. In Rocket, it was much simpler.

I like type safety, but I need simplicity too. Of course, dealing with Rust’s ownership/borrow system is a bit of a pain, but Ive found it to be a small hurdle to get over compared to some of the errors I’ve had to deal with in Haskell. I guess you might say Haskell in a way prepared me for Rust.

Anyways as I said, I’m basically aligned with the author at this point. I will always have a special place in my heart for Haskell, and I’ll probably try to keep up with all the recent developments of Haskell, but I don’t think it’ll be my default language choice anymore

5 Likes
#100

…which can be achieved by using the monadic type ST s a and runST:

runST :: (forall s . ST s a) -> a

But if you’re referring to that other leakier variety:

…amongst others! So I would suggest that you be as flexible as possible, and prepare for the high possibility that a certain programming-language paradigm that you still love could vanish in a few years.

Enjoy your new career, and try not to worry about the rest of us…

1 Like
My talk "Functional Programming: Failed Successfully" is now available!
#101

So the refrain goes. Making that statement itself can be a political act, an attempt to gather support to one’s cause. From my point of view I don’t see how that line of thinking is beneficial to the Haskell community, however.

4 Likes
#102

Rust certainly has its allure, and I tried to like it enough to drop Haskell, but for myself it represents a lateral step rather than a step forwards. The tooling is awesome and package ecosystem is large, but then other things are worse, like the lack of exceptions, concurrency and garbage collection. All of which are outstandingly ergonomic in Haskell. In Rust, async/await, errors, and borrowing are all awkward and leave their grubby mark all over otherwise simple code. For all its warts, which are well-described in that post, I haven’t yet found something I like better than Haskell.

12 Likes
#103

I meant to reply to the original post, but clearly the discussion digressed so far away that my answer would be offtopic at this point. Could we all be mindful that linear threading model is not friendly to tangential discussions and create separate topics for them?

6 Likes
#104

Please post your thoughts. I for one would like to read them, and I can’t think of a better way of keeping comments sections on-topic than by posting on-topic comments.

5 Likes
#105

I have PM’d OP when he first posted, pointing out to him that his (interesting!) column was prone to develop into a discussion on the larger Haskell ecosystem. I have asked him whether that was fine or if he preferred a somewhat stricter moderation for tangential replies.

He said he was fine with a more general discussion, and as long as he is fine with it, I am prone to have a hands-off approach.

If you feel some messages stray from “tangent but relevant” into off-topic land, flag them so moderators can act on those.

5 Likes
#106

As I mentioned earlier, modularization cannot be perfect - this is part of why manufacturing is complicated, after all. Further, each application running on an OS already provides good enough modularization, where each production department (or entire company) would focus on one program. You do not need this strict modularization inside the department.

Personally I dislike OOP quite a lot, and I prefer FP if anything. What I said was more of an observation. A modified version of OOP seems to be thriving, which does exclude inheritance but keeps the overloading and polymorphism. Recent success of Go signifies that, with Python expanding further. I cannot spot any glimpse of OOP fading away anytime soon, other than handful of opinionated blog posts like that.

#107

…just like Rust, Haskell and (I think) Idris - no notion of object-based inheritance, only overloading and polymorphism. But based on your prior posts, including those about Haskell and Rust:

#108

I received tons of feedback on my OCaml vs Haskell blog post! Thanks a lot to all who read and shared their thoughts :hugs:

Using the feedback, I improved my post by:

  • Changing the most triggering exponentiation example to a different one
  • Added links to all discussions of my blog post all around the Internet
  • Changed feature from Laziness by default to Composable laziness
  • Added topiary as an OCaml formatter
  • Changed the suggested TOML library from To.ml to otoml
  • Changed the suggested AWS library from ocaml-aws to awsm

As always, I’d appreciate your feedback!

@Bodigrim I’d be happy to read your and anyone else’s thoughts on my blog post! :hugs:
If not here, you can all reach out to me in other places to share what you think :relieved:

In the Haskell community, I often had the impression many people have a lot to tell but rarely feel heard. I’m glad to see that the discussion around my blog post gives people an opportunity to share their feelings. Reflecting on your experience is important too! In the end, that’s what I did in my blog post :sweat_smile:

10 Likes
#109
  • Work hard to knock down obstacles to using Haskell in mission-critical applications.

I’m optimistic that the Haskell community can make this happen.

With the renewed focus on stability of the language, compiler, and base-library, the community has shown that it is listening to its users. What might help with momentum and actionable goals is to measure the impact of these initiatives. Perhaps, as an example, querying Hackage or Git on how “fresh” the packages are and how often they are updated for GHC compatibility reasons can give some insights as to the burden package maintainers face and whether the situation is improving or not.

From what I gathered, the next big piece of obstacle is addressing the incidental complexities of using Haskell due to it being such a deep and feature rich language. As a newcomer myself, I think the most prominent issue here is there’s no de facto, agreed upon best practice among the community, so it’s been a dazzling and confusing journey for myself. Seasoned individuals and organizations have their own list of do’s and don’ts, but for increased adoption, it’s very helpful to have an authoritative source where newcomers can learn about best practices (or at the very least, safe practices), so we don’t shoot ourselves (and likely, others in the foot), and can produce libraries that are easy to maintain and easily consumed by others (e.g., not forcing the users to use a specific effect system, which could conflict with other libraries used).

Best practice topics like, which extensions are safe/recommended to use, when to use type-classes, when to use type-level programming and what are its associated costs, which parsing library is a safe/conservative default to start out with, what effect system to use; library design best practices like what constitutes a good functional API design, when should you expose fancy Haskell features to end users … etc., can guide newcomers in a direction that both enriches the ecosystem and build momentum in a newcomer’s journey to proficiency.

In summary:

  • [Code] Measurable decrease in the overhead of maintaining Haskell packages
  • [Documentation] Best practices on the following topics from a unifying and authoritative source:
    • Language features
    • Library selection (better distinction between experimental and production stable packages)
    • Sensible library/API design, especially when it pertains to Haskell/GHC’s ecosystem.

These are the areas that I feel can help drive adoption and allow Haskell to be selected in more mission-critical applications.

8 Likes
#110

…I thought that problem was already solved in 2015:

That it was a relatively simple and compact change to GHC (only 20 files affected) would have to be one of the more salient examples of Haskell’s efficacy. In comparison, it would be interesting to see what would be required to add either of -flazy or -fnonstrict to the likes of Standard ML, OCaml, Go or Rust - perhaps the implementors of Lazy Racket can be of assistance…

1 Like
#111

Conspicuous failure to die, and actually some significant and sustained improvement of long-standing weaknesses.

There’s another reason why Haskell won’t be dying any time soon:

If Haskell did disappear, designers and implementors of new languages would have to provide their own explanations of the monadic interface, and possibly their own monad tutorials! (unless someone remembered to do some archiving ;-)

#112

That’d be a very unfair comparison given that Strict doesn’t make Haskell a strict language in any reasonable sense (see this example), it just adds bangs to new definitions, i.e. it’s basically syntax sugar. Also going from lazy to strict is generally much easier than the other way around.

#113

That’d be a very unfair comparison […]

You mean like the ones I’ve responded to here:

  • https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946/199

  • https://discourse.haskell.org/t/pre-hftp-ghc-should-offer-low-level-logging-infrastructure/9159/27

  • https://discourse.haskell.org/t/since-haskell-has-linear-types-so-we-can-track-resources-why-cant-we-disable-the-gc-like-in-ats/7951/8

where:

  • Haskell is being compared to some ol’ warhorse,

  • or Haskell should have some (more) of its “features” *

…amongst others? Yeah, this Discourse seems to have a great many unfair comparisons.

* …apart from it’s style of records, apparently.