ddellacosta

I feel pretty confident that Haskell is generally unpopular and so would be poorly represented in any of the statistics you asked about, but you can take a look at the SPJ talk in my other comment if you want some seven-year-old numbers--I suspect its status hasn't changed substantially since that talk though.

Regardless, this has nothing to do with what I wrote in the comment you were responding to, so I'm not sure what your point is in raising these questions.

Also, it's worth watching a bit of this talk (link at a particularly relevant time to start) because while Haskell is an "ivory-tower language," it is not _just_ an ivory tower language, and the people working on it are very much not just "a merry bunch of category theorists who had little interest in software engineering."

https://www.youtube.com/watch?v=re96UgMk6GQ&t=802s

This talk is seven years old btw. Caring about industry users in Haskell is not new.

> The reality is that you realize that this language was designed by a merry bunch of category theorists who had little interest in software engineering. The effort put into different parts of the language is super unbalanced. GHC is an impressive feat of compiler engineering. But the other tooling is poor, and so is support for basic features such as records.

> Whatever extra bugs are caught by Haskell’s elaborate type system that wouldn’t be caught by a simple type system like Java’s, are replaced by bugs introduced by laziness.

I think you're simply wrong. I've been writing software professionally for almost 30 years: say what you will about Haskell's weaknesses, I've consistently found it to provide a better _software engineering_ experience than most other languages I've used. The only thing I think comes close is Erlang/Elixir, and even then I miss the sophistication of Haskell's type system all the time--the ability to make a change one place and have the type checker tell me so much about where else I need to make corresponding changes is invaluable.

Feeling constrained in what I can express because the type system forbids it almost always leads me to realize a logical fallacy in how I've been considering a given piece of code. And yes, Haskell records are bad in a lot of ways, but it still isn't enough to make me throw the baby out with the bathwater, and the existence and utility of row polymorphism in PureScript in my mind dismisses the notion that this has something to do with the type system.

In fact I think this article is frustrating and off base because I value Haskell so much for its ability to help me write useful, maintainable code; I don't care about esoteric extensions or type-level programming other than how much it enables me to solve problems.

I don't get why so many people have the attitude about Haskell that you do. I think a lot of people bounce off of it but this is not the same as asserting that it doesn't live up to the promise--it does, and then some, as far as I'm concerned.

Then again, I was also a jazz performance major

It's a bit hidden in their about page:

    GNU Guix provides state-of-the-art package management features such as transactional upgrades and roll-backs, reproducible build environments, unprivileged package management, and per-user profiles. It uses low-level mechanisms from the Nix package manager, but packages are defined as native Guile modules, using extensions to the Scheme language—which makes it nicely hackable.

https://guix.gnu.org/en/about/

I love this place. I lived in Tokyo a while back, these are all over. I had one down the street from me in my neighborhood in Meguro-ku. Notably, the tables and counters had big metal (I think?) tubs of sauce planted on them and there were all these signs warning you not to put your kushikatsu directly in the sauce. I think I always ended up putting a bit on a small plate and taking it from there.

I would go there and get a bunch of fresh grapefruit sours and just eat deep fried, breaded meat, eggs, veggies, etc. for practically nothing until I was stuffed. The vibe was working stiffs meeting up to hang out and complain or long-lost friends enjoying some fried food and draft Kirin or whatever. Very casual, tasty, and fun. 懐かしいな

TIL, nice--thanks!

Oh yeah, you just reminded me of this cool talk I saw at Strange Loop a while back. Not about the AI parts but re: program synthesis in Haskell:

"Type-Driven Program Synthesis" by Nadia Polikarpova https://www.youtube.com/watch?v=HnOix9TFy1A

Links to more projects and papers by Prof. Polikarpova: https://cseweb.ucsd.edu/~npolikarpova/

I think this is one of the main projects she discusses in the talk: https://github.com/nadia-polikarpova/synquid

EDIT: meant to mention this too, which I think has been around a bit longer, not that I've ever used it in production: https://ucsd-progsys.github.io/liquidhaskell/

This and the responses that are piling on with the same sentiment are offbase.

