To be pedantic, this isn't quite correct. Syntax isn't countable like that. What S-expressions are light on is production rules. At their most basic they have IIRC 7 production rules but there are absolutely 0 languages based on s-expressions which are that simple, since it doesn't give you anything like quasiquotes, vectors, Lisp 2 function resolution, etc. Reader macros make matters much worse.
What we can say is that they are constructively simple, but not particularly unique in that. Once you get into real sexpr languages they aren't simpler than horn clauses, and are constructively more complex than languages like Brainfuck and Forth.
It's repeated a lot because it's true. The collective developer world has decided that LISP syntax is not the preference. Good if you prefer it, but you're the in the overwhelming minority.
The key issue is that Lisp's minimal uniform syntax has less variation to help with visual pattern matching, which we humans are good at (compared to richer syntax).
The meta-programming power of Lisp may be largely due to being homoiconic, although Dylan/Julia etc achieve similar without it. However Lisp's minimal syntax is not a prerequisite for homoiconicity: S-Plus/R has a more conventional syntax while retaining "code is a list" representation.
minimal and simple is not the same thing as easy to use and natural/obvious.
what looks easier to read:
(if (< a b)
(let [x (long-function-name a b)]
(another-long-function (+ x c)))
(+ a b))
or
if a < b {
let x = long_function_name(a, b);
another_long_function(x + c)
} else {
a + b
}
to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read syntax" but theres also python, lua, kotlin, even js if you ignore strict/loose equals and weird casts. all of them use more procedural/c like syntax because its the natural way humans think about running an algorithm. theres a reason why pseudocode in every textbook looks like that.
I think by the same reasoning Qwerty keyboard is better than Dvorak. People are just used to Qwerty, although they would type faster on Dvorak, or in the case of s-expressions use structural editing.
> minimal and simple is not the same thing as easy to use and natural/obvious
You are right about that.
I value "minimal and simple" more than "familiar" because it makes my growth trajectory less arbitrary and more about intrinsic properties of the code. I don't care about learning how to do things the same way as everyone else nearly as much as I care about learning how code can be improved generally.
I know that code is written for humans, and that you can't remove the human from the equation. But I'm more interested in the future of code than in present-day code culture.
Honestly it's so exhausting. Every time Clojure gets mentioned on a broader forum, there's always some ridiculous claim that the Lispy syntax is "un-natural". Other Lisp dialects mostly pass unnoticed, but Clojure being more popular always causes some ruckus and I never get it - do people think that Clojurists stumble on it and be like: "holy mother of Alan Turing, this is so much more 'natural' to me than everything else..." Both choices are in the same sense "natural" as skiing and sledding. None of it is "natural" - reading prose in English, Thai or Katakana - all that is "unnatural". Nobody stumbles on the language and immediately thinks the syntax is just better - the majority of Clojurists come to it after years, often decades of using other PLs and they have to struggle at first.
Comparison with sledding is apt here, because both methods let you achieve the same goal - going down to the base of the mountain. Of course, skiing is more difficult to start with, it's more expensive, it requires deliberate effort and dedication. But the practical, learned experience far exceeds initial expectations. Do you realize how ridiculous it looks when inexperienced people try to convince them it's not worth it? Well, you may say, "the point is not to convince 'them', but to show the wider public..." And that's even more imbecilic. Imagine trying to point at people zigzagging 70 miles down from the peak, having enormous fun and telling the observers not to even try that? I'd dare anyone to argue with an experienced skier that sledding is more fun.
> theres a reason why pseudocode in every textbook looks like that.
Like I said, most - the absolute majority of Clojure programmers come to it after many years of programming in other languages (see the surveys). They are using it as a real instrument to achieve real goals, to solve practical problems. It's not an educational tool, not a "hello world app" incubator, not a "good for the resume" kind of a thing for them. If you (not you personally, but some proverbial programmer) are arguing just for the sake of it, well, with all respect, then "fuck you" (for wasting people's time). If you're sincerely trying to make a choice - nobody can "make a skier" out of you - that is something you must do on your own. No theory, no books, no videos can ever convey to you the enormous joy you may get out of it later - there's too much nontransferable tacit knowledge there. Just keep in mind, people in this community didn't make the choice because "their brains are wired differently" or something, not because "they are oblivious", no. Unlike you - they have seen, walked and lived through both of these worlds. Most of them have to switch between them, sometimes multiple times a day. And yes, the wider majority can often be wrong. In fact, history shows us that it makes wrong choices all the time. Lispers don't care about popular choices - they prioritize pragmatism above all.
I think this is kind of misleading. Yes s-expressions have very simple syntax in and of themselves. But s-expressions are not all that's required to get all the control structures in Clojure. You need to memorize all the special forms and all the standard macros that people use on a day to day basis. And they're just as hard (actually IME harder) to memorize as any other syntax. let, cond, record, if, condp, let-if, fn, def, defn, loop, recur, if-some, when-let, for, ->, ->>, as->>, cond-> ...
To this day I have to look up whenever I get back into clojure what the "syntax" is of ns, require, import, etc.
i can link you similarly undecipherable walls of text in rust and zig and c
but i bet if you sat down a junior developer not yet entrenched in any style yet, they'd be able to grok lisp code MUCH faster than the intricacies of syntax of the other alternatives ¯\_(ツ)_/¯
My opinion about this, is that it appears to depend on how a particular person's brain is wired, as to which language(s) they will understand faster and like. There can be a "winner" in terms of which language more people gravitate towards, but then that is very relative to many factors, including corporate influence.
People also put themselves into bubbles. Once in, they can filter out other languages (with all kinds of excuses), and be overly focused on certain families or only specific languages.
Kind of, but there are some subtle differences in my opinion. Oracle is top-to-bottom evil, whose business model basically boils down to screwing over their clients and everyone else at every possible opportunity, comparable to the likes of McKinsey or Accenture.
IBM is a bit more nuanced. My wife grew up in an IBM town and a lot of her family and her friends’ families used to work there in the 70s and 80s. People, especially the engineers, used to take pride in their work there.
I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.
Not to talk about the other side of the holy war too much, but one of the things I appreciate about GNU ELPA is it's treated as part of the Emacs distribution and needs to follow all the rules of Emacs proper as a result.
I believe we are thinking about different time horizons, and your language and comparison to <modern editor> reveals a lot about unsaid about your reasoning.
I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
What is 'over' is the idea that AI assisted coding is only hype that will go away. It is clear that software development is going to be different in ways we've not seen before.
Same tired argument from when compilers couldn't unroll a for loop, or from when photoshop was new. Did you think you would become that guy when you were young?
Today I faced an unexpected challenge in a high-pressure environment. I experienced a rapid loss of structural support (my trousers), which led to a complete pivot in my physical trajectory. I didn't just fall; I deep-dived into a new ecosystem (the toilet).
This experience taught me three things about resilience:
1. Always ensure your foundations are secure.
2. When you hit rock bottom, make sure it's a splash.
3. Failure is just an opportunity to wash off and start fresh.
Grateful for the growth. #Resilience #GrowthMindset #Agility #LessonsLearned
There are a few things I take away from this post:
1. If you care about the physical manifestation of a product, maybe Amazon.com is not the place to be shopping for it.
2. If the product as it arrives is substantially different from that ordered, it seems dishonest of the seller.
3. While the physical book is a source of joy for me as well, I feel lucky to live in a time where I can own a copy of a book that only a handful of people value, for a reasonable price.
He implied replacing nano was the first step, before using it for more complex (software development) tasks. First use it just for quick one-off edits of /etc/blah.conf then graduate to using it for longer editing sessions.
No, nano is not my daily driver. It's what I use when I want to quickly edit a file with root access because, funnily enough, I'm not in the habit of running my primary editor with superuser permissions :) Nano is a low-hanging fruit that was the first of many tools I gradually massaged the editor into replacing.
It's funny. When I have a topic I am interested and passionate about, and want to find an improvement or solution, I welcome the chance to have my ideas questioned. To explain them, to in turn question the alternatives others put forward.
In their frothing haste to put down my heresy here https://news.ycombinator.com/item?id=47307056, not one single commenter took just a second to understand what I actually wrote. Most of the responses aren't even coherent on their own, much less address my questions. I did not advocate for the status quo, I did not even assert OP was wrong. I invited them to provide some reasoning for their proposal. Quite troubling, even cultish behavior.
I try not to assume malice (i.e. Hanlon's Razor) when it happens to me. Unfortunately the mob rule seen on other user-curated sites seems to be infectious.
I try to gently call it out here when I see it, though, because HN is the one user-curated site where I still feel that people come to get to 'truths' versus 'agendas'. I want it to stay that way!
The syntax argument is such a tired argument. With LISPy language there is almost zero syntax, it's pretty much executable AST.
Because of this, formatting matters a lot, but I don't think that's too different than other languages.
If you think LISP is hard to read, you are someone who could most benefit from branching out to a non-Algol lineage language.
Also, the little syntax present is pretty much timeless. Learn once and its yours for the next 50 years.
reply