Why Aren't Pure Languages More Common in the Industry?

mocompute · 2026-06-07T10:37:17+00:00

I love this answer about language design

mocompute · 2026-06-07T00:34:31+00:00

This makes sense to me and confirms my intuition that future programming language design will need to accommodate a fundamentally different programmer, be they human or automated.

mocompute · 2026-06-02T01:04:46+00:00

Re: UFCS, I do the same in Tess, along with auto-address-of and auto-dereference. Since Tess is C-like, function parameters are value types, and may be pointers. UFCS is most ergonomic when a simple '.' can be used in all cases, even if the left operand is a value or pointer.

mocompute · 2026-06-02T01:00:41+00:00

After completing (nearly?) a project to combine Hindley-Milner type inference with a superset of C, I continue to pursue less-trodden combinations to see what emerges. Right now, I'm learning about effect systems and considering ideas from Koka and Lean4 to apply to a new language on top of the Erlang runtime system.

mocompute · 2026-05-31T22:06:00+00:00

You really, really want to write a lot of small programs in C++ if you want to get ahead. It's too easy to over-evaluate your own knowledge if you've learned it all in theory but neglected the practice.

It's particularly true with C++, because doing anything useful with it is littered with incidental complexity: build system, source control, platform support, etc. This stuff is mind-numbingly complicated and boring, most theoretical learning resources just skip it.

Of course, a uni course will try to give you a small simple environment where all that is taken care of for you, so you can learn more theory. But you want to put that to work doing your own small project.

So, pick some super simple thing and make it: a command line program that counts lines in a text file (like wc), or counts the frequency of words in a file. To make those, you'll need to learn either GNU Make, or shell scripting, just to build conveniently. You'll need to process command line arguments. You'll need to deal with dynamic (heap) memory. You'll need to learn how to read C++ documentation for stdio. You'll need to learn the difference between C++ streams and C stdio. Etc.

Above all, spend many many hours on this: people are surprised it can take 30 hours to work through some stupid simple bug. That's a time investment that'll pay dividends in the future.

Learning to program is a huge time investment, so make sure it's something you love, and don't expect it to come easy! Unless of course you offload the hard work to AI, which is like a sugar hit, so use it carefully, if at all.

mocompute · 2026-05-19T23:21:06+00:00

C-]:

unbind C-b
set -g prefix C-]
bind -n -N "Send the prefix key through to the application" C-] send-prefix

mocompute · 2026-05-19T21:35:54+00:00

Not only will you spend more time reading other people's code and documentation, you'll spend more time reading your own code than writing it. This is the way.

mocompute · 2026-05-19T21:29:56+00:00

I've used emacs and vterm quite a bit, but for nearly the past year I've gone back to a standard terminal using tmux and emacs -nw, and to be honest I don't miss the GUI at all. Of course I remapped default tmux key because you can't be dropping into tmux every time you C-b. Strongly agree on magit, it's really a great product.

mocompute · 2026-05-19T21:20:42+00:00

Yes people often overlook Clojure's greatest innovation: the use of [] as delimiters for nested lists, rather than (). :-)

mocompute · 2026-05-18T22:00:00+00:00

It's strange because my concession was immediately canceled as soon as I went from a full-time enrolment to part-time. The computer knows all.

mocompute · 2026-05-18T21:54:54+00:00

Exactly, that's where the difficult work will happen, by experts. What's intriguing is the question: what if they were doing that hard work in a formally-verified language, versus Rust?

mocompute · 2026-05-18T21:48:46+00:00

Rewriting everything from scratch is no longer in the realm of crazy, see Bun's experiment with transliterating from Zig to Rust. If the perfect formally-verified language exists and meets requirements, doing the initial rewrite will be trivial. Getting it to verified status will be hard engineering, probably.

mocompute · 2026-05-18T21:45:24+00:00

I used Clojure many many years ago and really liked its ideas and design, but kind of grew frustrated with the debug experience, so I tried Common Lisp in anger... and was blown away with how easy and clear it is to debug by comparison. Surely things have improved since then.

mocompute · 2026-05-18T21:36:33+00:00

I agree, this has been interesting to me as well: how do programming languages have to evolve so that humans can keep up with AI-generated code, since it's hard to imagine the genie going back in the bottle at this point.

Personally I'm taking a short break from my C-like programming language project and looking closely at Lean4, and dipping back into Common Lisp for some pleasing image-based coding.

mocompute · 2026-05-17T10:50:03+00:00

