Looks like 100% idiomatic normal OCaml to me.

> For many years now KDE has focused on polish, bug fixing and "nice-to-have" improvements rather than major redesigns, and it paid off.

It has. I believe this is a consequence of the 4.x debacle 18 years ago. KDE was doing great in the 3.x release, capturing a lot of users, and then everything went sideways with 4.x.

They recovered: by the later releases of 4.x most of the problems were fixed and 4.x was entirely livable. The KDE developers learned a hard lesson and have been very conservative since then. Since the release of Plasma (5.x) in 2014, KDE hasn't self-inflicted any great regressions or misfeatures, and now there is 10+ years of "polish."

It is very nice.

I too have used the "Window Rules" mentioned in the blog post. Very useful for game development where you want certain windows to appear at precise locations on different displays every time, day after day, for years. KDE just gives you features like this, whereas this is considered unnecessary elsewhere.

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. Unfortunately it fell into the gap between what academia could justify working on and what industry was willing to do.

[1]: Practically speaking, the 31-bit Ints are annoying if you're trying to do any bit bashing, but aesthetically the double semicolons are an abomination and irk me far more.

Lisp programmer here.

Traditional S-expressions, by their definition, ignore most of whitespace; additionally, reading sexprs is always a linear operation without the need to backtrack by more than one character.

The suggestion from this post violates both assumptions by introducing a 2D structure to code. To quote this post's examples, it requires the multiline string in

    (fst-atom """   trd-atom)
              00001
              00002
              00003
                """

to be fully read before TRD-ATOM. It also forces the reading function to jump up and down vertically in order to read the structure in

    * (                               )  
    *   e (           ) (           )    
    *   q   m (     )     p (     )     *
            u   a a       o   a 2       *
            l             w             *

The author also states that

    (eq (mul (a a)) (pow (a 2)))

is less readable than

    * (                                                  )  
    *   *eq* (                   ) (                   )    
    *          *mul* (         )     *pow* (         )     *
                       *a* *a*               *a* *2*       *
                                                           *

Then there's the ending passage:

> we hope that the introduced complexity is justified by the data readability expressed this way.

I cannot force myself to read this post as anything but a very poor Befungesque joke.

I've been following Dark since its inception and found the idea inspiring. I'm happy about today's announcements and look forward to seeing what comes next.

On a personal note, I'm curious around the move to F# as the implementing language and wonder if there will be ports to other languages now that it's open source.

It still needs middle out compression imo

I think there's a sharp rule of diminishing returns the stronger you make type systems. Type safety comes at a cost and that cost has to come with an associated payoff.

This is why ultra strong type systems end up being little more than academic toys - the payoff when you dial type safety up to an extreme doesn't match the associated cost.

Types and tests should meet somewhere in the middle because the same law of diminishing returns affects tests in reverse. They tend to be good at what the other is bad at and if you rely too heavily on one at the expense of the other they will start fraying around the edges.

If only they had unveiled the single unifying abstraction of everything :(