6 ms·
I program multiple languages including Common Lisp. I don't buy that Common Lisp is too large. I would say the opposite is true. The base language is rather si
by lmilcin 5y ago
I program multiple languages including Common Lisp.
I don't buy that Common Lisp is too large. I would say the opposite is true. The base language is rather simple and what you mistake for language are just standard library.
What is complex is it being Lisp language which means you need to adjust your brain structure to a different level of functioning and focus when reading code.
**
But languages do get too large.
I think the reason languages get too large is because developers, as soon as they get some experience, start demanding more features. Maybe they want to have more functional experience in an object-oriented language, or maybe they want async in one that was not designed for it.
These developers form a core of users that enjoys being able to absorb these features over time as the language evolves.
On the other hand, new users need to learn it all at once.
There will come a point where new users will just look at horrendously complicated language with vast specification and will just say "Fuck it, I don't want to spend so much time to be able to do anything, I will program in this neat new other language that is simple to start and already has most of what I need."
- WalterBright 5y agoI lost count of the number of posts in the D language forums along the lines of "don't add any more features, just fix bugs. BTW, I need features X and Y, please implement them."
- cb321 5y agoThat made me crack up. Thanks for the morning smile. Priority variation is one thing, but boy oh boy..add lack of self-awareness and you have a pickle of a problem.
- lmilcin 5y agoThat's basically what is happening in Java, too. I have been programming Java for the past 20 years and I do enjoy new features. And I would like couple more features myself. But I am also tech lead for a lot of new developers which I see they struggle finding sense in what is going on with Java. Not just the language, but the multitude of frameworks and other paraphernalia supposedly needed to make a working modern application. Rather than trying to understand it they are giving up and revert to copying and pasting code that works. And wait for somebody with experience to catch obvious problems on code review. I think this is not sustainable.
- WalterBright 5y agoWe have an informal rule that every feature that starts with the words "Why not ..." gets rejected. New features need a justification for them. :-) Often, though, I just feel like Doctor No.
- lmilcin 5y agoHaha:) That's how I feel, too. I got new appreciation when it became my responsibility to care for productivity of a lot of people. Often people bring in new toys just to have some change in their work environment. I select for people who like to learn new things so why would I fault them for it? But I also see people don't understand how disruptive it is to productivity. People mostly see only gain side without seeing the outsize cost side of the problem. Even management doesn't seem to understand it. One time they brought me into large project that had trouble delivering and huge reliability problems and they told me my first priority problem is going to figure out how to upgrade Java from 1.6 to 11. My first question was "Why do you guys think it wasn't possible to deliver reliable applications with Java 1.6?"
- memling 5y ago> We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. I wonder how much language inertia can be overcome by surveying what's been implemented multiple times and ranking them. One imagines a very minimal language with multiple implementations, say, of asynchronous I/O or common data structures. Frequently-implemented features would be good candidates for thoughtful inclusion.
- lmilcin 5y agoThat language already exists and it is called *Lisp. In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library.
- fouric 5y agoI'm a Common Lisp user, and I would like to refine your claim. I don't think that many true "language features", like borrow checking and a static type system, can be implemented in a Lisp (without writing an entirely new language on top - Lisps are generally Turing complete, so you can always write an interpreter for another language on top, but I would claim that at that point you're not "extending your Lisp" so much as making a new one). Instead, what Lisps seem to excel at is allowing you to implement syntactic sugar. For instance, you can easily write CL macros that give you JSON/hashtable literal syntax, list comprehensions (pretend LOOP didn't exist), foo.bar to access struct elements, and infix notation - those things that people think of as being "part of the language" but don't give you any new capabilities (e.g. closures, a MOP, multiple-value returns, conditions).
- bitwize 5y ago> What is complex is it being Lisp language which means you need to adjust your brain structure to a different level of functioning and focus when reading code. "To be fair, you have to have a very high IQ to understand Common Lisp..."
- lmilcin 5y agoI think it has more to do with habits of the mind. You need to be willing to explore and be inquisitive. You need to be able to read more difficult books (than entry level) like Let over Lambda or On Lisp and try to understand every sentence and every example and not just the superficial side but also as questions like why this way, when this is useful, what are limits on application, etc. I guess intelligence correlates but I know a lot of very intelligent people who are too lazy to be bothered to understand things deeply. It would be fair to say you need at least some IQ to be able to do this. Probably about 100-110 is a limit below which people just are not able to understand complex abstractions (which is a little scary if you think about it, because that is over half of the population). But I wouldn't say you need to be very intelligent (like 140 and upwards).
- mbrodersen 5y agoNope not at all. Learning Lisp/Common Lisp/Scheme was easy for me. However learning Haskell was hard. Things are hard to learn when you have to change how you think to understand it. I know people who are good at Haskell but crap at writing C. It has nothing to do with IQ.
- at_a_remove 5y agoPython is heading this way (among other problems with the whol shebang). "We had X in this language Y, so add feature X." Why leave a language if it had the features you wanted? And if you left it, why import the problems you tried to leave behind?
- BeFlatXIII 5y agoWhat are some of your other problems with Python?
- dragonwriter 5y ago> Python is heading this way (among other problems with the whol shebang). "We had X in this language Y, so add feature X." Why leave a language if it had the features you wanted? Because you can't switch languages in a system for each feature, so if you want features A, B, C, D, and E, and the subset (A,B,C,D) has more value than (D,E), the language that has A,B,C,D will be preferred to the one with D,E, but you’ll still want to add E.
- foobarian 5y ago> What is complex is it being Lisp language which means you need to adjust your brain structure to a different level of functioning and focus when reading code. Even if you do get proficient at this, there is still the problem that reading CL is not enough - it's CL + custom macro/DSL systems per project. Given a bunch of different projects and teams in an org, moving people around is easier with other languages because that second part tends to be less complicated. We have one team that decided to go all in on customizing the common frameworks, inventing their own with bespoke annotations and patterns so now they are basically isolated from the rest of the org and others dread working on projects that involve changes in that codebase.
- fouric 5y ago> it's CL + custom macro/DSL systems per project How is this any different from building an overly convoluted architecture in any other language where you have layers upon layers of objects, getters, setters, proxys, callbacks, VisitorFactoryFactory's, configuration files, multi-level build systems, virtual methods, type system hacks, generic functions? I've been programming in CL for years now, and I have more of a problem keeping my non-macro code from spiraling out of control than my macros. What makes macros any more than just a thing you have to exercise discipline with, like "normal" code?
- lmilcin 5y ago> Even if you do get proficient at this, there is still the problem that reading CL is not enough - it's CL + custom macro/DSL systems per project. That is true and expected. Because if you "got" CL it means you start any larger application by writing a perfect language in which to write that application. But with power comes responsibility. And this is where a lot of Lisp projects fall short. It is much more difficult to make a mess in a poor language like Java where you can basically ctrl-c/ctrl-v your solution than it is in super powerful language like Lisp that gives you no guidance on how to structure your application. Especially if you also have intelligent people on the project. Because intelligent people can make even more complicated constructs with which to shoot their feet. I wish every CL project had one guy with a long beard that can bring wisdom on how to deal with an infinite power of Lisp.