tome

Experience has demonstrated that it's not sufficient!

> Flipping one card doesn’t change the state of the other one

Right, but you didn't say "change" you said "determine".

> Aspect carried out the experiment in the early 80s

I have a write up of the maths behind this if anyone is interested, accessible to an undergraduate: https://h2.jaguarpaw.co.uk/posts/bells-theorem-made-simpler/

Haskell most definitely supports loops:

    ghci> :{
    ghci| for_ [1 .. 10] $ \i ->
    ghci|   print i
    ghci| :}
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10

It doesn't require loops to be implemented at the language level, however. The language is rich enough to support user-defined loop constructs.

> Just imagine the billions of value you could've generated with a more programmer-friendly language!

To make a serious rejoinder to a light-hearted comment, I couldn't have, because without Haskell I would have been so annoyed with programming I would have gone into management or something, so that I didn't have to use a "more programmer-friendly" language and want to tear my eyeballs out 8 to 10 hours a day. Seriously. Haskell is the only language I've used which I don't feel gets in my way.

> Haskell is a great research language - just don't try to use it for actual production programming. ;-)

Oops, your advice came ten years and millions of dollars of value generated too late for me :(

There is some work on that: https://www.youtube.com/watch?v=qk_P8piUclI

The first article doesn't say that Israel was the culprit and the second article isn't about this particular case (nor does it actually say that Israel was involved, just Israelis, formerly intelligence service staff).

Maybe a silly question, but without video isn't this obviously fake? Or is it normal for all participants on a call to be audio only?

I think you've got it exactly backwards. The comment is supposed to explain that there can't be a scientific determination of such a matter, not that it itself is such a determination.

This comment by nh2 (on Reddit) is my favourite response to that line of thinking. I recommend reading the whole thing. Excepts:

> You're not going to get any "credible empirical evidence" already because the sample size is so small. That would require getting, say, 100 companies that are similar in size and tasks, have a working business model and are still around, and also want to spend time on methotically collecting concrete evidence, and care to blog about that.

> people don't really want to spend time stating the obvious

> We don't spend time blogging that on our Haskell server, we get pretty much none of [run time type error or segfault] because well, those don't exist in Haskell

> We're convinced it's the best tool for the server job, compared to other tech we used at past jobs and projects. So we're using Haskell for it, and we started it in Haskell. We cannot compare before/after, because we directly started it in the "best tool available". We can compare our current project to our past individual work experience, but one cannot simply turn such individual cross-project experience into quantitative evidence

https://www.reddit.com/r/haskell/comments/1plsmqh/comment/nt...

If that's so could you link the other articles?

The culprit where?

That article doesn't say it was Israel.

Are you sure it says that? As far as I can see it only says he dealt with Israeli ex-spies in an (unrelated) kidnapping and that he was friendly with Israeli spies.

I don't quite follow. `fmap = map` is a valid implementation for lists indeed, but `for_ = foldr` is not. They don't have compatible types, for one thing. What do you mean?

Or just use `for_` instead of explicit recursion ...

Yes, because foldr is equivalent to for_, that is, iterating over a container and performing an effectful action (what in other languages would be called "doing something") for each element. Uses of foldr can always be rewritten to uses of for_, and I find things much clearer in terms of for_!

(This is explained in my article "foldl traverses with State, foldr traverses with anything": https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr...)

Oh you're right, I misread. But in that case isn't it even less crazy? Different levels of risk pay different amounts, up to 33% more in the cases documented above?

> but this is what's crazy to consider: the difference in wages we are talking is no more than $3 per hour

What's crazy about it? Do you mean it's crazy that people chose to work a dangerous job when a safe job was available for not much less?

> Everyone assumed they were going to do a Venezuela

When you say "everyone" do you mean "everyone in the US military establishment"? I remember very few independent commentators who suggested the US intervention in Iran was a good idea. (Personally I think it's too early to say.)

Excitement is not a reward, excitement is a motivating force :)

> Apparently in the 90's the Haskell devs couldn't fathom two different types both having a field called "ID" or "name".

I think it's simply that making field names become functions that select from the record was a simple design that worked, and didn't require anything new to be added to the language.

> I haven't tried any serious LLM Haskell before 2026-02, because it was just not a timesaver.

Same, and now seven months later a GBP 20 per month Plus subscription gets me basically all the GPT-6-Luna-xhigh I can eat, which does a tremendous job of Haskell. It's even helped me with some really gnarly things like this, which require deep knowledge of the GHC RTS: https://github.com/tomjaguarpaw/bluefin/commit/c298733bdd67d...

It's possible it's much slower when working on Haskell than it is on other languages. I wouldn't know because I've only tried it on Haskell. But I'm very happy (and extremely impressed) by it.

Why would you want to be pissed off when you could be excited?

What do you mean? Because management says it makes you too slow? Or is it unacceptable for some other reason?

> > But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code. > > This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.

You can try it now yourself in Haskell! This is my effect system, based on capabilities: https://hackage.haskell.org/package/bluefin

One of the common objections I hear to Bluefin is "isn't it too inconvenient to pass around capabilities everywhere?". Perhaps surprisingly, no, I haven't found it remotely inconvenient. I find it liberating, actually.

What's the difference?

In Bluefin, IOE (which allows you to do I/O, i.e. what Haskell's IO also allows you to do) is an argument, and therefore not a color under your interpretation.

https://hackage.haskell.org/package/bluefin-0.0.7.0/docs/Blu...

Cool, my contact details are on the front page of that site.

Interesting, I have not heard of Spritely Goblins! But neither Bluefin nor effectful could be described as distributed capability systems/effect systems, so I don't think they're comparable.

On infection, I think it's a bit like being infected by mitochondria :)