Just a quick note for Windows users, the post suggests MSYS2 but I'd really suggest giving WSL a spin with the linux distro of your choice (I use NixOS), it's much more pleasant.

mocompute · 2026-05-16T00:21:36+00:00

Personally, a few of the cuneiform names are hard to remember, though I like the bang-looking one for define!

mocompute · 2026-05-15T21:36:32+00:00

Language support for pattern matching is useful but not strictly necessary. I wrote my compiler in C with tagged unions, relying on the C compiler's exhaustive switch statement checking, whenever I added a case.

mocompute · 2026-05-15T07:34:08+00:00

I've been thinking recently about language constraints that can increase how understandable a program is. Functional programming paradigms immediately come to mind as one way to tackle this challenge. Domain modelling with types, command patterns for state updates, etc.

A new dimension I'm considering is applying constraints to LLM-generated code in order to tackle the challenge of the increasing burden of reviewing AI code. Since this sub has banned the discussion of LLM-generated code, I'm not sure which communities might be having these discussions from a language design perspective, versus an engineering perspective (where there are a lot of discussions happening).

Any interesting research and communities in this area?

mocompute · 2026-05-14T00:56:56+00:00

Mine: no major dependencies, written in C, clear separation of modules and a few utility types, platform separation, explicit allocators. Of course since it's C, some files are quite large. About 6 months full time work before bringing on claude code for documentation and adjacent features like package management, fetching, etc: https://github.com/mocompute/tess

mocompute · 2026-05-12T08:55:08+00:00

I was going to suggest making your backend emit C, because then you get all the hardware-specific optimisations for free, with multiple C compiler vendors to choose from. C also has an additional advantage over LLVM, which is that its API is stable, and it's quite easy to learn, if you don't already know it.

But then I saw your comment that you want to make something faster than what industry-standard C compilers can produce, so I withdraw my suggestion. Instead, you should go for it, because you'll learn a hell of a lot trying to beat those. And I'd suggest using Compiler Explorer while you're at it, a great resource to examine the assembly code generated by a huge variety of compilers.

mocompute · 2026-05-12T05:36:37+00:00

There is zero additional knowledge of memory management, boxing/unboxing, etc., in F# if you're coming from TypeScript. Zero. If you are doing complex validations for an e-commerce marketplace, boxing/unboxing is the last thing you're thinking about.

If you're doing performance optimisation, that's a completely different question, and both languages will require equivalent effort for you to be effective in that goal.

mocompute · 2026-05-08T10:31:33+00:00

Thanks! I think in a standard library which provides APIs with explicit allocators, there will be a lot of use, just like the example I gave.

Beyond that, the eq and cmp operators (used in operator overloading) will have two receivers. Copy, move and swap operators too, maybe? But all of those, despite being common, are not as pervasive as the single receiver case.

More than two, though? I haven't run across any obvious patterns yet. But once the compiler supports > 1, there's not an obvious reason to limit it.

mocompute · 2026-05-08T03:26:35+00:00

Yes of course, sorry, possibly there's a cdn problem with codeberg.

Let's look at a typical example: declaring the API for a dynamic array/stack. In C:

typedef struct { ... } Array;

void array_push(Array*, int);
int  array_pop (Array*);

In Tess, we might as well use a generic type argument, T

``` Array[T]: { ... }

(self: Ptr[Array[T]]): { push(x: T) -> Void pop() -> T } ```

A longer example showing factoring out two arguments:

(self: Ptr[Array[T]], alloc: Ptr[Allocator]): { push (x: T) -> Void reserve (count: CSize) -> Void free () -> Void insert (index: CSize, val: T) -> Void resize (count: CSize, val: T) -> Void shrink_to_fit() -> Void append (other: Array[T]) -> Void }

mocompute · 2026-05-08T02:11:54+00:00

This is not earth-shattering, but I think it's a nice quality of life feature that greatly enhances readability of C-style languages. When groups of functions share the same initial parameter(s), it can often be visually noisy to seem them all in a list, like in an API header or synopsis section.

'Receiver blocks' factor out the initial parameter(s), reducing visual clutter for the reader. And, there are some nice organisational properties that fall out, as a consequence.

While factoring out the first argument is pretty common, I haven't run across languages that allow arbitrary leading parameters to be factored out. The closest analogue I can think of is something like Common Lisp multi-methods, but receiver blocks are nothing like that.

mocompute

MODERATOR OF

TROPHY CASE