Plenty of ways to define complex data shapes in Clojure

Spec is definitely underrated here considering it's built into the language and has a wider scope but for most people they want the intellisense experience which you can get with clj-kondo + mailli but is not built in so most teams don't use it, fair enough

I'd like to move the goal posts though and say I want flowstorm in every (any other?!) language

I can just run the program and scrub backwards and forwards through the execution and look at all the immutable values frame by frame with a high level UI with plenty of search/autocomplete options

For program understanding there's nothing better

The fact I can program against the timeline of values of my program and create custom UI on top is crazy

One of the most mind blowing demos to me was Bret Victor's inventing on principle and having a programmable reverse debugger for your language makes those demos viable

I built an emulator recently for work that replays what happens on live locally, combined with flowstorm I can go line by line and tell you exactly what happened and why, no print statements no reruns with my own custom UI customised to our apps interesting parts

This is my appeal to anyone outside of Clojure please build flowstorm for JavaScript and or Python

The design of flowstorm is definitely helped by the fact that 95% of Clojure programs are immutable but I don't think it's impossible to replicate just very difficult

This indeed is one of the superpowers. I hope Elixir will eventually acquire it.

Yeah I wish variables were immutable by default and everything was an expression

Oh well continues day job as a Clojure programmer that is actively threatened by an obnoxious python take over

As a Python programmer at day job, that is Clojure-curious and sadly only gets to use it for personal projects, and is currently threatened by an obnoxious TypeScript take over, I feel this.

In the context of the original discussion, TypeScript (and ES6) has const and let.

Neither let nor even const are immutable (const prevents reassignment but not mutation if the value is of a mutable type like object or array).

Yep, I believe you'd need to call Object.seal(foo) to prevent mutability. Haven't really had the chance to use it

Object.freeze is the one you're looking for.

const + Object.freeze is a lot to remember and cumbersome to use throughout a codebase, very relevant to Carmack's wish for immutability by default. I'm grateful Rust opted for that default.

Fair enough about const and let, the obnoxiousness for me is a combination of the language ergonomics, language ecosystem, but mostly the techno-political decision making behind it.

well yeah except const doesn't make objects or arrays immutable

Yeah it makes their structure immutable? Something like that. Not useless but not what you would expect.

But for non-objects and non-arrays it's fine.

I feel that Java’s “final” would have been a better choice than “const”. It doesn’t have the same confusing connotation.

If you avoid metaprogramming and stick to the simple stuff, python and typescript are almost the same language.

To be fair, comprehensions (list/object expresions) are a nice feature that I miss a lot in JS/TS. But that's about it.

Removing barriers to sloppy code is a language feature.

That is why vibe coding, JavaScript and Python are so attractive.

Removing barriers to civil engineering building design is a feature.

Who needs to calculate load bearing supports, walls, and floors when you can just vibe oversize it by 50%.

Rust taught me that a language does not have to be purely functional to have everything be an expression, and ever since I first used Rust years ago I've been wishing every other language worked that way. It's such a nice way to avoid or limit the scope of mutations

Clojure will always be faster than Python. So you have that, at least.

You are not a Clojure programmer. You use Clojure to solve problems in a professional context. I'm sorry that there's a political tribal war based on language going on at your workplace.

But especially now that coding agents are radically enabling gains in developer productivity, you don't need to feel excluded by the artificial tribal boundaries.

If you haven't, I recommend reading: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

I remember that post and essentially agree with everything in it and your points too.

However there's a real-world factor that I don't think it covers, which is that having ten years of experience in the ecosystem for any language almost guarantees that you're going to be faster, more efficient, more idiomatic, and generally more comfortable through familiarity with that language and its ecosystem than with any other 'drop in replacement'. And you'll also probably be more aware of what doesn't work, which is just as useful. You can always tell when someone knows their tools well when they can immediately tell you what sucks about them, and possibly even the history of it and why it might happen to make sense, even if seems bad.

This isn't an argument for favouring speed or efficiency, just an ackowledgement of what is lost when you choose or are forced to move to a different environment.

