"A lede is the introductory section in journalism and thus to bury the lede refers to hiding the most important and relevant pieces of a story within other distracting information."
Burying the lead in the journalism would actually be burying the lead (like the metal) so they aren't even pronounced the same. Many people make the same mistake you do so this misconception proliferates.
This is a big misunderstanding of languages and multi-threading. First, plenty of languages including C++ have a const keyword, rust is just const by default, so that doesn't enable anything new through the language. Even marking something const doesn't enable anything new, it's just convenient safety.
Single threaded programs being normal was originally from almost no systems having more than one core or CPU. Then there were few languages that had threading built in. Someone knowledgeable would have to use the OS API to launch threads.
After that threading has mostly come from structures that are already built. There is nothing difficult about copying data if that's what people want to do. There is nothing that says scheduling has to be slow since you can have threads taking data from a queue. None of this has anything to do with rust.
you are no longer being slowed down by the software scheduler in the kernel
This isn't necessary if you just create threads and let them grab data they need, work on it and move on.
CPUs are just so much faster than their memory controllers
This assumption isn't true. It takes solid optimization to end up limited by memory bandwidth. The problem is memory latency and that is not something that can be solved by adding more bandwidth from another memory controller.
That would be about 3 billion transistors and a 7800X3D is apparently about 6.5 billion transistors, but there are lots of problems.
The first is that they would spend all their time waiting on memory. If you run a CPU at 5 ghz, you will have 500 cycles before you get the bytes from memory you want.
1% of a modern CPU is running the instructions, the other 99% is trying to keep it busy. You would then need to double the transistor count for cache, but even then you will be waiting on memory for everything that you haven't already used and put in cache. To counter act that you need prefetching so you can get from memory ahead of time etc. This goes on and on until you either build a modern CPU or a modern GPU.
The other problem is that this doesn't solve a problem anyone has. People aren't really clamoring for more raw math or instructions any more. Most of it goes to waste by running scripting languages that run at 1/100th the speed of naive C. Most C runs at 1/100th the speed of a real optimized program. It's as if someone built a super powerful engine and everyone just decided to fly jumbo jets to work instead of using the same cars and less gas.
Then finally there are modern GPUs which already can do one million floating point operations in the time it takes to get a single byte from memory (the single byte is really two cache lines which is the minimum and this also includes the memory not being in the TLB).
It's all memory latency and software optimization. The need for raw math is not a general computing problem any more, it has all been relegated to GPUs.
> 1% of a modern CPU is running the instructions, the other 99% is trying to keep it busy. You would then need to double the transistor count for cache, but even then you will be waiting on memory for everything that you haven't already used and put in cache.
Waiting for those periods only occurs when a modern cpu is fetching memory outside its caches. When its all in cache it runs at basically full speed.
> To counter act that you need prefetching so you can get from memory ahead of time etc. This goes on and on until you either build a modern CPU or a modern GPU.
Thats all true but what im suggesting is if you had MORE a lot MORE humble cpus even if they run at a much less than GHZ, doing a little work the sum of the humble cpus would actually become more than the modern fast cpu.
Think a lot of slow donkeys would still get move more than a ferrari, for less money and less fuel.
> Then finally there are modern GPUs which already can do one million floating point operations in the time it takes to get a single byte from memory (the single byte is really two cache lines which is the minimum and this also includes the memory not being in the TLB).
Thats all true but the cost of that performance is a lot of heat and silicon.
Waiting for those periods only occurs when a modern cpu is fetching memory outside its caches
I said that exactly. Half the cpu will be cache and it only helps once data is in the cache, which it won't be if you are running through big arrays. Big arrays would be necessary to supply a bunch of tiny cores, unless of course you had prefetching and other mechanics.
When its all in cache it runs at basically full speed.
L3 cache will not run at full speed. The latency is much better but you still have 40 cycles. That means that every lda instruction will wait for 40 cycles when in old computers it would take one cycle. That's just for anything already in cache, not the 500 cycles you would stall for something outside of cache. Don't forget that there are no cache lines and no out of order execution so you pull down a single byte after 500 cycles and if you read the next byte you wait 500 more cycles.
Thats all true but what im suggesting is if you had MORE a lot MORE humble cpus even if they run at a much less than GHZ
Your idea is clear, it's not a misunderstanding, it's just something that has been considered a long time ago and dismissed.
Think a lot of slow donkeys would still get move more than a ferrari, for less money and less fuel.
People don't want slow donkeys, they want to move themselves with a ferrari or jet, or huge amounts of stuff on a giant ship. Donkeys are obsolete. They don't cross water, they don't move fast, they don't go straight.
Thats all true but the cost of that performance is a lot of heat and silicon.
So what?
What if that power was given to a million 6510s ?
You would have the same number of transistors and you would be able to do 0 floating point calculations because those CPUs had no floating point units. You can't even multiply integers. You can add and subtract integers. Now you have to sit and wait on every memory load, you have lower Ghz and every math operation is going to use lots and lots of cycles because you can't even multiply integers. Good luck with that.
> I said that exactly. Half the cpu will be cache and it only helps once data is in the cache, which it won't be if you are running through big arrays. Big arrays would be necessary to supply a bunch of tiny cores, unless of course you had prefetching and other mechanics.
The 6510 did not have any cache. Im suggesting the cost/benefit of cpus that do not have any cache, no branch prediction, no out of order, just the minimum to execute its ISA.
Again cutting things down to as simple as possible and hope for the best.
> Your idea is clear, it's not a misunderstanding, it's just something that has been considered a long time ago and dismissed
It was dismissed because x86 has a very large impossibly expensive range of software that would be lost on any new different arch.
> You would have the same number of transistors and you would be able to do 0 floating point calculations because those CPUs had no floating point units.
The 6510 could do floating point in software. Im not saying that the solution must be a million 6510, one could add a simple FPU and advance some of the features. Im just suggesting an arch without all the extras that require lots of transistors like Out of order execution, caches and all that.
Im suggesting the cost/benefit of cpus that do not have any cache, no branch prediction, no out of order, just the minimum to execute its ISA.
Right, again this is clear. Although you did talk about cache earlier, it's not a mystery what you are trying to say. It's simple, easy and doesn't work.
Again cutting things down to as simple as possible and hope for the best.
These old CPUs are extremely efficient with transistor budgets but they do almost nothing.
It was dismissed because x86 has a very large impossibly expensive range of software that would be lost on any new different arch.
This is completely wrong. If this architecture worked, there would be a 100,000 original x86 cores on a chip. You can look at the evolution of x86, super scalar computers like cray machines, the successors to the 6502, chips from sun, dec, SGI etc. and see what they added and why.
There are new CPUs running riscv that you can buy right now and they don't do anything like this even though it is running on a completely new instruction set.
The 6510 could do floating point in software.
32 or 64 bit floating point numbers using just 8 bit integer add and subtract with bit shifts. Kind of seems like the thing that would be much better done in hardware. Maybe do 8 or 16 floating point operations in a single cycle.
one could add a simple FPU
The first FPU was 45,000 transistors. Now each chip isn't 3,500 transistors any more. Don't forget you are still moving single bytes around with every instruction, many instructions take more than one cycle to complete, you have almost no registers and the ones you have are all 8 bit and because you have no cache, every memory load takes hundreds of cycles while the cpu sits and does nothing. Also even with this FPU some instructions take 100 cycles to complete and some take 1000 cycles to complete.
> Right, again this is clear. Although you did talk about cache earlier, it's not a mystery what you are trying to say. It's simple, easy and doesn't work.
WHY ?
> These old CPUs are extremely efficient with transistor budgets but they do almost nothing.
Yes one does very little very slowly but if you add enough of them, it could be power efficient in a round about way.
> The first FPU was 45,000 transistors. Now each chip isn't 3,500 transistors any more. Don't forget you are still moving single bytes around with every instruction, many instructions take more than one cycle to complete, you have almost no registers and the ones you have are all 8 bit and because you have no cache, every memory load takes hundreds of cycles while the cpu sits and does nothing. Also even with this FPU some instructions take 100 cycles to complete and some take 1000 cycles to complete.
Sure the 8087 was complex, but 45k and 3k for a total of roughly 50k is minute compared to the billions of a modern x86 or m5. What would the performance be if those billions were divided into cpus with a budget 50k or even 100k ? That would buy tens of millions of equivalent 6510.
> many instructions take more than one cycle to complete, you have almost no registers and the ones you have are all 8 bit and because you have no cache, every memory load takes hundreds of cycles while the cpu sits and does nothing.
You are too focused in mixing the limitations of a 6510 and the weaknesses of modern cpu the cache requirement.
It doesnt have to be a 6510, it could quite easily be a 68000 or equivalent but enhanced with a FPU and given more registers. My suggestion was again was these million cpus dont have to share a single memory, they could all have local memories.
Old cpus that did mHZ did not take 500 cycles for a memory access. For being SMART you shoudl know this basic fact, the 6510 for example fetched a memory byte every other cycle.
If most instructions require several memory reads for the opcode and possibly operands like memory addresses and if each memory read took 500 cycles, the c64 which ran at 1mhz would take seconds to clear its text mode screen. Did it take seconds for the c64 to clear screen memory and not im not talking about a basic loop ?
> Again, it's obvious that you are suggesting that and with a little research it's obvious why it doesn't work out.
Where are your proofs that your statements are true ?
Demanding that you are right because you say so is very boring and nobody learns when you dont share your knowledge.
What do you mean why? Did you read anything I wrote?
That would buy tens of millions of equivalent 6510.
Not tens of millions. How do you use those cores? They load one byte at a time and it will take 500 cycles to get there. Want a 64 bit address? 4000 cycles for something that happens in less than one cycle on a modern cpu because the cpu can do multiple things at once. Then you can only add and subtract 8 bit numbers.
Want floating point numbers? Now you need 15 times the transistors, loading each float takes 2000 cycles and doing the float math takes 1000 cycles. Don't forget to write it back one byte at a time, that's another 2000 cycles. A single mid range CPU with SIMD is 320,000 faster. Feeding all those cores doesn't come for free and you have no virtual memory which means you have no OS and no multi-tasking.
You are too focused in mixing the limitations of a 6510 and the weaknesses of modern cpu the cache requirement.
It's not me, it's physics, sorry. CPU design for the last 35 years has been mostly about minimizing the impact of the latency from memory.
It doesnt have to be a 6510, it could quite easily be a 68000 or equivalent but enhanced with a FPU and given more registers. My suggestion was again was these million cpus dont have to share a single memory, they could all have local memories.
That "local memory" is called cache and it is done with more transistors. What kinds of programs do you think will run on a computer with no main memory? It is literally the only consistent part of computer design over the last 60 years.
Old cpus that did mHZ did not take 500 cycles for a memory access. For being SMART you shoudl know this basic fact, the 6510 for example fetched a memory byte every other cycle.
You think you're going to clock down a cpu to 1 mhz and have that compete with 5 ghz cpus?
You can fetch a single byte at 500 Khz. That's about 1.28 million times slower that a modern cpu. Now your 240,000 fpus (11 billion transistors of a modern / 6800 + fpu transistors) are going to lose on memory alone. Don't forget that you still have every floating point number taking 100 - 1000 cycles and your cycles are 5000x slower than a modern cpu.
Where are your proofs that your statements are true ?
It's not me, I'm telling you what exists and why. You're acting like this is hidden information. The entire history of CPU design is out there to read. I'm not predicting anything, I'm saying what already happened and why. Every step was brilliant engineers solving problems.
Demanding that you are right because you say so is very boring and nobody learns when you dont share your knowledge.
What have been writing? If you want deeper information go find it, I'm not going to copy and paste entire books to a person who doesn't want to hear that their wacky ideas don't work.
We haven't even gotten into how someone would program a computer like this, since it would essentially be impossible.
You can not agree or 'submit for this class of problem' all you want, but the fact is that now and for a long time getting the most math instructions out of the smallest die size doesn't seem to be a problem.
Realistically in most applications you can get far more processing power than you need because of clock speeds, modern architectures, transistor budgets etc.
A disposable vape can have an arm cortex m0 that runs at 24 mhz and a $1 pi pico can have a dual core m0 that can run at 133 mhz to 200 mhz.
If you want raw math you can use SIMD or a GPU model and if you need single core power you need out of order execution to hide the memory latency, because that's the real bottleneck for the last 30 years.
These multiple tiny cpu core models just don't make sense to solve any real problem and they create a lot with their complexity and latency trying to communicate with each other.
There just isn't some bizarre niche that needs more math instructions with less power consumption. People have all they need even without being efficient. If someone needs more they turn to writing actual optimized software.
It's not compression. Look it up, it's really cool. Random sampling in a sparse basis. Using the prior. Single pixel camera can reconstruct a 10MP image, etc.
A more approachable example is not needing Nyquist limit of 44.1kHz to reconstruct any frequency up to 22kHz, if the sound is sparse in some basis and samples are random.
For example, if you know a signal is only a solo trumpet, you can probably reconstruct a perceptually perfect recording from just a few kHz of random samples. But, a solo piano would need many more random samples, as there are more harmonics and the hammer strikes, greater complexity and broadband hammer click isn't sparse in frequency.
Are you asking? No, I meant below. You can't sample below the nyquist frequency and magically reconstruct higher frequency signals.
Look it up
You look it up.
Single pixel camera can reconstruct a 10MP image, etc.
All you need is to already have that image. Amazing.
If you have a bunch of high res images and you combine all their pixels into one color, then put those in a point cloud, you can check a single pixel to see which single point is closest. This is not exactly mind blowing and it has nothing to do with the nyquist limit and that's not 'reconstruction', it's just looking up using nearest neighbors.
I'll let the audience decide on this one. I came at you sharing my genuine wonder and appreciation at how incredible compressive sensing is. I'm sorry you felt threatened or something. Best of luck dude.
No one is threatened and this isn't an "audience decides" type of thing.
It just isn't what you are saying it is. The nyquist frequency is not being beat, you're talking about looking data up. I explained exactly what that could look like in your 1 pixel to entire image example.
What if there are more than one GUI-rich app, and with browser they share most of the overhead?
Those are called web pages. I don't know what the rest of this comment is trying to say. When a chat room program takes 4GB of memory, there will be optimizations literally everywhere. Everything will work from looking the current javascript to switching languages.
Your "4GB of memory" for "chat room program" is obvious reference to Discord in its Electron-based incarnation. Which certainly proves you sincerely don't understand what that means, and what the rest of my comment is about. It could be my fault, but may I suggest you first read the comment to which mine is answering, just to get the whole picture, so to speak? Missing context may be the root of misunderstanding here because I didn't write it about Discord actually. And even about Electron.
If you're just talking about being on of the 'java can be faster than native programs' people, then show me a java program and I will show you how to make a faster, more consistent, lower memory native program.
It's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent.EOQ
Good JIT is able to dynamically re-optimize code according to present conditions/load which is what can give bytecoded program in certain conditions (which aren't that rare) edge over static native code. Is it possible to make your own dynamic optimization with natively compiled PL which would beat Java, or JS on a relevant case? As a sport, sure, you would just have to make your own bytecode with JIT. Or hand-optimize in every possible way staticly, and just chose the best path when running. You can even gain more by going with assembler. Is it worth extra time, increased attack surface, and higher probability of bugs? Will you even have a good chance to succeed? It is genuinely impossible to answer without full requirements which bind you. Independently, it's fair to say that on RAM side, natively compiled code wins most of the time. Is it something users care about is again a question to think each time anew. To quote me again:
But never say "never" until you know what exact problem you have to deal with. EOQ
Is it possible to make your own dynamic optimization with natively compiled PL which would beat Java, or JS on a relevant case? As a sport, sure,
'As a sport' doesn't mean anything, it's just completely possible. I don't even know how you got into java in the first place, that has nothing to do with the current topic. You injected it out of nowhere.
Why not ask someone involved if they want it or tell someone the prompt that made it? Someone who does the work of checking it and sanitizing it can take the credit.
Depends on the project but some actually adopt an outright hostile response to this. Sometimes justifiably. Sometimes not.
It's honestly not worth it. I understand both sides here, but people are going to have to come up with new ways of collaborating. Pull requests are likely not it anymore.
Lots of people have used lisp, scheme or scripting languages and never go back. Lisp was created in the 50s, if it converted everyone it would have done it a long time ago.
I don't think these 'most people' you anecdotally cite have gone deep enough into Lisp to realize what it's all about, and why it turns users who do taste real Lisp into Lisp fanatics.
You probably have no idea how much Lisp is out there in real, production systems. Just because the majority is required to be on Python, doesn't mean it's the best stack for solving problems. Gathering language stats for Lisp is also challenging, because it's not a single PL - it's a whole family of dialects. And these dialects and communities are absolutely thriving. Modern Lisp landscape is very, very different from LISP you're talking about (invented in the 50s).
I just wanna throw myself in here and get some advice. I’ve started using lisp recently mostly for emacs configuration but also doing a bit of recreation game programming in Fennel. If I wanted to learn a lisp for general programming/application stuff like writing a shell, a compiler, something more user facing, what would be good to check out?
It doesn't matter. Just start with a Lisp, any Lisp. Grok the idea of being REPL-driven, pick some structural editing idioms. That's all you need. Then, you pick a runtime for your needs. Depending on the runtime semantics you can choose a Lisp dialect for that runtime. Pick up some Clojure, it's enormously practical for any kind of data manipulation and analysis - small or big data. I don't even use jq anymore - studying http response in Clojure REPL is so much more convenient - you sort, filter and group data anyway you like.
I prefer the schemes.... Chicken scheme for standalone programs, s7 for embedding into larger systems. They're simple and easy to mold to whatever shape you want in my experience
In practice, it is exactly the opposite of a "curse". From many practical points of view, when you actually use it, it feels and behaves like "one good language". You probably have little idea how jaw-dropping it feels when you write the same piece of logic in Clojurescript, and it seamlessly runs on both JVM and Javascript - completely incompatible platforms. I have not seen this kind of code-reuse even with Node, where the runtime is basically the same on both sides, but you still have to write code for them separately.
And you haven't even seen the Clojure<->C++ interop in Jank. Anyone who has even the slightest clue of what's up says this is some kind of blackmagicfuckery.
I mostly don't use Lisp for work; we have some Clojure services, but they rarely require any attention - mostly when we need to bump dependencies. But I use a Lisp for personal stuff and I switch between different dialects multiple times a day - Elisp, Babashka, nbb, Fennel, Jolt, Jank - and the overhead is virtually none. I can't say the same thing about switching between JS/TS, even though I have used them for far longer than any Lisp.
Your entire rave sounds like exactly like a NixOS heavy user ranting about the greatness of flakes and immutability.
And I am left wondering if it is that great why didn't it take over. I think you are ignoring some minor things that make it unpalatable for the most programmers.
Fair, enthusiasm isn't evidence. But adoption isn't either. Javascript took over because browsers shipped it. Python took over through universities and numpy. Neither won a contest on language design.
Your comment to me sounds ironic because I don't even use Nix. I manage all my dotfiles in a single org-mode file and tangle them from there. It takes a few minutes to bootstrap a machine from scratch and makes my systems semi-immutable.
Comparison with nix on the surface sounds fair. Nix has steep learning curve, but most users once learn it, stay in it. Same can be said about Lispers - I have never met a person who wholeheartedly dove into e.g., Clojure and ever said it's [widely] impractical. There's unavoidable pain of getting into both, but the difference is where the pain sits. With Nix, much of it sits in the language and tooling: an untyped, lazy language with cryptic errors. With Lisp, the language is the simple part, and the cost is unfamiliarity and the ecosystem. Lisp's core is small enough to explain on a napkin, Nix's isn't.
> ignoring some minor things
I am not ignoring them, I speak from my heart. I know first hand how pretty much every mainstream popular stack lies to you about its own complexity. Neither Python nor Javascript are simple, small language ecosystems and I say that with full confidence after decades of using them. There's a real, practical wisdom of Rich Hickey's "simple vs easy" distinction and majority of programmers either don't know, don't understand, or don't care.
Gonna pushback on this. Adoption is proof of fitness to purpose in the Worse is Better way.
> Nix has steep learning curve
Not what I meant. I meant more in praise vs. how little you can see it in the wild.
> I am not ignoring them, I speak from my heart
I believe you speak from the heart, the same way I believe NixOS people speak from the heart. Or OpenBSD enthusiasts. The issue isn't the passion, but the way that passion biases you to overlook some corner.
I suspect in Lisp/Clojure case it's the lack of a large community and performance issues. Either the community is uninterested in making Lisp fast, too splintered or ignoring benchmarks.
You probably have no idea how much Lisp is out there in real, production systems.
We really do have a good idea because we can see how much every language is used on github and we can see bulk job listings on the internet.
Just because the majority is required to be on Python, doesn't mean it's the best stack for solving problems.
So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Gathering language stats for Lisp is also challenging, because it's not a single PL - it's a whole family of dialects.
If you take them all together, they still don't amount to much.
Modern Lisp landscape is very, very different from LISP you're talking about (invented in the 50s).
The old lisp landscape actually had some people using it.
It might be time to accept that most experienced programmer have heard of and used lisp or a variant at some point and it just didn't offer a real pragmatic advantage. It was very influential when the alternative was putting in assembly instructions using their hex codes, but modern languages have adopted all the best parts. The parts that are still unique like s-expressions, macros and 'code as data' haven't really paid off as much as people like to pretend. If you have every program writing their own crazy DSL, things get very squirly very fast, because every program becomes it's own niche language.
Mixing 'code and data' is the same thing. The key to simplicity is to use simple straightforward data structures and keep the data and execution as separate as possible because data is static and easy.
It has been 70 years and many ideas were hugely influential while some others ended up doing more harm than good. People thought inheritance was a great idea for 20-30 years too and we're still trying to fix that damage.
> We really do have a good idea because we can see how much every language is used on github and we can see bulk job listings on the internet.
Public GitHub repos and job ads measure open source and hiring. They miss private production code. Nubank runs a bank with 100M+ customers. Google Flights grew out of ITA's Common Lisp engine. Those don't show up much in either metric.
Just, spend a minute looking at Nubank's numbers. It is the biggest digital bank in the entire world. They grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. For JPMorgan (just for low-key comparison), getting to their ~80M customers took around 150 years and dozens of acquisitions. It's not totally fair, because I'm handwaving assets here and other things, but seriously, how can this story be just ignored?
> So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
> The key to simplicity is to use simple straightforward data structures
You're reciting word for word the Clojure philosophy. Rich Hickey's "Simple Made Easy" talk makes exactly your argument.
> they still don't amount to much.
Go check Github Language stats and see where Emacs Lisp sits there. And let me remind you, Elisp is not a general-purpose lang, it was made for one and single objective, it's an effing text-editor configuration tool. Once again, r/emacs gets daily announcements of new Emacs packages. I'm not even exaggerating, every single effing day there's someone posting about a new package. Are you seriously not curious to see who the heck all these people?
> It might be time to accept that most experienced programmer
I think you seriously need to study the demographics of Lisper communities. Maybe log into Clojurians Slack, or watch some talks from Clojure conferences. Majority of them are surpassingly experienced. Over 95% of them are bona fide programming language polyglots. Most of them either borrow ideas from other languages into Lisp or take what they learned from Lisp into other languages. They rarely bash on specific PLs, because the choice of a language for specific scenarios largely doesn't matter, they understand that. They are not language fanatics. Neither am I. I'm not telling you to switch to my "beloved language". Because Lisp is not a language. Lisp is an idea. And it is a very much a brilliant one.
> If you have every program writing their own crazy DSL
> Mixing 'code and data' is the same thing.
"Code as data" doesn't mean mixing data with execution. It means code is written as ordinary data structures, so tools, editors and the program itself can read and transform it trivially. Languages without it still build DSLs. They just put them in YAML pipelines, JSX, HCL, decorators and annotation processors, and each one needs its own parser and tooling.
> modern languages have adopted all the best parts.
They adopted GC, closures and FP idioms. Most didn't adopt connecting to a running process and redefining one function while it runs, or structural editing. Those still change how the work feels day to day.
> It has been 70 years
Yes! That's the point. Great ideas are timeless and the grand idea of Lisp as a practical notation for lambda-calculus is timeless. Even though it was not initially designed as a notation for lambda calculus, the way how it fits almost purely incidental. McCarthy invented a language and, by accident, found inside it a minimal self-describing core. That core is the timeless part, and it stays timeless because it was found, not designed. Whether anything in mathematics is truly "discovered" is a philosophical question, but Lisp is one of the stronger cases for saying so.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
Public GitHub repos and job ads measure open source and hiring. They miss private production code.
Not really, because if companies use it they will mention it when hiring. It isn't back up by any real information. You're basically saying that all data says the opposite, but it's used a ton because of the one example company. This is like when people say haskell is about to take over because someone at facebook used it for an email filter. Everyone gives the same exact example. Every popular language has about a million examples.
Then you are trying to argue that customers or growth of one company has to do with language adoption. Do you realize that this seems like a desperate backwards rationalization of what you wish was true?
watch some talks from Clojure conferences
I have, they are obsessed with the rabbit hole of language pagentry and never seem to end up solving real problems. It's all about more and more complex language mechanics and labels of complicated techniques.
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
Saying it doesn't matter that it isn't popular contradicts it being popular.
Do you know where emacs lisp ranks? 49th, behind a half dozen languages I've never heard of and configuration languages.
Most didn't adopt connecting to a running process and redefining one function while it runsThose still change how the work feels day to day.
Agreed
Great ideas are timeless
Agreed, that's why lisp has been so influential. That doesn't mean it is objectively a good choice by today's standards.
the grand idea of Lisp as a practical notation for lambda-calculus is timeless
Maybe, but the truth is no one cares about that because it doesn't mean anything to productivity or better software.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
This is a nonsense statement that doesn't relate to the conversation. You're giving something a label that no one is asking for then saying the label is super important. No one cares about this, people can already do what they want.
> This is like when people say haskell is about to take over
I never said Clojure or Lisp is "about to take over", besides you're trying to use one spam-filter system inside a PHP company example, against CircleCI, Metabase, Walmart, Grammarly, ITA/Google Flights, Cisco, Rate.com, Funding Circle, Netflix and bunch of other teams that use it in production.
> I have, they are obsessed with the rabbit hole of language pagentry
There's tons of different real-life use case talks. From Boeing/Embraer, from Funding Circle, from CircleCI, from tons of smaller startups running things on prod. You're just insisting of something you haven't even bothered to give a critical look at.
> That doesn't mean it is objectively a good choice by today's standards.
Okay, tell me more about "today's standards". What do you mean? No language is "objectively a good choice". A choice is good or bad for a team, a problem and a set of constraints.
It is a great choice for specific use cases. Fintech startups notably finding that to be very true.
> it doesn't mean anything to productivity or better software.
Clojure's immutable data by default rules out a whole class of concurrency bugs, and I already gave you the real-world example: Nubank scaled to thousands of engineers on Clojure and Datomic. That is a large bet on the language at a large scale, but you're just choosing to ignore that. I get it, every niche language has its "company X uses it". But once again, I'm not advocating for a single PL specifically. I'm preaching the idea of a language. The idea you're just outright dismissing because "it would have converted everyone a long time ago."
I've been working in this field for decades. I have gone through over a dozen language stacks: different paradigms, tons of tooling, techniques, patterns, hype cycles and silver bullet calls. If I've learned anything, it's that the majority is not only not always right, but in most cases it is flat-out wrong.
You don't have to trust me on this (some rando on HN), just listen to renowned CS veterans with big names - Guy Steele Jr., Alan Kay, Sussman, John Carmack, Crockford, Yukihiro Matsumoto, Paul Graham, Uncle Bob, Steve Yegge, Dijkstra, Brendan Eich, Karpinski - there are tons of names who'd agree that Lisp is an everlasting idea.
Lisp endures. It is thriving; there are new Lisp dialects coming out every few years. Some of them are serious tools, not toys. You can realistically run Lisp on pretty much any platform today.
I'm not suggesting everyone should just drop whatever they use and switch. I'm just saying there are some ideas that are worth understanding and your view on where Lisps stands today is misguided.
> This is a nonsense statement that doesn't relate to the conversation.
I.e., "lambda-calculus doesn't help anyone ship software". Yeah, maybe you're right. Yet it is still in there, whether we want it or not - it explains why the software we ship behaves the way it does. So maybe it's worth understanding the language that explains it best.
I never said Clojure or Lisp is "about to take over",
I didn't say you did.
CircleCI, Metabase, Walmart, Grammarly, ITA/Google Flights, Cisco, Rate.com, Funding Circle, Netflix and bunch of other teams that use it in production.
So which is it? It's popular or it's not popular but popularity doesn't mean anything?
Also naming a bunch of big companies doesn't mean much. When there are 10,000 employees, a few people are going to do something with niche tools. That isn't what these companies were built on and it's just a cheap use of their name. Again, it's like haskell people saying, "no on uses it? ever heard of facebook??" and it turns out to be one small program over the last 25 years of thousands of programmers' work.
Okay, tell me more about "today's standards".
Maybe you should tell me, because your comment is basically an appeal to authority without real numbers to back it up. You aren't talking about crucial features much or why you even like it.
Clojure's immutable data by default rules out a whole class of concurrency bugs
In practice this ends up being a feature with silver bullet believers like haskell's lazy evaluation, but when people try to make it work in practice the performance hits and awkwardness just don't give any benefits because you're fighting how a computer works, and if you really need it it can be replicated and used in specific situations. You can already make things const in system language and you can make structures and architectures that rely on copying data for certain parts of parallelism.
I've been working in this field for decades.
So have all the people not using lisp.
just listen to renowned CS veterans with big names
Listen to them say what exactly? You just listed a bunch of names as if that somehow makes a concrete or technical point. Most of those people don't ever use lisp in the first place so I'm not sure what this is supposed to say. "Uncle bob" is a buffoon snake oil salemen that knows less than nothing.
Lisp endures. It is thriving
Then why is the most popular lisp emacs lisp, which is less popular than 'vim script', starlark, gherkin, solitidy etc.
> After 70 years it might be time to accept this reality.
I think you're confusing my pragmatism for an enthusiasm of a misguided novice. I agree, sometimes you have to let it go, and I have. I started my coding journey with BASIC, in college I learned Pascal, C and Assembly, then Turbo Pascal, then later Delphi. You might be too young to remember how huge Borland was back then and I used their tech profusely. There was a period where I coded in Actionscript and VB, picked Macromedia, started making web-pages. I even worked in some esoteric language where all the operators were in Russian - I was working on a ERP system in Dubai with my Slavic friends. Then I picked some Perl and PHP. Following Heilsberg's work on Pascal, I went to .Net, when the guy moved from Borland to Microsoft. I switched from VB to VB.net, then to C#, I picked up some F# later. I developed games for Silverlight, remember that one? I was an early adopter of Typescript, forcing my team to switch from their beloved Coffeescript, that was at the time when GitHub in their style guide was explicitly asking to use Coffeescript for new projects instead of JS. I tried almost every available altJS option - Livescript, IcedCoffescript, Purescript, ELM, Reason, Fay, Haste and GHCJS. I was heavily invested into CLR only later to realize that it started feeling like a mental prison. I switched to Python on the backend. That's when I first time saw Clojure and blindly rejected it - it looked too weird. I then learned some Haskell, tried Idris, did Ruby, Golang, etc. etc.
Anyway, the point I'm trying to make - there are numerous tech pieces that I have completely parted with, with absolutely zero regret. Some pieces still remain practical - they simply work. I don't miss Pascal, Perl, Ruby or PHP. I'm a bit sad that Elm never took off, it was nice. Yet I don't see any reason to bury Lisp. It just works. It remains an enormously practical tool with zero meaningful alternatives.
I can tell you with conviction that using babashka for bash-scripting, or nbb for node stuff like simple web-scrapers is far, far better experience than the alternatives. Reducing huge Lua boilerplate to a five-liner Fennel macro feels liberating. Building web-apps with Reframe (today I'd use Datastar) felt like playing videogames. I stopped using jq for analyzing request data, Clojure REPL for digging through data is much simpler, faster and feels less confusing to me. And nothing, just nothing even remotely comes close to what I do and can do with Emacs. That didn't come out of nowhere - I was an IntelliJ power user for almost a decade, and used tons of different text editors and IDEs - from Eclipse to Atom. I still sometimes open VSCode and reach for Neovim in the terminal. I know what I'm talking about.
Trust me, another 50 years will pass, yet Lisp will remain. I can clearly see that; the idea of Lisp is simply way too practical to die. Would it ever become popular in a big team setting? Nobody can predict that. Perhaps it never will. Maybe there will be new Rusts, Kotlins, Elixirs and ML-like things, with Lisp carrying on in the shadows.
It's great that you have conviction but no matter how forcefully you say something this seems like your own personal journey to becoming obsessed with lisp.
That's fine, but it doesn't mean it is being used. Listing people and companies and languages with no context isn't real data.
Trust me, another 50 years will pass, yet Lisp will remain.I can clearly see that;
It has been 70 years and plenty of ideas have remained even though the actual languages are niche. You seem very confident that you can predict the future. Does this future predicting ability apply outside of 70 year old computer languages?
the idea of Lisp is simply way too practical to die.
The idea didn't, it's in the languages people use.
"A lede is the introductory section in journalism and thus to bury the lede refers to hiding the most important and relevant pieces of a story within other distracting information."
Burying the lead in the journalism would actually be burying the lead (like the metal) so they aren't even pronounced the same. Many people make the same mistake you do so this misconception proliferates.
reply