I am not seeking out opportunities to badmouth Elm. But as I am someone who is interested in FP and frontend tech in general, when I see an Elm story on the frontpage I click on it to see what folks are saying. And when I see exclusively glowing and positive statements (which was the case when I first posted) then I feel like I have an obligation to point out that there are some big issues with how Elm is maintained, because this is the sort of thing that _I_ would want to know before I spent a bunch of time digging into it.

If you want to watch the dang movie go ahead. But anyone asserting that those of us posting negative things about Elm are acting cult-like (seriously?) is being disingenuous. Considering the audience, there are good reasons to highlight the--IMHO major--problems with how the Elm project is run, and not mentioning them is irresponsible.

Yeah the way tuples work in PS is kinda painful, but there are some affordances for tuple-like pattern matching that smooth over some of that pain.

On the other hand, I feel like PureScript's records that utilize row polymorphism are such a game changer that it's hard for me not to get frustrated with Haskell records when I go back. And while I love where Haskell is going with WASM and JS support, I think it'll be a little while before that is viable for real-world projects.

I wouldn't bother with Elm. Among other things: https://www.reddit.com/r/programming/comments/fxvlow/why_im_...

PureScript (https://www.purescript.org) on the other hand is very nice.

Hey you gave me an excuse to link to one of my favorite PWL talks: "A Rehabilitation of Message-passing Concurrency" by Frank Pfenning - https://www.youtube.com/watch?v=LRn_nPfti-Y

Will take a look--thanks. Also, re: anesthesia, appreciate that you linked to the "Electron spin changes..." paper in the other comment, will check it out!

(In support of your point about QM:)

To contrast with an example of where quantum mechanics is relevant at the level of biology--this is one I'm familiar with:

https://www.sciencenews.org/article/quantum-fragility-may-he...

Unfortunately I'm not finding anything related to anesthesia except for hand-wavy pieces about "quantum consciousness" (anyone, please do correct me with a link or two if I'm wrong). I blame Sir Roger Penrose, if only because him talking speculatively about it (even in a sophisticated, informed way) seems to give so many others leeway to speak far more casually about the same topic, with far less coherence. This is why we can't have our cake and eat it too I guess

This is a bit of an indirect answer, but I watched this not too long ago and it made it seem clear that MOND doesn't work so well, if not in general at least in the case discussed, which seems pretty damning regardless: https://youtu.be/HlNSvrYygRc?si=6on0pD9_jsed9Dlm

I've also heard the bullet cluster pointed out as a strong counterpoint to MOND--I'll let you read the wikipedia page rather than attempting to explain this, poorly: https://en.wikipedia.org/wiki/Bullet_Cluster

As a layman who watches tons of astronomy and physics videos, my general sense is that dark matter is more or less simply a placeholder, such that everything else around it is pretty consistent, but it just represents this unknown matter that we can clearly observe interacting _gravitationally_ with galaxies and other objects in the universe, but otherwise doesn't seem to interact. Whereas my impression of MOND is that it's a set of heuristics that requires a lot of tweaking to work, whereas GR is quite simple and very strongly experimentally verified. But, again, layman

I think it's also the case that multiple concepts end up manifesting in ways that we can't envision or simply don't consider (see Marshall McLuhan). For example, this was also science fiction, but is probably much more relevant than a two-way radio when considering how we use our mobile devices, even if the form factor is far closer to a tricorder: https://en.wikipedia.org/wiki/Memex

"Strong typing" was a poor choice of terminology here.

https://en.wikipedia.org/wiki/Strong_and_weak_typing

Location: NYC area

Remote: yes

Willing to relocate: no

Technologies: most recently, Haskell, Lua, PureScript, Ruby (on Rails), JS, Nix, Postgres/RDS/Redshift, a bunch of other AWS services...much more.

