The Tragedy of the Common Lisp, Or, Why Large Languages Explode

144 点作者 error54将近 10 年前

20 条评论

lisper将近 10 年前

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.[UPDATE]: You can find my code here: <a href="https://github.com/rongarret/ergolib" rel="nofollow">https://github.com/rongarret/ergolib</a>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.

评论 #9741218 未加载

评论 #9741323 未加载

评论 #9743164 未加载

评论 #9743340 未加载

评论 #9741391 未加载

hydandata将近 10 年前

There is a great book about Lisp from Christian Queinnec titled "Lisp in Small Pieces" or LISP. Here is a little excerpt from it."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."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.

评论 #9743062 未加载

davelnewton将近 10 年前

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.)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.(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.

评论 #9741179 未加载

kazinator将近 10 年前

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.C is a "small" language and is pushing 700 pages now.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.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?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?

评论 #9745211 未加载

PaulHoule将近 10 年前

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.)That is, it is the complexity of the ecosystem, not of the language.

评论 #9741443 未加载

评论 #9741069 未加载

评论 #9742018 未加载

评论 #9741576 未加载

评论 #9741776 未加载

评论 #9741389 未加载

orthecreedence将近 10 年前

I think lisp could benefit from a small core and building out a standard library. You could pack all the features it needs (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.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.Shoving everything into the "common-lisp" package works but it's cumbersome and you have to have the entire language sitting there to use anything.

评论 #9740966 未加载

评论 #9741027 未加载

评论 #9741714 未加载

chubot将近 10 年前

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.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.It made me wonder what Crockford is up to, and what he thinks of this.<a href="https://github.com/lukehoban/es6features" rel="nofollow">https://github.com/lukehoban/es6features</a><a href="http://es6-features.org/" rel="nofollow">http://es6-features.org/</a>

评论 #9741989 未加载

评论 #9742872 未加载

评论 #9742951 未加载

评论 #9741644 未加载

gongador将近 10 年前

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":<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>(Daniel Weinreb was, among other things, one the designers of Common Lisp.)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>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.

braythwayt将近 10 年前

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.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?

评论 #9749285 未加载

Grue3将近 10 年前

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?

Animats将近 10 年前

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.

评论 #9741980 未加载

newuser88273将近 10 年前

Common Lisp actually has a core of a mere thirteen "special operators". You can think of everything else as standard library.

TazeTSchnitzel将近 10 年前

ECMAScript 6 is a shame, there's a lot of stuff added which is unnecessary."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."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.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.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.Method properties, e.g. { foo(a,b) { ... } }, are unnecessary given => functions.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.

评论 #9743627 未加载

评论 #9743268 未加载

pjmlp将近 10 年前

The common fallacy about simple languages.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.Hence why every simple language that achieves mainstream use, ends up becoming like the ones it intended to replace.

jaunkst将近 10 年前

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.

ericbb将近 10 年前

Here's a title for a rebuttal in case anybody wants to write it. ;)The Tragedy of ISLISP, Or, Why Small Languages Implode

upofadown将近 10 年前

Whenever I encounter people arguing about Python3 I am reminded that I still miss Python1.

raymondh将近 10 年前

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.

a8da6b0c91d将近 10 年前

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.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.

dschiptsov将近 10 年前

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.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).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.