Languages are a lot more than just syntax. Language-specific features, conventions and common idioms, language implementation details that end up being valuable to understand, familiarity with core library, familiarity with third party libaries (including the ones that are so well-known as to almost be considered core), package management, documentation standards, related tooling, foreign-function interfaces and related tools to make that workable, release concerns. The list goes on.

There's no tribal boundary here, just a belief that time spent with a given tool and all its idiosyncrancies (and programming languages are their idosyncracies, otherwise they wouldn't be different) is valuable and not something to pass up, even if I agree with the thesis of the article.

Can you bootstrap your way to a passable, possibly even idiomatic, solution with coding agents? Yes. Does that mean you've managed to short circuit the results of long-term experience? I'm not so sure. Does it matter? Depends on the person or environment, I guess.

I don't think the learning curve for a new tool is a straight line (I imagine more logarithmic), so it's not that you'd need the same amount of exposure in terms of time, but that does imply the cost of changing is up-front.

There's also a difference between choosing to investigate a new language out of your own interest and having the time to do it properly, versus having some top-down mandate that you must now use <X>, meanwhile still having to meet the same deadlines as before.

You know I read this when it came out but have gotten out of the habit of applying it.

Thanks for the reminder. Will work on putting these ideas back into practice again.

The Clojure community tries to achieve long lived applications

It helps that the core language has been incredibly stable

Remember Forbes list is a marketing device

Do not treat it like the real list of world's richest people

Yes these numbers are peanuts compared to the Rothschilds and Saudis of the world. But the question was about self-made billionaires, which I believe everyone on that list is.

Nice to hear about Pathom being incorporated

To me something unreadable is code that I cannot statically make any assertions about the runtime behaviour of the code

This function you're complaining about looks like 2 virtual threads doing program input reading and output writing for the LSP client given some ArrayBlockingQueues in about 25-30 lines

If I wanted the complete story I could use Clojure's inbuilt test runner to slip some ArrayBlockingQueues in there and run it under record with Flowstorm

Then leisurely seek through the entire state of the program, to get the play-by-play of how this works

There are so many good design choices in this language and a good 30% of colleagues I run into are not even doing the basics of like running a REPL, I think some people just need to clock in with a decade of C# or PHP or TS or JS or Python or whatever to get a taste of a language with next to no inbuilt immutability, statements instead of expressions, no reload-ability in the language semantics and just crapshot debuggers that run in lockstep with the program execution

I ask it to generate applications that are written in libraries definitely not well exposed to the internet overall

Clojure electric V3 Missionary Rama

With LLMs we are starting to get the technology where comments could be programmatically rated by more interesting scales than upvotes

There's a big problem with "car blindness" when it comes to cars, pedestrian crossings, car signs I think we forget how invasive they are.

So instead, I want you to imagine the sea or a very large bay, the most wide open space available, then I want you to imagine a ferry that can carry 500 people, big yes but there's still plenty of sea and its reasonably tranquil.

Now imagine 500 people on jet skis roaring around, then imagine that the jet skis and ferry are all trying to get somewhere different but that's relatively the same, perhaps commuting between the different sides of the bay.

If I was mayor I would put a stop to 500 jet skis and say look you have to use the ferry, people on jet skis keep colliding with each other, the noise is horrendous for people on the beach and makes swimming dangerous, and it's also wildly power inefficient when you step back - that's even if we ignore the pollution! 1000 spots to store a 500 jet skis on both sides of the bay is perhaps even worse!

If you can make a sea packed and grid locked with just 500 just imagine what it does to a city with thousands, hundreds of thousands, if you then turned to me and said the jet skis drive themselves! I would still think most people should be taking the ferry and there's a upper limit to sustainable jet ski use.

The ferry is not originating or stopping at every possible destination on the shoreline, so the ferry is only useful if its passengers 1. have a second way to get from their origin to the ferry and a third way to get from the ferry to their destination. And if the ferry does stop at every possible origin and destination along the shoreline, then it's going to take much longer on average than a point-to-point jetski.