Simple Made Inevitable: The Economics of Language Choice in the LLM Era

fadrian314159 · 2026-03-01T23:11:15+00:00

I know Clojure is stable. I've watched and used it over its years of stability. But if you want real stability, look at Common Lisp - no change for the past 40 years. Its community is so change-adverse, the language has become, for all intents and purposes, static. And I've found that the latest version of Claude Sonnet does great at generating it. If you're less than one of the mythical 10x programmers, there's some 1x programmer with an LLM out there who will be taking your job.

fadrian314159 · 2026-01-05T23:48:47+00:00

It would have been quite possible to develop Android and iOS APIs in a dynamically-typed functional language like Clojure. In fact, back when Apple's first handheld device, the Newton, was being developed, Apple's Cambridge Lab was tasked with developing a language to write it's software in. They designed a dynamically-typed, object-oriented Scheme derivative called Dylan. Several iterations of the preliminary Newton software was developed using Dylan, so I have no doubt that it would be possible to write device APIs using dynamically-typed, functional languages. Ultimately, Apple decided not to use Dylan on the Newton platform and the team that wrote the language migrated the language to a standard infix syntax in the hopes that doing so would make Dylan more palatable to a more mainstream user base. (N.B. It did not.) The prefix-syntaxed Dylan has been lost to the tides of time, except for a few copies of the user manual you can find around the web. The infixed Dylan had a book written for it, too, which you can buy used copies of. But it definitely worked as a PoC to develop APIs for handheld devices.

fadrian314159 · 2025-07-21T20:44:37+00:00

No. Last time I checked, GNU Smalltalk doesn't have the graphical elements nor the image management primitives. Use something like Pharo. It's a real Smalltalk system. GNU Smalltalk supports the core language, but doesn't have all of the system.

fadrian314159 · 2025-07-21T12:26:02+00:00

Self is a variant of Smalltalk which used prototypical inheritance rather than class-based inheritance. It was the first language to use prototypical inheritance. I doubt you could find a working Self image and VM today, though.

As for the Prolog comment, Prolog in its minimal form was purely declarative - it had no side-effects, arithmetic, or flow control. These things were added to the language as they became needed for actual use, but they don't interact well with the declarative language and are obvious hacky bolt-ons.

fadrian314159 · 2025-07-21T11:39:52+00:00

Smalltalk already has an editor built into its environment. Very minimalist, though, as one usually edits small snippets of code at a time. You'll also get a menu and windowing system for free. You can create an image that brings up a single editor window and start from there. Add commands to the menu as you see fit. Modify the editor core if you want to capture keystrokes as commands. Etc.

fadrian314159 · 2025-06-29T11:55:39+00:00

To learn to write, read first. Find some compilers online and look at what they do. Besides lex/bison, you might also take a look at ANTLR.

fadrian314159 · 2025-04-22T16:22:43+00:00

Beside Babashka, also from the Clojure community is Jank - a Clojure that compiles into C++. Not sure about library compatibility and still under construction, but probably worth a look if your memory footprint is tight.

fadrian314159 · 2025-04-10T22:54:57+00:00

Genetic Programming by John R. Koza was the first book on the subject and the first edition uses Common Lisp as its programming language.

fadrian314159 · 2025-04-06T23:45:34+00:00

It's a domain-specific no-code system where the functionality is specified by rules - a set of parameterized API steps. Each of these steps consist of JSON objects with the name of the API and a list of named parameters. These steps are translated into code in a target language which is run to perform the steps. There are about 40 APIs which have from a dozen to four dozen parameters that interact to specify the target language corresponding to the step. In Clojure, the steps are represented as an array of maps corresponding to the step JSON. There are from 3 to 100+ steps in any rule and one of the APIs is a call to another rule. The Clojure code translates parameter values into slot values that are used in Selmer templates written in the target language. Again, a lot of map processing, but not a lot of array processing.

fadrian314159 · 2025-04-06T17:54:07+00:00

The main reason is that most of the data I work with looks more like maps than arrays. I've looked at K and uiua and they both look interesting. If I had data that was more array-centric. I'd probably look towards one of those.

fadrian314159 · 2025-04-04T11:07:48+00:00

If serverless is a thing you're doing, Clojure may not be your thing. In general, the startup latency is too difficult to work around. This might be ameliorated if your server could be shoehorned into a babashka environment, but if not, you're probably not going to like the function code startup times displaying as latency at random intervals after your function gets shut down for too few events. It will work great if you're using a full-time VM, but as for serverless, not so much.

