vperez

Because there are much more unknown parameters in the outcome of AI for humanity than in your match against Stockfish.

For example, the timeline upon which AIs get effectively smarter than us is uncertain. Let's say you believe the probability this occurs before we solve the alignment problem is 80%, it doesn't seem too far fetched to think that in this case there is at least a 12.5% chance that AIs coordinate against us in a catastrophic way. Combining these probabilities you get a 10% chance of a catastrophic outcome for humanity.

Note that the numbers are not to be taken at face value, I just wanted to give an example of thought process which could give such a figure.

It's not too hard to imagine potential scenarios, some example have been given in previous responses.

But there is another kind of argument to be made: if you play chess against a player that is far smarter than you (chess wise), you know you are going to lose, even if you don't know how.

So the mere existence of a smarter species than us is a threat in itself.

Haskell is actually used by companies to solve practical problems, a non trivial example being Facebook: https://www.youtube.com/watch?v=mlTO510zO78

Not too bad for an abstract experimentation.

Great article. One nitpick:

> One of the biggest benefits of using a systems programming language is the ability to have control over low-level details.

I think this is a misguided conflation of "systems programming" and "low-level programming", those are separate things. See http://willcrichton.net/notes/systems-programming/

I second this, notably for programming related queries. I have been using DDG for a year or so now, and never looked back.

Here at https://legalstart.fr, we have been using Elm for a few months now, and this experience has been quite positive.

What we liked:

- the compiler: not only does it prevent a lot of bugs, it allows us to refactor large portions of the code base fearlessly. Also, the compiler messages are often very easy to understand.

- the documentation: the guide is excellent.

- The Elm architecture: the fact that this is the only framework that you can use makes things easier, notably for junior developers who are not lost into a sea of choices.

- The Slack community is very responsive, notably via its Slack record channel: https://elmlang.slack.com/. I also found it to be quite friendly.

What we struggled with:

- In our experience, the hardest part has been to deal with JSON Encoders / Decoders. But it got smoother when we got used to it.

- The fact that the 0.19 version was new had some negative effects, eg obsolete docs or unavailable tools. It has gotten much better by know.

If you're new to functional programming Elm will require some getting used too, but we quickly got 4 developers of various experience / backgrounds up to speed. I believe having one developer who already knew Elm and advocated / taught it the beginning helped speedup this process a lot.

About nested components: as stated before, they are much less necessary than one might think; but otherwise this post might be helpful: https://medium.com/@alex.lew/the-translator-pattern-a-model-...

Last but not least: if you are interested in working in Elm (or React), we are looking for creative frontend developers !: https://jobs.smartrecruiters.com/Legalstart/743999665887249-...