So, “Haskell isn’t as pure as people make it out to be–pure is actually a technical term when it comes to functional languages. We can support both OOP and procedural programming via some language facilities and libraries, but idiomatically, we’re the most functional language out there” doesn’t fly?
Are there good examples that showcase the use of compact regions?
One possible use-case is “deduplication”. A large series (10s of millions) of tasks have subtasks that can be part of multiple tasks, and need to be performed just once, with the result shared. The naive solution is to use a map of some sort to store subtask id to result (pending or final). As the map grows GC costs become quite noticeable.
Is there some way to use compact regions to tame the GC cost of progressively building a map with O(10M) keys (and associated values)? Is there a “compact” map type that holds all its keys and values in a compact region, how does it avoid hanging on to too much “garbage” as updates replace the root and internal nodes?
I tried using it in my IRC client to store the message history. I never measured to see if it actually helped, but message history is most of what my client spends its memory on.
1 Like
If Alexis King is a noob I’m off to Google “barrista courses”
6 Likes
Just on the topic of performance and GC, it seemed to me like linear types have a big role to play there, but I haven’t seen much in the space, especially w.r.t. adoption by libraries. Is the linear types vision alive? Or does it just need to be louder in its efforts?
Just on the topic of performance and GC, it seemed to me like linear types have a big role to play there, but I haven’t seen much in the space, especially w.r.t. adoption by libraries. Is the linear types vision alive? Or does it just need to be louder in its efforts?
Hi. The linear types project is still very much alive. The time that I, and my colleagues have, for it is less that I’d hope (hence the relative silence), but we’re making progress. Adoption is rather slow (at least, slower than I’d have hoped), and I must confess that there are some good reasons: integration of linear types doesn’t cover all of Haskell. The most embarrassing is that “let” bindings are not compatible with linear types! This is something that I’m, finally, about to propose a patch for (it was a surprisingly long journey), see #18461.
The next big thing, for me, will be to integrate the work that we’ve published last year on linear constraints, which I’m hoping to be great help for the design of comfortable APIs.
23 Likes
I worked on around 25 industrial Haskell codebases during consulting at FP Complete. I also participated in groups of Haskellers learning Rust. This topic is very interesting to me. Some things that come to mind:
- Every line of code, in any language, is a liability. Haskellers don’t treat code as a liability; especially juniors but also seniors, they rewrite everything in it, try out weird abstractions, use packages with a single maintainer for a core product feature, etc.
- The novelty budget is a very apt guide. When you use up your novelty budget, it’s very high chance that your project will be dropped and rewritten in $popular_lang. Haskell takes a big chunk of the novelty budget already, but Haskellers use more of it than necessary.
- The tooling problem is real. It is terrible and has been since I started in 2009. That makes Rust look attractive. Also, people don’t want to have to learn Nix to build their code projects. But ecosystem churn makes CTOs look back at Java.
- The compilation speed problem is real. If you count your CI build time in tens of minutes to an hour, rather than seconds, chances are you’re using Haskell and not Go. That makes Go look attractive.
In my view, the best way to use Haskell in industry and avoid it being dumped or rewritten is to be parsimonious, use existing packages from other languages that already work, minimize the upkeep required (think Casio watch vs Tamagotchi). Otherwise that codebase will get the chop.
29 Likes
Those are holy words. Code should never be treated as an asset.
5 Likes
I think these are great principles.
What do you mean by this exactly? FFI?
What is this referring to? Fancy-language features, complicated build-setup?
There are few ideas I find to be faker and more unhelpful than “novelty budget.” I really should just write an essay on it, but the fact that it frames novelty and understanding as fixed constants is the start of why it’s nonsense.
I pretty much have disregarded the concept since day one for 10 years of Haskelling now, and I am confident I’m better off for it.
I guess this touches more on the tension between companies and individuals. And balancing situations where things that are good for the company risk management are harmful for the individuals personal growth.
1 Like
…and how many other Haskellers would you think understand your own “personal brand” of obtuse novel Haskell?
They may not actually be fixed constants, but consider how much it costs to expand them constantly, particularly if your competitors are “just getting on with the job” by using a more standardised (and less speculative) approach…
1 Like
I find that it’s pretty easy to understand everyone’s style of Haskell even when it differs from my own. And it’s not hard generally to communicate with code as a professional.
I generally find this sentiment about code being so fancy that you declare bankruptcy to be something that exists more in forums than in reality. I have years of real Haskell experience on projects using libraries deemed by “production pros” to be fancy enough to “blow your novelty budget” - singletons, beam, extensible effects, optics, polymorphic records, and more.
It was fine! And I came into one of these projects with literally 0 Haskell experience and 0 formal FP education. Within less than a year I had learned a crazy amount and was suddenly “advanced.” So I’m glad that company didn’t care about novelty budgets.
And it’s why when people say to me now, “Ambrose, you know these concepts but you gotta understand that new people can’t learn this stuff” I raise my eyebrow 
Because I was that new person and the only reason I got to learn this cool stuff that has multiplied my Haskelling was because nobody was too scared to let me (and us - a bunch of new Haskellers hired by the company) try and sometimes fail and make a mess.
That company wasn’t wildly successful business-wise, but it did forge a lot of advanced Haskellers out of novices and set them out in the world. It created more advanced Haskellers from beginners than any other company I’ve seen actually. So that benefit to Haskelldom is one thing that’s missing in this discussion imo.
Your last point is related to the tension I mentioned above. I never take such a brutally-capitalistic, optimizing approach to engineering or engineering leadership (even if I am the founder!) That’s just a taste and preference thing though. Different strokes for different folks.
2 Likes
…and I would not advise it either! That would take matters to the other extreme, which has its own risks - an organisation that “regimented” risks losing out to one which is more innovative.
One of my regular merchants mentioned this analogy: pH - if it’s too high or low, your plants are probably going to have problems. It’s much the same with innovation and stability - it can’t be all one way or the other (unless an actual standard is being contemplated, of course); there has to be a balanced approach, ideally one which recognises that not everyone who uses Haskell will be “1337” Haskellers.
1 Like
This is the core bit of disagreement I have. I don’t believe in the idea of a “1337 Haskeller” in the first place! Skill (across domains) is inevitable and therefore uninteresting.
And even if we assume the “1337 Haskeller” exists - I honestly don’t think it takes a genius to do anything, no matter how fancy or advanced, in Haskell.
This is all a meta-pedagogy I guess. Do you need to protect students from advanced ideas? Are some people inherently more skilled? Do some people need to be forced to focus lest they chase shiny objects on a whim? My opinion for all of those is “no.”
1 Like
…if everyone had unlimited time to spare. But (at least the last time I checked) we don’t, and everyone’s “rate of up-skilling” is different. Therefore in the finite time we do have, some will be invariably be more skilled than others:
Well, I thought one of the goals of teaching was to bring the ability of students up to the point where they are able to deal with the challenge of advanced ideas. But do feel free to hand out notes on Gödel’s incompleteness theorems, Einstein’s general relativity, et al to first-graders at their first day of school - it should definitely make an impression on their parents!
1 Like
Therefore in the finite time we do have, some will be invariably be more skilled than others
Bell curves work for quantitative things. Haskell skill is in no way quantitative. So I don’t really subscribe to this world view about skill and the like. And it is a world view - not fact, not science.
In fact, one thing that annoys me about a lot of the discourse about Haskell in industry is how pseudo-scientific it is. “Novelty budget” and other things that use made-up math to “prove” engineering management principles all fall under this umbrella.
I think my comment already pretty clear addresses this. I don’t think shielding new professional Haskellers from advanced ideas is necessarily the best or only way for them to learn. My anecdote was all about that.
What do you consider scientific and proven about Haskell in industry and about engineering management?
Very little? It’s a humanity not a science.
1 Like
It’s about different business use cases.
Some firms want to attract highly-skilled Haskellers, for which the opportunity to work on cutting-edge, experimental, Haskell is a plus. They are willing to put up with higher on-boarding times or difficulty hiring, for the advantage of getting very skilled or very smart people together in one shop.
For other firms, the greater on-boarding times and difficulty hiring is not worth it, and they want a simple, trainable dialect that delivers software that is written quickly and just works.
The vast majority of firms and projects are better off with a dialect of Simple Haskell because of the business ergonomics; they want to be able to hire some random competent programmer off the street and get them to replace you in short order. From the classic management guru Peter Drucker, it’s a very bad thing for the firm (although not the worker) when you have a worker, manager, or executive that is hard to replace.
Moreover, the extremely deep skill tree of Haskell scares middle managers; i.e, it is always a challenge to manage people who are more competent or skilled than you are, not least because of how it affects the social dynamics.
If you are selling Haskell, the vast majority of the time, the firm explicitly or implicitly wants something that more approximates Python or Go than ultra-correctness / high-performance senior Haskell.
If you give them what they want, they are more likely to trial Haskell and keep it because it actually matches their requirements.
Where you go from there is up to you and them; they will likely always want a part of their Haskell codebase in a Simple Haskell dialect for the onboarding advantages. But can you get away with hiding fancy-typed Haskell in a library somewhere? If you can, is it good for the firm or is it a form of industrial sabotage? If it is good for the firm, what kind of contingency plans are there should you get hit by a truck or otherwise become unavailable?
2 Likes
People always talk about “advanced Haskell” as something with 10 GHC extensions enabled and type families and GADTs all over the place.
If you want to see advanced Haskell, I suggest to look at libraries that provide excellent primitives, like bytestring, text or containers. Some of those parts are quite advanced.
In the end, there are many parts of advanced Haskell. Shoving your entire program into the type system is really just one of them. And I’m not sure it’s the most interesting or useful.
6 Likes