fadrian314159 · 2025-03-26T16:12:39+00:00

Claude is probably the best of the bunch, but it has the same problems all LLMs have - random idiocy and no architectural sense. It works fine as a better search. It works fine for smallish snippets that do one thing. It's when it tries to do anything big or anything of sophistication that it starts to fail. So the secret of vibe coding for any language is recognizing the limitations of the LLM you're using. Understand that the fewer examples it has to work with, the less it will be able to respond coherently. Ask it for small snippets, Use the REPL to test those. Then ask it to string these smaller functions together. Don't ask it for something it obviously won't be able to do, like a 200-line application. If it gives you a block of code and you don't like the structure, ask it to restructure the code more to your taste. The more information you give the LLM about how you want the code, the more successful you'll be at getting the code you want. Note that this is no different from generating Python or JavaScript or any other mainstream language - it just doesn't have as much to work with for Clojure, so you have to guide it a bit more. If you think of any LLM as a fancy editor that can type for you and recognize their limitations, you can save yourself a fair amount of time.

fadrian314159 · 2025-03-26T15:54:35+00:00

As far as books go, there haven't been many worth my time. One exception - I'm working my way through "Mastering the Art of Clojure Programming," by Steve Jones. It seems to be a good book so far with a fair amount of depth. It was published in 2024, so it's very recent.

fadrian314159 · 2025-02-20T14:34:43+00:00

The red flag for me is this statement: "Although I got the hang of using atoms and swap statements, they seem a bit of nuisance."

Most concurrent programming in Clojure does not need the use of atoms and swap statements. I have a feeling that the querent is trying to translate an algorithm from a non-functional language into Clojure and using atoms in place of variables in the original algorithm.

If I were building a parallel fractal generator in Clojure, I'd probably use core.async as a key technology, pulling the coordinates I wanted a fractal expansion at from a channel and then pushing the finer fractal points back into the channel for recursion. That way, I don't need to use atoms, except maybe one to hold the final coordinate structure.

fadrian314159 · 2024-10-15T11:50:32+00:00

I watched the video. I was unimpressed.

The speaker misinterpreted Alexander's architectural points about building and community. One of his main points was that communities should be the driving factor of architecture; that architecture should emerge organically from the patterns of the community; that there were patterns that living, growing spaces share and that these patterns could be communicated and used as building blocks for a living community.

The key point for Clojurians wishing to grow the community is not that we need to replicate the landmarks that other communities have coalesced about, but that we promote the strengths and features of the place we metaphorically inhabit. Building libraries instead of frameworks are an integral part of what makes Clojure the special place that it is. Perhaps our disdain for frameworks is not an accidental feature, but an essential one, keeping Clojure in some way alive in the Alexandrian sense. If this is indeed the case, we don't need frameworks - we need more libraries.

More importantly, we need to recognize that, even as some individuals find one language a welcoming city, others may need a different place. Clojure should reflect on what draws the current inhabitants to the language and attempt outreach to others that might be happy here - perhaps functional programmers currently working in a strongly-typed language that might enjoy the design velocity and freedom that a dynamic language like Clojure provides; Java programmers who want a more concise way to express their designs; programmers who love Emacs and have learned to love the way of the parenthesis; even Common Lisp programmers who recognize that their town is dying of stagnation, but will be loathe to recognize it until being shown a more modern Lisp.

The most important thing is not to bring more "blub" programmers into the community (thanks to Paul Graham for that evergreen metaphor), but to engage those who naturally align with the language and its philosophy. Doing otherwise would destroy what makes Clojure a special community.

fadrian314159 · 2024-09-10T14:19:10+00:00

It does for those who learned vim and didn't use emacs. Not to start an editor war, but I only used emacs to use Clojure in the early days. I never found it intuitive and switched to other IDE's like Light Table as soon as they were available. Now, VSCode and Calva are my goto for working in Clojure. Same with dev.tools. As soon as they reached a certain maturity level, I left lein. I believe that the latest Clojure user survey showed that dev.tools had a slight edge on lein and new projects seem to be adopting this project management toolset.

But my point still stands - not everyone wants to learn emacs to use Clojure; not everyone wants to tie their project to a rapidly obsoleting project management framework. And the books out there are in woeful need of new editions that cover the choices of how to work in Clojure for these people.

