2,928 karma · joined February 14, 2015
[ my public key: https://keybase.io/agzam; my proof: https://keybase.io/agzam/sigs/La7qFk8YkbwfkgeSx7vkBWBba2f3HIpZyNVxUHvshbU ]
Any language is difficult at first. Nobody ever comes to any PL, opens random piece of code and goes like: "yup, I understand everything". It is called "code" for a reason, it's not "revelation", it takes some effort to grok it.
I bet you have no idea what Emacs is for, what it is capable of; you probably think it's "a text editor", yet in experienced hands it simply destroys all the other alternatives, easily. TextMate, Eclipse, Komodo, Aptana, Zend Studio, Dreamweaver, Brackets, Atom, Sublime Text - each of them at some point in time was more popular than Emacs, most of them slowly disappeared, Emacs is still here, stronger than ever. That is a success story.
I guess you have techno-myopia, and just can't see past your own bubble - some ideas are simply timeless: Lambda Calculus, Relational algebra and SQL, Vim modality, Regular expressions and finite automata, Homoiconicity, Unix Pipes, Curry-Howard, Immutability, Garbage Collection, etc.
None of that will ever be affected by the industry trends and will always be relevant. Nobody can kill Lisp because it's not a concrete implementation, it's an abstract idea. Clojure won't ever die, it will simply transform into another kind of Lisp. Just like it emerged as a Lisp, built on top of other ideas. Newton's laws no need to be "successful", they seek no recognition, it's not a popularity contest. They are still relevant, even after Einstein's discoveries.
What's your goal here? To prove something to me? Buddy, I'm far beyond redemption - I've seen way too much crap, and I learned how to collect good ideas and put them to good use. I suggest trying something like that. Some ideas are worth attention.
I don't know what the heck makes you so angry; I suppose it's your own inability to look into a given idea and, with candid curiosity, attempt to see what it is about. Your views are one-sided. You should at least acknowledge that I have seen both sides of that coin and maybe, just maybe, there's some truth in my tale, despite of me being biased (everyone, almost always is).
Thank you. Perfectly proves my point. "Some people still get triggered by the title alone."
> most people do think Lisp is difficult to read
Correction. Most people unfamiliar with Lisp think that. I've been using Lisp for over a decade, I went to conferences, organized meetups, used Lisp for work and for personal projects, I met many experienced Lispers and I have mentored complete newbies. Not even once have I met someone in person who actively practiced writing and reading Lisp and ever complained about its readability.
What makes Ramayana difficult to read? Sanskrit - you need to learn darn language. What makes Quran difficult to read? Arabic - you need to learn darn language. What makes Lisp... the language, you need to learn the darn language. That's all you ever need to do. And you have to do it once, never twice, never repeatedly. Do it once in your life and that's it. It suddenly becomes not so difficult to read. Just learn the fucking language. Why the fuck complain about anything without first learning the darn thing?
Netflix uses it. Amazon uses it. Apple uses it. Walmart built their billing system in it. Cisco's entire cybersec stack is on it. Even NASA uses it.
Let's see, how has it been "dying"? Clojure, Clojurescript, Clojure-Dart, Coalton, Fennel, Janet, Jank, Jolt, LFE, Joker ... and these are relatively recent additions. The amount of Emacs Lisp on GitHub alone should be at least surprising - go check the GitHub lang stats, isn't it weird - a non-general-purpose PL, that has one and only one intent, is among the top languages, why? Check the r/emacs subreddit - there are daily, pretty much daily announcements of some new Emacs packages. Who the hell are these psychopaths? Don't they realize that Lisp is "dying"?
You don't know jack shit about whatever you're trying to talk about, and you call yourself "a hacker"? Honestly, it's pretty sad when someone can't find the time and patience to learn an instrument and then blame their own failure on the thing. Rather pathetic.
Opinions don't mean shit unless they are supported by evidence, and Lisp has plenty of it. It has survived subjectivity for almost 70 years, and it's still thriving. Good ideas don't need to prove anything; they just exist. If you still cannot see the reasons for why so many people still choose to use it, I'm sorry, that's just dumb and nearsighted. And you don't really have to listen to me - try to find some renowned CS academics or big-shot programmers publicly bashing Lisp - you won't find many.
Great. Arguing about "readability" with a dyslexic person. What could ever go wrong here?
You are incorrectly presumptuous. Common Lisp had lexical scoping as a design requirement from its first technical meeting in 1981, three years before the language was published. https://dl.acm.org/doi/10.1145/234286.1057818 https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
Steele wrote the Lambda Papers in 1975-1980, before CL existed. They contrast Scheme with MacLisp, and Steele then brought Scheme-style lexical scoping into CL.
CL marks itself as different from its dynamically scoped predecessors. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html
> It's not common lisp.
It is, but you're correct, it's not core of CL, it's from ruricolist/serapeum - a widely known CL lib.
It makes me feel very uncomfortable to say this - I don't want to appear presumptuous or patronising, but it honestly sounds almost like you have little or no clue about this.
LLMs are not about code generation. Code generation is almost like a side-effect and there are so many different things LLMs are really good at way before you get to even talk about code - gathering data by its semantic fingerprint; classification and routing where the boundary is fuzzy: is this a bug, a config error, or a support question; semantic diffing; reading stuff nobody will read: a 900-line helm file, a dependency tree, six months of changelogs, a vendor contract, etc.
If you have never dealt with cases where the input is messy and the matching criteria are impossible to write as rules, yes, of course it would feel like you don't even need LLMs. But pretty much any serious software does have plenty of those, and LLMs are incredibly good at that. Not only they are great - they are quite irreplaceable, in the sense that, yes, I won't die if I stop using the Internet, but any reason for choosing that path obviously must have some drastic rationale.
Feels good to find a perfect opportunity to be witty and snarky, yeah? Well, allow me to murder this vibe of yours. Titles do exist for a reason. This article's title specifically, assumes too much. It's nearly click-baity. Imagine a title like "Why does the Holocaust feel like a hoax?", and then it goes into intricate detail to prove it isn't. Some people still get triggered by the title alone.
What's interesting is that at the point when Clojure finally started feeling more intuitive and I was able to quickly scan the code snippets and understand the flow, it almost wondrously opened the gates for just about any Lisp. I can easily switch between Lisp dialects, as a matter of fact I can do it multiple times a day and the overhead is so tiny, it feels like I'm dealing with the same language, just on a different platform. It's by far the easiest language to deal with, be that Clojure, Clojurescript, ClojureDart, Fennel, Elisp, CL, Jank, Jolt, etc.
I think most programmers simply don't do that. They don't switch between different platforms (and thus languages) very often, they pick one or two, get proficient with them and build some loyalty or whatever, the language almost becomes their identity (at least at that point in their lives, until they find a new one).
And then the problem with Lisp dialects is that they are pretty niche - they are not so widely used in the industry, therefore the incentive to specifically learn Lisp is very moderate at best. But people hear stuff like "how expressive and powerful...", "Emacs has no competition", yada-yada and they'd try to spend a weekend to see what it is about, then look at the unfamiliar syntax and go like: "hmm, I don't know..." They try to learn kung fu but skip all "Mr. Miyagi's bullcrap". Alas, it just doesn't work that way.
For me, it was absolutely worth it. I think learning Clojure saved my career. At the time I was so overwhelmed with complexity in the apps I was trying to build and maintain. I started having an existential crisis - I thought about leaving the field for good and starting something else. Turns out, I wasn't a complete failure, I wasn't stupid, and I didn't lack incentive. I just needed a different perspective. And that "weirdness" and "uniqueness" of Lisp was that inflection point that I desperately needed in my life. Guess what? Becoming a Lisper helped me understand other languages much better.
I think I found a lifehack - want to become a polyglot programmer without wasting ten years of your life? Grok Lisp. It will do.
> Lexical binding was added to Common Lisp almost as an afterthought
Common Lisp was lexically scoped from day one. You're arguing about CL using Elisp's history.
And your "cumbersome and stupid" snippet is that, because, well you wrote it that way.
(local
(def user (find-user user-id))
(require-admin user)
(def report (build-report user))
(write-audit-log user report)
(def receipt (send-report report))
(record-delivery receipt))
Lisp is the language where you do whatever syntax is suitable for the task, yourself, in an afternoon. In Python you wait for a PEP.
Be careful, these statements are aging faster than milk. Most skeptics of even a few months ago suddenly got very quiet. New models are getting very advanced; the pace is stupefying. LLMs absolutely can and do write much better code today than the majority of senior software engineers, or at least at comparable levels. If you're not seeing that, you either aren't using the greatest models, your harness needs some work, or maybe you specialize in some very niche domains where LLMs are legitimately helpless.
So be it. It's fine. It will be fine. At some point I knew assembly well enough; I read hex fluently and confidently changed things directly in some random-looking files. This skill sometimes comes in handy (even today) when reading network packets. How many people today need to really understand offsets, field sizes and padding, so shit like: "bytes 12-13 are the EtherType" feels natural? What percentage of programmers actively creating software need to know how to read, say, exploit and malware traffic?
Some may say: "well, this is enormously important", but the reality is, "no, it's fucking not". For like 95% of programmers, it isn't.
And the number of programming languages I had to learn and then forget later... The point is - you don't need to be "thinking in a programming language". You just need to be thinking, period. Whatever language it will be tomorrow, it really doesn't matter. Cuneiform tablets with math still hold the math even though nobody in the world does any math in cuneiform anymore.
Technology has always been moving from lower abstractions to higher ones, and that's a normal cycle. Why is it so inconceivable to think that most of the software developers of tomorrow would have no idea how to "think" in Python, C++, Java, or Clojure? Does every car mechanic need to be able to explain the principles of a combustion engine?
When was the last time you built something meaningful with it? I admit, LLMs do help and save tons of time and effort, yet building noteworthy software still remains a difficult task, with or without LLMs.
Funny, but your comment reminded me of my wife. Circa 2009, she was walking behind my back, she stopped to watch me work without me noticing. I was using Visual Studio (sluggish, temperamental mammoth, not its smaller cousin). She stared at my screen for a few minutes and suddenly exclaimed: "You're not even working, this thing is telling you what to do. I could probably do this shit too..." By "this thing" she obviously meant the intellisense completion that was giving me hints whenever I typed.
Yes it can. org-babel-detangle copies edits you make in a tangled file back into the matching source blocks in the Org file. There's also `#+INCLUDE: "file.py" src python :lines "10-40"` and org-transclusion package - `#+transclude: [[file:foo.el::some-defun]] :src elisp` shows live content from an external file in the Org buffer.
Babel has no built-in way to import arbitrary existing files, but for the stuff that you make it make sense, it knows how to get its shit together back into one place.
That's just factually untrue. Emacs core is not obviously buggier than, let's say, VSCode, which has tens of thousands of open issues and is written in Typescript. What differs is visibility. Emacs throws a backtrace in your face; VSCode swallows extension errors into a log nobody reads. And every Emacs user runs a unique build with like 350 packages nobody tested together; try to even start VSCode with half that number of plugins.
The bugs that actually hurt in Emacs are state bugs, not type bugs. Two packages advise the same function. A buffer-local variable is set in one mode and read in another. Dynamic binding leaks. None of that is a type error in the Haskell sense.
The dynamism is the product, not an accident. Redefining any function at runtime, advising anything, inspecting live state - that is why people use Emacs instead of an editor with a plugin API. Strong static types plus separate compilation cut against late binding everywhere.
You're not "biased", you just seem to be unfamiliar with the type dynamism in Lisp systems. Dynamic types are not equally bad everywhere; don't take what you know about Python and apply it the same way to things built in, e.g., Clojure.
On Mac, I combined it with Flameshot to select a region, and Hammerspoon that watches the clipboard, so it always automatically OCRs anything I screenshot and pops into a buffer. On Linux I haven't spend time figuring out how to hook it up, so after the screenshot, I just have to manually call the command.
¹ https://github.com/agzam/.emacs.d/blob/main/modules/writing/...