... and and and and ...New catlang post to lobsters but the server for the blog is chugging 
Another sloppist :(
Devine Lu Linvega@andnull it's true, nobody actually writes in catlangs
@neauoire Langdev space in general is full of people posting slop projects. There is however steady work still being done. @yumaikas is slowly refining the Zig implementation of StackTalk. Periodically, seeing update post from tz they build out a whole IF style IDE for their languag.
But so many people just want to churn out a flashy looking project for the clout of publishing something.
@neauoire Slap was a huge let down cause it had so many neat things going and I would have loved to share it with the catlang discord but 
https://lobste.rs/s/3fprl8/slap_functional_concatenative_language#c_kgvanm
@andnull ah yes, well he's quite a famous slopper, that doesn't surprise me.
@andnull it's bizarre to make llms spit out programing languages knowing that you won't be using said programming language anyways, seems utterly stupid to clutter the PL space with that useless stuff, my guy, stick to javascript
@neauoire fr, granted a lot of PL dev seemed to be driven my extrinisic motivitation rather than intrinisic motivations. It was a vibe I picked up when I noticed all PL designed started to homoginize around Rust/Go/Zig clones.
Slava Pestov@andnull @neauoire There is a legitimate need for safe(r) systems languages that give you precise control over memory, because there are still plenty of problem domains where something more dynamic can’t really work. But definitely I agree that the search for the “C++ successor” has sucked the oxygen out of the room in the language design space, feels like a fad at this point
AlgoCompSynth by znmeb 🇺🇦
disregard Joe Groff@slava @andnull @neauoire the way all of these successor languages blow complexity on metaprogramming features trying to get back to dynamic language expressivity, i wonder if the "systems language" should just be an EDSL you piece bits of together inside of a real programming language. what if C but the preprocessor is your smalltalk environment
Jordan@andnull @neauoire @jrose @joe @slava
TBH I would use an interactive all-Arm-architectures macro-assembler - everything from the RP2040 (M0+) up to aarch64 with Neon. That was what got me into Forth on the 80186 - the fact that I could use it as an interactive assembler. I suppose I'd have to add Hazard 3 for the RP235x. ;-)
@neauoire @jrose @slava @andnull indeed. ObjC and C++ keep the higher language plane subordinate to the C runtime model, though, so you have to think directly about manual memory management, callstacks, calling conventions, etc. i was thinking of something more flipped around, where the "C" bits are pieces in a limited-abstraction environment that you can build up, compose, evaluate, or compile-and-jettison from the higher-level plane
Ben Lings
graydon@joe @neauoire @jrose @slava @andnull There's a gradual coalescing of ideas for useful imperative EDSLs in Lean (Strata, Loom, the built-in monadic VC generator tactic in Lean) -- and at least a sort of pitch being made for a consolidation of efforts by https://arxiv.org/abs/2602.04846 ? Of course it is all happening in a modern context of "what if an LLM drove, and humans mainly focused on the logic tools surrounding them"; but I don't think that's necessarily a bad thing; these ecosystems are already strongly organized around proof irrelevance and automated term-search. I know I'm in a minority but it feels like a glimmer of a promising potential future, if capital remains intent on LLM-ifying the world (especially if there is some modularity to the abstraction layers built on top; there's lots of real and interesting PL-and-logic engineering to do there)
CSLib: The Lean Computer Science Library
We introduce CSLib, an open-source framework for proving computer-science-related theorems and writing formally verified code in the Lean proof assistant. CSLib aims to be for computer science what Lean's Mathlib is for mathematics. Mathlib has been tremendously impactful: it is a key reason for Lean's popularity within the mathematics research community, and it has also played a critical role in the training of AI systems for mathematical reasoning. However, the base of computer science knowledge in Lean is currently quite limited. CSLib will vastly enhance this knowledge base and provide infrastructure for using this knowledge in real-world verification projects. By doing so, CSLib will (1) enable the broad use of Lean in computer science education and research, and (2) facilitate the manual and AI-aided engineering of large-scale formally verified systems.
algernon.st@joe @andnull @neauoire The idealist in me still believes in the VRPI vision of multiple small languages built from a common substrate that work well together. I still want the lower level language to have ownership and memory safety, but yeah, maybe instead of trying to make it palatable for application development by layering ever fancier metaprogramming abstractions on top, there should just be a separate language
@joe @andnull @neauoire I’m imagining a modern “frontend construction toolkit” that gives you a parser generator for incremental parsing, semantic analysis based on recomputing and caching small bits of information from the immutable AST, and some kind of term rewriting/algebra engine for specifying your type system
zwarich@slava @joe @andnull @neauoire You're rediscovering attribute grammars from first principles.
Joking aside, I've been thinking about this a bunch lately. Here are my thoughts on the parsing side of things (hopefully I'll add more later about semantic analysis):
1) Code generation tools always seem to have awkward support for quoting/integration code in the host language. A proper solution to this probably requires a host language with complicated metaprogramming features (which are not my strong suit), so I'd probably just try to reduce the need for this.
2) Unless your whole compiler is going to be generated end-to-end, at some point you need to produce tree data structures that will be used by handwritten code. Do you have a lot of flexibility here or just force a convention on people?
4) Traditional lex-style maximal munch semantics are not implementable by a finite-state transducer. Conversely, several lexer tricks (e.g. Go's semicolon rule) are implementable by finite-state transducers, but are not expressible in lex.
5) Traditional parser generators focus on LR/LL techniques, but neither of these is good. On the LR side:
a) Humans prefer EBNF to BNF, but LR w/ EBNF is very subtle (with lots of mistakes in the literature)
b) Generated parsers are not type-safe in ordinary languages
c) In practice, there is a tradeoff between handling lookahead > 1 or supporting full LR (as opposed to SLR/LALR)
On the LL side:
a) Expressiveness and performance issues with operator grammars
b) Unable to resolve "dangling else" conflicts. I think this one might finally be irrelevant, since new languages seem to be abandoning the "dangling else" entirely.
I think the best approach would be to abandon LL/LR for one of the hybrid LL-covering grammar classes like LC(k) (left-corner) or PLR(k) (predictive LR, i.e. LC w/ automatic left factoring).
6) It is known how to do all of the above with "push" incrementality where you are given a past input/out and an input diff, whereas writing an implementation of this style of incrementality by hand would be miserable.
7) Making the above also work with indentation-sensitive syntax is probably possible, but a bit of work.
@zwarich @slava @andnull @neauoire guix has me feeling the s-expression religion again, the way it cleverly embeds build scripts as quoted sexps that get composed in the configuration execution environment and then executed in the package build sandbox where they can’t have any accidental undeclared dependencies. seems like you could do something similar with a “systems” subset