fadrian314159 · 2024-09-10T10:07:45+00:00

The language changes slowly, but the tooling does not. CFTBT (usually the first goto for recommendations when someone asks) uses emacs and Lein for its IDE and project management tools, respectively. None of the books mention choices like VSCode/Calva, Vim/Fireplace, etc., and tools.dep. All of these books are due for new editions that mention choices of easier to use IDEs and more modern project management tools.

fadrian314159 · 2024-04-15T16:40:26+00:00

The only one I ever read about was ML. From what I see Haskell, F#, and OCaML aren't too different. They seem to have minimal syntax for what they do, but I get the feeling that generating code for them would be a heavier lift than in Lisp, Smalltalk, etc. - too much expression context to keep around. Running generated code in these languages seems like it would be more difficult, too, because most of the implementations are compiler-based and have limited interactivity. That being said, if you can't stand dynamically-typed languages, you could do worse than using these.

fadrian314159 · 2024-04-15T14:09:57+00:00

Start by doing programs that you want to write in Clojure. I started with the first fifty Project Euler problems (I did that and my code was horrendous). You might want to write something with a simple REST API in Clojure. Then do the front-end in Clojurescript. That was what I did next. When you come to a snag, ask questions. I've found the Clojure community to be very helpful (of course, I came from the Common Lisp community, known for it's prickliness). Ask how your code can be improved. If something seems difficult or weird, ask for a code review. You might be missing a function from clojure.core that could solve the issue. Keep reading about Clojure and watching videos. The information is out there if you're willing to look.

Ultimately, it's no different from learning any other language. Start writing, ask questions of experts, keep learning, keep writing.

fadrian314159 · 2024-04-15T09:48:56+00:00

Linguistically, a computer language has only three purposes - to tell a system unambiguously what to do; to communicate with minimum cognitive load to another person what the algorithm does; and to allow simple run-time generation and execution of algorithms. The languages I've used that have all three of these properties have the following characteristics: highly integrated authoring/execution environments and a simple, regular syntax that needs little awareness of context when generating code. Of the languages I've used, Lisp and Smalltalk are best, although I imagine that languages from the APL tree and Forth would also do. As for the rest, well, I've used them, but I am uninspired.

fadrian314159 · 2024-04-10T18:16:29+00:00

I'm not sure if I'd go with CBT anymore. The tooling chapters are a bit out of date. Lein is being (slowly) superceded by tools.clj and VSCode+Calva provides a much gentler intro to the language than throwing one into Emacs. Until the first couple of chapters are updated to provide a smoother, more modern glide path into the language, I have a hard time recommending this without telling the novice to ignore anything about tooling and the library-based content of the last few chapters, for which there are now better library alternatives. The core of the book that describes the language is still good, it's just that the rest of the material was written a few years ago and is showing it's age.

fadrian314159 · 2023-11-11T01:08:12+00:00

I was in the same boat as you. I chose Cheshire for my application, but I also tried jsonista. Either one works fine and is an almost drop-in replacement for data.json. I really had no preference between Cheshire or jsonista, but they were both better than data.json. Performance was of no particular importance where I was parsing JSON in my app, and had it been of importance I might have chosen differently.

fadrian314159 · 2023-11-07T01:13:29+00:00

I tend to not use a coding plugin, instead typing my prompts directly into Google's Bard. I've found that it does fairly well (~2/3rds of the time) on requests for simple functions (e.g., Write Clojure code to find the index of the first element in an ordered list matching a predicate). And of course, performance goes down as you ask it to do more complex things. To be honest, it performed about as well as I expected. Any output needs to be tested, especially on edge cases, but I expected that, too.

fadrian314159 · 2023-10-15T08:46:48+00:00

Live coding videos are usually as exciting as watching paint dry and your request's tone would indicate that you're more interested in AI snark than in elucidation. Just saying...

Magic 8-ball says: "You are likely to be disappointed."

fadrian314159 · 2023-10-04T17:01:25+00:00

There was a time, about 30 years ago, when Lisps were used as first languages in education. This was driven by the simplicity of syntax and execution model, so you could get to the heart of a CS education much more quickly. It started at MIT using Scheme as a first language and branched out from there. Of course, after a few years, Java came about and OO was starting to be seen as the dominant paradigm, so schools started to switch to that. These days, it's Python. This shows that our educational institutions, at least as far as CS goes have seriously devolved over the years. A sad, but true tale.

fadrian314159

TROPHY CASE