One cool thing about Lisp is that you can easily embed new languages in it, and those languages can be small and beautiful. For example, I have a Python-esque FOR macro that uses an iterator protocol, and a universal binding macro that subsumes all of Common Lisp's binding constructs (LET, LET*, LABELS, FLET, MULTIPLE-VALUE-BIND, etc.) So for me, Common Lisp has actually shrunk without losing any functionality. This is not possible in languages without macros. Such languages are indeed doomed to either grow forever, or change in non-backwards-compatible ways (e.g. Python3). But with macros you can shrink a language as well as grow it. This is one of the reasons Common Lisp continues to thrive.<p>[UPDATE]: You can find my code here: <a href="https://github.com/rongarret/ergolib" rel="nofollow">https://github.com/rongarret/ergolib</a><p>Also, I forgot to mention another language-shrinker included in that library: REF. REF is a universal de-referencer that subsumes NTH, ELT, SLOT-VALUE, GETHASH and probably a few other things that I can't remember right now. It also lets you build abstract associative maps (a.k.a. dictionaries) with interchangeable implementations (see the DICTIONARY module), which lets you get rid of ASSOC and GETF.
There is a great book about Lisp from Christian Queinnec titled "Lisp in Small Pieces" or LISP. Here is a little excerpt from it.<p>"There are subjects treated here that can be appreciated only if you make an effort proportional to their innate difficulty. To harken back to something like the language of courtly love in medieval France, there are certain objects of our affection that reveal their beauty and charm only when we make a chivalrous but determined assault on their defenses; they remain impregnable if we don't lay siege to the fortress of their inherent complexity. In that respect, the study of programming languages is a discipline that demands the mastery of tools, such as the lambda calculus and denotational semantics. While the design of this book will gradually take you from one topic to another in an orderly and logical way, it can't eliminate all effort on your part."<p>Lisp has some of the best literature around of any programming language. Anybody who really cares about craft of programming should make use of wisdom therein.
It was painful watching Common Lisp happen; too many competing interests, and commercial stakes. Unfortunately languages went a different direction. (I also mourn Smalltalk's "loss", but Java had much more money coming into it.)<p>Lisp50 went into this somewhat (<a href="http://www.nhplace.com/kent/Papers/cl-untold-story.html" rel="nofollow">http://www.nhplace.com/kent/Papers/cl-untold-story.html</a>) and, unrelated, was a freakin' awesome good time. I sat next to Guy Steele for one talk but was too in awe to even say anything.<p>(Anecdote about same: I IMed a friend and said "I'm sitting next to Guy Steele" and he replied "Cool, ask him who Guy Steele is." Damn kids.
Though the 1994 ANSI standard is 1153 pages, Common Lisp somehow doesn't feel large. A lot of it is library pieces that can be understood more or less on their own and work independently. Somehow you can know the language well, without reading 1153 pages cover to cover. If you see anything in someone's code which is standard, but which you don't know well (or at all), it's not going to throw you a big curve ball.<p>C is a "small" language and is pushing 700 pages now.<p>Projects written using small languages tend to use lots of extensions. So do projects in larger languages, too; they use some subset of the core language, probably a small one, and then other libs which address problems not covered in the language at all.<p>How big is Perl? How much of CPAN should be included in that measurement? If the answer is "none", how realistic is that? Do you know Perl if you don't know any CPAN module?<p>How about Scheme? The base standard is small. But then there are SRFI's. It seems disingenuous not to count htem. And then there are implementations and their environments and extensions, which projects depend on. What better represents "Scheme size"? The R6RS document, or some measure of the size of, say, Racket?
In the case of Java it is not that Java is a "large language", it is that to get anything useful done with Java you need to know about Maven and Spring and Log4J and Apache Commons Logging and SLF4J (because if you're using a lot of libraries surely all of those will be in use.)<p>That is, it is the complexity of the ecosystem, not of the language.
I think lisp could benefit from a small core and building out a standard library. You could pack all the features it <i>needs</i> (packaging, lexical/dynamic scoping (defvar), let/lambda, defun/defmacro, multiple values (via values, multiple-value-call), setf (w/ setf expansion), simple arithmetic, declare/declaim/proclaim, maybe a few more) into the core and have standard libraries: cl.bind (multiple-value-..., defparameter, etc), cl.math (sin, cos, etc), cl.clos, cl.collections (arrays, hash tables), cl.io, etc etc.<p>I think this would clean things up a lot, still preserve the spec (aside from documenting what's in which libs), and make things more approachable.<p>Shoving everything into the "common-lisp" package <i>works</i> but it's cumbersome and you have to have the <i>entire language</i> sitting there to use anything.
I'm glad someone said this. I'm an occasional JavaScript programmer, and I looked over ES6 last night and was surprised by how large it's become. And I learned that ES7 is already on the way.<p>That said, most of the features seem nice, and many are borrowed from stable languages like Python, so perhaps it's not too much. I'll have to try it and see.<p>It made me wonder what Crockford is up to, and what he thinks of this.<p><a href="https://github.com/lukehoban/es6features" rel="nofollow">https://github.com/lukehoban/es6features</a><p><a href="http://es6-features.org/" rel="nofollow">http://es6-features.org/</a>
The plan for Common Lisp originally was to have a "core" and a standard library. From Daniel Weinreb's blog post "Complaints I’m Seeing About Common Lisp":<p><pre><code> It’s just too big. Actually, the real problem is that the core of the language is not cleanly separated from the built-in libraries. The Common Lisp designers had originally intended to do this separation, but there wasn’t time enough.
</code></pre>
<a href="https://web.archive.org/web/20100706204555/http://danweinreb.org/blog/complaints-im-seeing-about-common-lisp" rel="nofollow">https://web.archive.org/web/20100706204555/http://danweinreb...</a><p>(Daniel Weinreb was, among other things, one the designers of Common Lisp.)<p>Zach Beane has some more information on this at <a href="https://xach.livejournal.com/319717.html" rel="nofollow">https://xach.livejournal.com/319717.html</a><p>EDIT: "time enough", in the quote, may seem strange; after all, work began in 1984 and the standard was finalized in 1994. But remember that many stakeholders were companies with jobs to do, and they had to assign employees to the design/standardization work at real costs for said companies.
I like the author’s remarks and philosophy about keeping JavaScript small, but I thought the opening was remarkably uncharitable. The specific person and the specific feature are quite irrelevant to the point he’s making here.<p>I am left with some admiration for his goals, but also a great deal of trepidation about ever suggesting anything or even talking about JavScript.next. Will I be the next one called out by name if I make the mistake of asking whether traits might be a good addition to JavaScript?
Interestingly hardly anybody uses Algol, Smalltalk, Pascal and early Scheme anymore, while people still use Common Lisp. Perhaps "being small and beautiful" is actually a bad thing for a programming language?
I didn't realize that Scheme had become bloated. I haven't looked at it in years, and thought it was still the basic language described in SICP.
ECMAScript 6 is a shame, there's a lot of stuff added which is unnecessary.<p>"let" is unnecessary. JS now has two kinds of variable scoping! "var"'s hoisting is annoying, sure, but we don't need two kinds of variable scope. If you want to scope something to a block, you can just use an IIFE.<p>"class" is unnecessary at best. JavaScript has a bunch of ways of constructing objects to choose from, and that's not a problem. Why lock users into one paradigm, and obscure what's actually happening underneath? This will just confuse people when they have to deal with code that doesn't use "class" syntax or the OOP model it presents.<p>Object property shorthand is confusing. Why the hell is {bar} equivalent to {bar: bar}? Isn't that a set literal (Python, math)? Why isn't there the colon, if it's an object? What the hell? Try explaining that to newcomers.<p>Computed property names looks weird and is misleading. You'd logically expect {[1+1]:2} to be an object with an Array (coërced to string?) key, because [] is an Array literal. But instead it means "compute this expression". In which case, why isn't it ()? That's what you'd intuitively expect. I've tried to use () before and was surprised it didn't work, even.<p>Method properties, e.g. { foo(a,b) { ... } }, are unnecessary given => functions.<p>All that being said, I think ES6 has some quite positive additions. Maps, sets, tail-call elimination, =>, modules and symbols are all very important and useful features JavaScript really needed.
The common fallacy about simple languages.<p>Yes the language might be simple to understand, but then the result is the complexity lands in the shoulders of developers and an ever increasing library of workarounds to compensate for missing features.<p>Hence why every simple language that achieves mainstream use, ends up becoming like the ones it intended to replace.
My prespective could be very wrong but isn't this a sort of quality is in the eye of the beholder issue. I get building a silo isn't very beneficial to another. But isn't building monolithic library just as destructive. I don't think anything is perfect even if it's perfectly executed.
Python also suffering in this regard. It has moved from being "a language that fits in your head" to a language where very few people on the planet know most of what's in it.
You hear this "safe subset" thing about the syntax rich languages all the time and I really don't get it. I really do use all of C++. There are some pseudo deprecated bits and some extremely esoteric bits I don't hit, but beyond that I do wind up jogging most pieces of the language and standard library. Pretty much the same with my usage of perl. I've never written a source filter or a format, but otherwise I use a lot of the "niche" features regularly to great effect.<p>This whole sentiment comes from people who work on large rotating teams with enough inexperienced people, I guess? Sorry, learning a language properly takes a couple years or more. The features aren't wrong or bad, your team just doesn't know the tools well enough. You can't play modal jazz with the big boys until you can do your scales. I guess have fun doing your pop medleys with "simple" languages.
The Arc language (which runs this site) is a remarkable attempt to "fix" what went wrong with CL. It lacks a decent runtime and native code compiler (it offloads everything to mzscheme, the way clojure did to JRE) but it is already more than a proof of concept.<p>The problem is that there is no more DoD or other grants for creating new Lisps anymore (particularly due to Java mass hysteria and prevalence of packer's mentality).<p>BTW, making something similar to SBCL (everything written in itself, except for a tiny kernel written in C) for Arc (a core language, without the kitchen sink syndrome) is of moderate difficulty compared to meaningless piling up of more and more of Java crap.