this is the log post that put lean on my radar, though I haven't played with it yet: https://kirancodes.me/posts/log-ocaml-to-lean.html

malka older's "infomocracy" is another interesting science fiction look at universal access to information

"a programming language".

Not to be confused with b programming language, which is not its succesor, but is the predecessor to c.

the fact that you can't name the UK equivalent offhand should tell you how obscure these regional agency names and acronyms are in general.

they're inspired by repeating elm's good features and fixing the bad ones!

I've found claude startlingly good at debugging race conditions and other multithreading issues though.

My rule of thumb is that its good for anything "broad", and weaker for anything "deep". Broad tasks are tasks which require working knowledge of lots of random stuff. Its bad at deep work - like implementing a complex, novel algorithm.

LLMs aren't able to achieve 100% correctness of every line of code. But luckily, 100% correctness is not required for debugging. So its better at that sort of thing. Its also (comparatively) good at reading lots and lots of code. Better than I am - I get bogged down in details and I exhaust quickly.

An example of broad work is something like: "Compile this C# code to webassembly, then run it from this go program. Write a set of benchmarks of the result, and compare it to the C# code running natively, and this python implementation. Make a chart of the data add it to this latex code." Each of the steps is simple if you have expertise in the languages and tools. But a lot of work otherwise. But for me to do that, I'd need to figure out C# webassembly compilation and go wasm libraries. I'd need to find a good charting library. And so on.

I think its decent at debugging because debugging requires reading a lot of code. And there's lots of weird tools and approaches you can use to debug something. And its not mission critical that every approach works. Debugging plays to the strengths of LLMs.

recalcitrant companies with a presence within the court's jurisdiction, which in the OP's case doesn't sound likely.

ocaml has a complex type system but it's also very pragmatic in that it doesn't force you into any one paradigm, you can do whatever works best in a given situation. (scala arguably goes further in the "do whatever you want" direction but it also dials the complexity way up)

Ocaml's typesystem is rich, but not as complex as TypeScripts. It seems TS just adds more obscure features every year for little benefit.

Yes! Completely forgot about OCaml because I only spent a couple of months with it

at first glance this looks amazing! basically provides everything I have ever wanted in a full stack language. looking forward to experimenting with it.

edit: looking through the docs/examples some more, it looks like javascript interop is fairly clunky, both because it relies on string concatenation to embed fragments of javascript, and because the string concatenation syntax is not great (and the formatter makes it even worse - see the example at https://github.com/anzellai/sky/blob/main/examples/13-skysho...)

I would encourage you to at the least add multiline strings with interpolation support, and ideally add a small compiler for html literals.

Thanks for taking your time to look at the repo! yes I have built so many applications and worked at startups/scaleups where different languages / type systems are used for frontend/backend, and very often we need to bring in schema generation like OpenAPI, protobuf/connectrpc etc. to code generate types/apis that can be shared between teams. But that's ugly and hard to maintain & scale.

I love Elm's ergonomics & Go's simplicity, and Sky is really my serious take to bring 1 language for full stack application (well, at least to cater for most common application types).

back to your feedback, indeed, the multi-line string is one of the things that bug me as well. They only surface when I start building incremental examples -- skyshop is a realworld like example which expose a bunch of issues & compiler limitations.

That said, my goal is for devs not needing to write/embed JS in Sky code, but perhaps serve as static, and have Sky semantic to "load/init" the JS.

Nonetheless the ugly multi-line string issue is now addressed with https://github.com/anzellai/sky/pull/13.

HTML I took similar of Elm to have elements as function, and have an escape hatch using node for custom elements. I use VNode rather than string for HTML rendering, as that's much more efficient in diffing and for Sky.Live SSE push for updates.

Anyhow, please feel free to check on Sky repo regularly and hopefully I will make enough progress sooner that Sky is useable in realworld side projects.

awesome! will definitely check back regularly.

often the blocked features are specifically blocked on the mobile web (i.e. on your desktop they won't make you get your phone out to use the app instead), so forcing the webpage to desktop mode helps.