My interests lately are centered around home automation/IoT, as I've been working on my own home automation tool (https://github.com/ddellacosta/automation-service), and I've also been trying to get familiar with LLM tech via some bindings to llama.cpp in Haskell (https://github.com/ddellacosta/llama.cpp-bindings) --I hope to use that in my home automation project at some point.

All of that aside, I'm an experienced web developer, I've worked in a large number of domains over the course of my career, and I'm always interested in picking up new things!

I'm looking for full-time employment but would consider contract or part-time as well.

Résumé/CV: https://drive.google.com/file/d/10_IvTiwd1n4vIy6ajwkyWuB7Fpz...

Email: ddellacosta@fastmail.com

I remain in awe of him. Turing indisputably had an incredibly important role in computer science. His code-breaking work saved many lives in WWII, and he even contributed an important result to biology: https://www.nature.com/articles/nrm3120 https://en.wikipedia.org/wiki/The_Chemical_Basis_of_Morphoge...

The way he was treated by his country after all he achieved and the lives he saved is a great outrage and a tragedy, and I always wonder what else he may have contributed to the world had he lived longer.

> I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs

What distinguishes the approach from what is presented in this blog post, can you provide a summary for those of us who haven't read the book? I am sincerely interested.

Yeah, this is what gets me--and at least on IOS you can get a sense of this simply at looking at the difference in what data the app requests access to compared to e.g. Apollo.

> My pet hypothesis is this will also why the current/next generation is much more open about sexuality / gender / identity, and I expect this to get only more nuanced as science understands more and as people learn to express more. But that's just something I cooked up. Anyone else feel this way?

I'm not sure if it's true or not, but it's something I hope, certainly.

At the same time I think a lot of people are stuck in cycles of abuse that they inherited, and which they themselves are going to pass down to the next generation. And I think to some extent this reflects the inhospitality of the societies we live in.

Anyways, I also wanted to say that I felt a lot of the same things you did reading this. Thank you for posting. I hope you will feel more peace as you get older.

My personal experience was using Datomic backed by DynamoDB, at the second Clojure company I worked at. In particular I remember feeling like it was hard to anticipate and understand its performance characteristics in particular, and how indices can be leveraged effectively. Maybe if we had chosen Postgres as a backing store that would have been better? I dunno.

Using it was pretty nice at the scale of a small startup with a motivated team, but scaling it up organizationally-speaking was a challenge due to Datalog's relative idiosyncrasy and poor tooling around the database itself. This was compounded by the parallel challenge of keeping a Clojure codebase from going spaghetti-shaped, which happens in that language when teams scale without a lot of "convention and discipline"--it may be easier to manage otherwise. All of that said, this was years ago so maybe things have changed.

At this point I'd choose either PostgreSQL or SQLite for any project I'm getting started with, as they are both rock-solid, full-featured projects with great tooling and widespread adoption. If things need to scale a basic PostgreSQL setup can usually handle a lot until you need to move to e.g. RDS or whatever, and I'm probably biased but I think SQL is not really that much worse than Datalog for common use-cases. Datalog is nice though, don't get me wrong.

EDIT: one point I forgot to make: the killer feature of being an immutable data store that lets you go back in time is in fact super cool, and it's probably exactly what some organizations need, but it is also costly, and I suspect the number of organizations who really need that functionality is pretty small. The place I was at certainly didn't, which is probably part of the reason for the friction I experienced.

I'm a Haskell fanatic, even wrote it professionally recently. I have also done a fair amount of small-scale audio programming, including trying to write a basic "soft" real-time-keeping app in Haskell, and it's not a great fit. I would probably choose Rust for anything that had to interface with hardware or tell time at this point, and that's largely because it would probably be easier for me than C/C++, which seems like the obvious choice based on ecosystem and prior art.

I think these kinds of comments made by FP advocates hurt FP advocacy more than they help, by implying that FP advocates can't see the forest for the trees. We are not in a world where the answer to ever programming problem is "throw FP at it!" We will never be in that world, no matter how awesome FP is, and I'm a huge fanboy.

Go take a look at the Ardour (http://ardour.org/credits) codebase and ask yourself in all seriousness how you could approach a project like that, what the tradeoffs would be, etc. and then ask yourself how serious any of your suggestions sound to someone like who you're responding to.

The video was not produced by the people making Grid Beam, but by Kirsten Dirksen, who covers all kinds of DIY/Sustainable/etc. unique and largely housing-related things https://www.youtube.com/@kirstendirksen

> I share the vision (if not the capital) of the people I'm working for, want to see that vision executed, and want to take an active part in executing it well. If that is not the case, it doesn't matter how much I'm being paid, I'm not going to be happy ("self-actualized") for long

This can and should be a condition on top of respecting yourself enough to expect that you are paid for the time you work and have the freedom to establish a good work-life balance based on those hours. Assuming for one second that the folks running the business--if they are any good at it--think about you in anything other than economic terms at the end of the day is simply foolish.

I may be trying to persuade, but I'm not being prescriptive. I'm just stating the logical outcome of behaving based on the thinking in the post I was responding to.

I understand the point being made, but this is fundamentally naive and counter-productive for everyone who wants to be working in this industry as a software engineer. Engineers are going to get exploited: just shrugging and saying "but we get paid well enough" means stuff like this: https://hirecloud.io/hr-and-recruiting-news/the-techtopus-ho... will continue to happen over, and over, and over.

So, unfortunately, your post encourages what the ones at the top with all the capital love: getting the rest of us fight over the scraps. Because the truth is that it's all scraps to them, and that's how they want to keep it.

> How do you feel about Kotlin where nulls are present but by default all types are not nullable?

I have to ask--how is that different from an option type?

> Optional or Maybe is just “type or null” which is the implicit type of every language with nullable by default types. It’s worse in every way to null.

This is completely backwards, and it's much more basic than ebingdom's explanation. Although, I don't think they're necessarily wrong, but I don't think you need functors specifically or category theory in general to explain this.

When your language allows the presence of null values, then by default you are asserting that null is a member of every type in your language. This means that any value can possibly be null.

When using Optional or Maybe or $My_Language's_Name_for_a_Some_Value_or_No_Value_Type, with a language having a half-decent typechecker, for any potential place where you may have a `Nothing` or what-have-you the typechecker will enforce that you are addressing that.

In a language that doesn't provide the ability to distinguish between null values and anything else via static analysis, you are forced at runtime to explicitly check every possible place that a null value could occur (I have used dynamically-typed languages for the better part of two decades professionally; nobody does this), or you can keep the entire logical structure of your application in your head perfectly such that you know where any nulls could occur and thereby skip writing as much code (no one can do this, and anyone who believes they can is either a junior or a junior) or acknowledge that you are a human and write a bunch of tests to try to mitigate potential failures (you will still have a microservice crash and spend a day or two putting out fires when that null slips through, because something something tests don't prove absence of bugs, thank you Dijkstra).

On the other hand, with a sufficiently sophisticated type system, you are able to write programs that let you flexibly target where optional values are present and where they are not with a minimum of boilerplate, and you never have to worry about this particular--but rather _significant_ when it comes to tolerating incessant firefighting--class of errors at runtime. This is better in every way to null.

> On the flip side, the guy is suing for millions and was going to work at a sandwich shop. Is he expecting more than a lifetime worth of value from society because he had an accident?

This is the problem with the completely stupid healthcare system in the U.S.: this kind of moralistic outrage only makes sense in the context of our ridiculously overpriced costs which are the way they are because of perverse incentives in our healthcare system. If we had single-payer health care we'd probably be spending less on healthcare overall (https://decisiondata.org/news/how-much-single-payer-uhc-woul...), and this would never have been a news story.

But, instead, we have these kinds of framings where someone did something stupid and has no way out of their situation besides desperately looking for some way to cover their costs without being completely screwed. How would any of us deal with this if we were in the same position? Coming back to "well he did it to himself" overlooks the reality of our system which is that so many folks with health issues have no options, regardless of how few mistakes they've made. And if we start demarcating who should and shouldn't get health care because of whatever stupid thing they have done, then I imagine we'd first say "well, all you smokers and drinkers, you don't get to have health care any more. Same for you overweight folks. Also you kids who got hurt because your parents weren't careful enough about protecting you when you were in a car/riding a bike/in a pool/etc.--sucks to be you." Etc. etc. This is first and foremost cruel, and more to the point, it is an absolutely ineffective way to determine public policy.

If we stop applying these regressive moralistic arguments to who should and shouldn't have healthcare, and instead frame things in terms of the kinds of public health outcomes we want and the type of policies that produce those outcomes, we get to profoundly better results (which can be seen by considering how other developed nations with non-dysfunctional healthcare systems function, if nothing else). But as far as I can tell, based on my lived experience over the course of almost five decades, Americans mostly don't seem to want to concede to their fellow citizens any of this kind of pragmatism and compassion until they themselves find themselves in similar situations. The majority of the responses in this thread--including yours--seem to bear that out.