12 ms·

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

144 points by error54 11y ago

raymondh 11y ago
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.
deleted 11y ago
[deleted]
a8da6b0c91d 11y ago
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.
PaulHoule 11y ago
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.
- sbilstein 11y ago
  I think this is a very fair way to characterize Java's problems. The syntax is annoying but generally let's you get tons of shit done in a reasonable matter. It lacks the features of a stronger type system like Haskell or Scala, but you can get pretty far. The ecosystem on the other hand can be totally befuddling, maven, gradle, the dozen or so DI frameworks and the various codebases that seem to use all of them, choosing between Apache or Google Java libs (or both!), etc. Scala on the other hand suffers from an explosion of language features that means you either get a ton of shit done because you love Scala or you get nothing done. I'm not sure which is better anymore since I work in both on a daily basis but it's a different tradeoff.
  - edwinnathaniel 11y ago
    > The syntax is annoying That's a matter of perspective no? I'm not fond of symbols so reading Ruby super-terse code makes me choose watching a movie on Netflix over that. > The ecosystem on the other hand can be totally befuddling You mean slightly better than Python that keeps re-inventing the (half) wheel? :D Maven is used by the majority projects with Android projects as an exception because Google pushed hard for Gradle. For DI frameworks: Spring is the majority winner with Guice/CDI on the second place. Apache vs Google Guava only because Guava came in late and both are just a nice small library (not a framework). Older code within the codebase might have already used Apache Common lib and newer code within the _same_ codebase will more likely use Guava where it is fit (I/O is an area where Apache has better library). We should also compare this situation with various Auth & Auth lib for Rails/NodeJS project :). So shrug ... Java has been around longer, at most usually there are 2 competing libraries for certain area and the better ones tend to win (again, depend on your perspective what "better" means: some prefer Maven over Gradle).
  - bad_user 11y ago
    > Scala on the other hand suffers from an explosion of language features This isn't what I feel. Scala's feature set is small, but powerful. Some examples: - Scala has no notion of static methods, unlike Java. Every reference or value is an object, every function call is a method call, with Scala's OOP being much, much closer to Smalltalk than any of the C++ inspired bastardizations tend to be - Scala doesn't have special syntax for certain types, like Java's plus operator for Strings - Scala's support for variance is much simpler and at the same time more powerful than Java's use-site variance by means of wildcards (I've met no Java developer that can tame Java's wildcards, I'm sure they are out there, I just haven't met them) - speaking of variance, Scala's type-system has Null and Nothing and AnyVal and Unit; in Java you've got "void" as a special construct, in Java the primitives are special, in Java "null" has special and unexplained treatment, in Java Nothing is surely there somewhere in the implementation, but you can't use it ;-) - Scala-async is a library, instead of a language feature like in C# - Slick is a library, instead of a language feature like Linq in C# - Scala's for comprehensions are much more general purpose than the foreach construct in Java, or than for comprehensions in Python, which means that Scala doesn't need new constructs for dealing with async stuff or with (god forbid) monads - Scala's traits are much better and I might say easier to understand than Java 8's default interface methods - Scala does not have side-effecting keywords such as break or continue - Scala does not have the special indexing syntax of arrays - Scala does not have special syntax for building arrays or maps, as the basic language is enough for doing that in an expressive way - Scala does not have operator overloading, or operators for that matter; as in Scala the operators are just plain methods And then indeed, we can talk about things like pattern matching or case classes, which in my opinion add tremendous value. But you know, static languages need features in order to be usable / expressive and cannot be minimal in the way that Scheme or Smalltalk are. For example people complain about implicit parameters, however implicit parameters happen anyway in any language (e.g. undocumented dependencies, singletons) and at the very least in Scala you can document those dependencies in the function's or the constructor's signature and have it statically type-checked and overridable. Plus implicit parameters allow one to work with type-classes and compared to Haskell, in Scala a type-class is just a plain interface and its implementation is just a value. And also the CanBuildFrom pattern is not a type-class and isn't possible in Haskell. So such a small feature such as implicit parameters yields tremendous power. I could probably go on, just wanted to point out that Java's simplicity and at the same time Scala's complexity is entirely misleading. And also, I happened to introduce many rookies to Scala and by far the biggest hurdles are posed by exposure to new concepts or design patterns, brought by functional programming of course. Even explaining Future is problematic, a standard library thing that otherwise leaked into Java and many other languages as well.
- falcolas 11y ago
  When I was learning Java recently in anticipation of a job programming Java - I was surprised by this reality. The core of Java is remarkably simple to learn - there's not really all that much to it. The complexity is indeed in all of the libraries and build frameworks and well intentioned but silly HammerFactoryFactoryFactoryFactories.
  - zorked 11y ago
    Java, or, how "software engineering" can kill a decent enough language with incredible complexity.
    - collyw 11y ago
      "software over-engineering"
    - jimktrains2 11y ago
      I blame a lot of that on the type system. It's almost very nice, but in such a way that make compensating for the almost very painful.
  - jerf 11y ago
    I think the case can be made that Java was too simple. It's inability to express very much within itself is what led to explosion of external tools to make it "better", or indeed, "work". I think it was deliberately designed as a simple language to be used by large groups of people in simple ways, but actually failed so epically at that goal because of being too simple that it actually destroyed the entire idea of building a language deliberately for large corporate use. (Note that it has grown a lot since then; it had to.) Go's the first language I've seen since Java try for that niche. I've said it before: In the short term Go may be stealing from Python and Node, but in the long term, Java's the one that needs to be worried about Go. Edit: Literally six minutes later, my feeds produce for me: http://www.businessinsider.com/google-go-update-from-jason-burberel-2015-6 http://www.businessinsider.com/google-go-update-from-jason-b...
    - davelnewton 11y ago
- oconnor0 11y ago
  That may have used to be true, but with every release of Java the language and standard library grows. More features means simplicity is lost, and Java is huge.
  - spiralpolitik 11y ago
    The language hasn't changed very much since inception. Java 8 was probably the biggest of the changes with Lambdas. But even so Java 8 looks a lot like Java 1 at the language level. The standard library has always been bloated. Hopefully Java 9 and Project Jigsaw will break it up into smaller manageable trunks. Really a lot of it needs to be burned away for new stuff to grow. The tough part for Java will be when they have to break backwards compatibility to move the language and VM forward. If not done careful they will have another Python 3 on their hands.
- javajosh 11y ago
  Yes, it's a problem I call the Java Jungle - and it's something that happens (and will happen) to every successful language, I believe. Therefore it's not enough to ditch it and start again - devs need to figure out how to manage complex communities and library/architecture options. Although I'm not entirely convinced Java is going to be the one that really figures it out. It's probably Node or Go or Rust that will finally get it right (they already get it right tacitly acknowledging that it's okay to couple to linux, therefore it's okay to be native, and that the correct unit of deployment is the whole damn server image.)
  - javajosh 11y ago
    You know if you're going to downvote, the least you can do is respond and say what you think is wrong. Otherwise, you're just being a jerk.
    - kweinber 11y ago
      +1... We could have learned something from a response.
- jdmichal 11y ago
  I would agree with you, except there's no way to fit type erasure into that sentiment. Type erasure is a complex solution to an easy problem, done purely out of laziness and a broken sense of what "backwards compatible" should mean. The moment you try to do anything "interesting" with generics, you realize the sham that they are and start passing around `Class<T>`, which is exactly what you would have done before generics anyway.
  - fithisux 11y ago
    Type erasure kills the language. Otherwise, it would have a bright future.
- edwinnathaniel 11y ago
  Isn't that the same with _any_ ecosystem? Ruby => Rails (most of the time...) Python => Django NodeJS => ExpressJS Ruby => RubyGems + Rake + Bundler Python => (finally something ... static) pip NodeJS => NPM Browser JS => Bower NodeJS tries to be as simple as possible but at the end of the day, you need to use/download/learn libraries with different quality/documentation level and different API-feel/code-style.
  - serve_yay 11y ago
    > Isn't that the same with _any_ ecosystem? It is!
    - reilly3000 11y ago
      Except it isn't. Attributes of languages include their documentation syntax and extension API. Getting this right makes a remarkable difference for how easily a person can grok a new library or extension and make it useful. A good language has a common "language" overall, not just code syntax.
      - bshanks 11y ago
        Which language(s) do you think do a particularly good job of documentation syntax and extension API?
  - lmm 11y ago
    Java libraries tend to have "magic" that alters the language semantics. E.g. Spring's dependency injection breaks your reasoning about how an object is constructed. Hibernate breaks your reasoning about when object fields can change. Tapestry breaks your reasoning about basically everything. There's a difference between a library that follows the rules of the language and a framework that changes them. (admittedly to a certain extent I've heard the same said of rails)
orthecreedence 11y ago
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.
- tjr 11y ago
  I don't have the exact quote/source right here handy, but I believe that was Guy Steele's intention with Scheme.
  - Jtsummers 11y ago
    https://en.wikipedia.org/wiki/Scheme_(programming_language)#R6RS https://en.wikipedia.org/wiki/Scheme_(programming_language)#... This was a concept for R6RS (not sure what happened, apparently some controversy with it) and R7RS has (attempted? succeeded?) in going in this direction.
    - duaneb 11y ago
      IIRC R6RS was deemed too modular for not much reason while abandoning backwards compatibility. Thus, R7RS was split into small/large specs, and largely builds on R5RS.
      - bitwize 11y ago
        R6RS was the systemd of language standards. It went against the very philosophy of the language it purported to standardize, and was basically a prescriptive standard based on a few influential individuals' notion of what Scheme "should" be. That's another reason why I remain unswayed in my detestation for systemd: I'd seen this movie before and I don't like how it ends.
lisper 11y ago
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: https://github.com/rongarret/ergolib https://github.com/rongarret/ergolib 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.
- collyw 11y ago
  I don't know Lisp, so correct me if I am wrong. The whole idea of embedding your own language sound pretty much the same as a growing the language, except that you are doing it yourself, in a non standard way.
  - agumonkey 11y ago
    The 'standard' thing is both a gift and an issue. You're free to fulfill your needs, but everyone will do so. The community needs to be mature and sensitive, sharing good ideas, not building silos.
    - ZenoArrow 11y ago
      Both rigidly defined and flexibly defined languages appear to have their issues. I'm not much of a historian of Lisp but my basic understanding is that it's great for lone developers, but a pain for larger teams, and the flexibility of the language is the reason behind both of these. In the Go language the tool gofmt formats the source code to certain standards. I haven't heard a single developer complain about gofmt, developers seem to appreciate that it takes away the bikeshedding over style, there's one established way to lay out your Go code and that's to use gofmt. Now if bikeshedding can happen over something as trivial as code layout, imagine what's going to happen if you make it trivial to change the language. Someone didn't design a regex library the way you like it? Code your own. So will everyone else. You end up with thousands of developers reinventing the wheel, all building their own versions of the same thing, that aren't necessarily compatible. CL now has its own package manager (Quicklisp), I'd be curious to know if this has had an impact on fragmentation, that's CL's best bet for reestablishing itself as a language that's growing in use.
davelnewton 11y ago
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 (http://www.nhplace.com/kent/Papers/cl-untold-story.html http://www.nhplace.com/kent/Papers/cl-untold-story.html) 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.
- lukego 11y ago
  I really did not enjoy Lisp50. I was surprised to discover such a disconnect between the old-school and new-school Lispers. Guy Steele and co really didn't seem to have any interest at all in what people have done with Common Lisp these past 20 years or so. That is a pity because I had always really valued the perceived continuity of the Lisp community.
  - davelnewton 11y ago
    I think Clojure's reception was great--the oldies, overall, were very positive.
    - lukego 11y ago
      Agreed. That was classy. But that is also a sign of them having no interest in the modern Common Lisp community :).
      - davelnewton 11y ago
        I read it differently; I think they thought it was an interesting direction, but only that, another direction. The oldbies are pretty CL-oriented, although obviously many of them have moved on (e.g., Fortress for GLS).
chubot 11y ago
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. https://github.com/lukehoban/es6features https://github.com/lukehoban/es6features http://es6-features.org/ http://es6-features.org/
- mkozlows 11y ago
  Yeah, I share the linked author's opinion of ES6 -- it's good stuff, but it's also a dangerous direction. Part of me thinks that maybe what's needed is an updated version of "use strict" -- "use es6" or whatever -- that would let you use the new features, but also prevent you from using some deprecated features, to keep the surface of the language somewhat smaller even as new stuff gets added.
  - fithisux 11y ago
    For many years I was fiercely against ES. With ES6 I start to change. Your suggestion make sense and I applaud it. Something like "use strict es6" would make our lives easier. Backwards incompatibility here has a goal.
  - dangoor 11y ago
    That was seriously considered some years back and thrown out as likely to cause poor adoption and poor intermingling of language features. http://www.2ality.com/2014/12/one-javascript.html http://www.2ality.com/2014/12/one-javascript.html
- serve_yay 11y ago
  https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 :)
- warfangle 11y ago
  It's expanding the language, but adding such sorely needed features. I've been working in it for a little while now, and egads is it painful to go back. Block scoping, arrow functions, and destructured assignments are all a godsend.
upofadown 11y ago
Whenever I encounter people arguing about Python3 I am reminded that I still miss Python1.
Animats 11y ago
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.
- hga 11y ago
  See now the R7RS which is split into a small and large standard (the latter still in progress). R6RS was largely ignored by the community, and there wasn't huge growth prior to it.
hydandata 11y ago
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.
- mkramlich 11y ago
  seeing this comment on HN, made my PG, a Lisp book author, is amusing. I have to admit that while I don't do Lisp day-to-day probably my favorite Lisp book(s) were written by him. The practical hacker in me prefers Python, Java and C. But the elegant hacker in me? Prefers Lisp. And PG captured that in his writing.
  - PuercoPop 11y ago
    IDK where the elegant but impractical (as it was a trade off). CL is a practical language. Consider loop, format, multiple values or the standard methd combination in CL. While the only practical thing about python is that it has more libraries. Nevermind the fact that python scope is misdesigned even in Python 3!
kazinator 11y ago
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?
- realityking 11y ago
  I think the post was more about syntax, not standard library. Functions and methods are reasonable easy to lookup, syntax much less so. Also try googling for some unknown syntax.
  - kazinator 11y ago
    > I think the post was more about syntax, not standard library If that is so, it has no point. The bulk of the 1153 pages of the Common Lisp standard is in fact describing a standard library, so if the definition of "large language" is one that has a large core syntax, excluding standard library, then it's a small language, in fact. Most of the syntax of a typical Lisp dialect (Common Lisp included) takes the form of a standard library. If you seen an unfamiliar syntax, it consists of a form with an unfamiliar symbol in the leftmost position: (unfamiliar-symbol ... stuff (you (do not)) understand) You search your help resources for "unfamiliar-symbol". The lexical syntax ("read syntax" in Lisp terms) is quite very small. It consists of elements like what constitutes a symbol token, what numeric and other constants look like, and other such elements. Stuff like: #(this is a vector) #c(3.0 4.0) ;; complex number 3.0i + 4.0. `(quasi ,quote) '(quoted list) package::symbol
pg_is_a_butt 11y ago
what a joke of a response. no, because no, and if it's yes, i'll employ murder. why? because new things mean too many things... ALWAYS. no to everything. let yourself get fucked;
jaunkst 11y ago
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 11y ago
Here's a title for a rebuttal in case anybody wants to write it. ;) The Tragedy of ISLISP, Or, Why Small Languages Implode
braythwayt 11y ago
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?
- inglor 11y ago
  For what it's worth - the authors know each other from before and knowing both parties Mark did not intend to mean any offense.
  - braythwayt 11y ago
    I came back to note that Mark has subsequently clarified that he meant absolutely no slight against Kyle. He is a gentleman.
gongador 11y ago
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": 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. https://web.archive.org/web/20100706204555/http://danweinreb.org/blog/complaints-im-seeing-about-common-lisp https://web.archive.org/web/20100706204555/http://danweinreb... (Daniel Weinreb was, among other things, one the designers of Common Lisp.) Zach Beane has some more information on this at https://xach.livejournal.com/319717.html https://xach.livejournal.com/319717.html 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.
TazeTSchnitzel 11y ago
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.
- benaston 11y ago
  I think the jury is still out on `class`. I can say that `class` is somewhat "dishonest" both the sense that it makes the language more complicated, under a guise of simplification; and in the sense that it lures developers from classical languages into thinking that JavaScript has classes in the same manner, when `class` in JS is just sugar.
  - phpnode 11y ago
    I see this line of thinking a lot and I think it's a mistake. Are classes in other languages consistent with each other? Clearly not, so why is this distinction made here? ES6 classes ARE classes, it's not just sugar, that is what they are.
    - 11y ago
dschiptsov 11y ago
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.
pjmlp 11y ago
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.
newuser88273 11y ago
Common Lisp actually has a core of a mere thirteen "special operators". You can think of everything else as standard library.
Grue3 11y ago
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?

144 points by error54 11y ago

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.

deleted 11y ago

[deleted]

a8da6b0c91d 11y ago

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.

PaulHoule 11y ago

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.

sbilstein 11y ago
I think this is a very fair way to characterize Java's problems. The syntax is annoying but generally let's you get tons of shit done in a reasonable matter. It lacks the features of a stronger type system like Haskell or Scala, but you can get pretty far. The ecosystem on the other hand can be totally befuddling, maven, gradle, the dozen or so DI frameworks and the various codebases that seem to use all of them, choosing between Apache or Google Java libs (or both!), etc. Scala on the other hand suffers from an explosion of language features that means you either get a ton of shit done because you love Scala or you get nothing done. I'm not sure which is better anymore since I work in both on a daily basis but it's a different tradeoff.
- edwinnathaniel 11y ago
  > The syntax is annoying That's a matter of perspective no? I'm not fond of symbols so reading Ruby super-terse code makes me choose watching a movie on Netflix over that. > The ecosystem on the other hand can be totally befuddling You mean slightly better than Python that keeps re-inventing the (half) wheel? :D Maven is used by the majority projects with Android projects as an exception because Google pushed hard for Gradle. For DI frameworks: Spring is the majority winner with Guice/CDI on the second place. Apache vs Google Guava only because Guava came in late and both are just a nice small library (not a framework). Older code within the codebase might have already used Apache Common lib and newer code within the _same_ codebase will more likely use Guava where it is fit (I/O is an area where Apache has better library). We should also compare this situation with various Auth & Auth lib for Rails/NodeJS project :). So shrug ... Java has been around longer, at most usually there are 2 competing libraries for certain area and the better ones tend to win (again, depend on your perspective what "better" means: some prefer Maven over Gradle).
- bad_user 11y ago
  > Scala on the other hand suffers from an explosion of language features This isn't what I feel. Scala's feature set is small, but powerful. Some examples: - Scala has no notion of static methods, unlike Java. Every reference or value is an object, every function call is a method call, with Scala's OOP being much, much closer to Smalltalk than any of the C++ inspired bastardizations tend to be - Scala doesn't have special syntax for certain types, like Java's plus operator for Strings - Scala's support for variance is much simpler and at the same time more powerful than Java's use-site variance by means of wildcards (I've met no Java developer that can tame Java's wildcards, I'm sure they are out there, I just haven't met them) - speaking of variance, Scala's type-system has Null and Nothing and AnyVal and Unit; in Java you've got "void" as a special construct, in Java the primitives are special, in Java "null" has special and unexplained treatment, in Java Nothing is surely there somewhere in the implementation, but you can't use it ;-) - Scala-async is a library, instead of a language feature like in C# - Slick is a library, instead of a language feature like Linq in C# - Scala's for comprehensions are much more general purpose than the foreach construct in Java, or than for comprehensions in Python, which means that Scala doesn't need new constructs for dealing with async stuff or with (god forbid) monads - Scala's traits are much better and I might say easier to understand than Java 8's default interface methods - Scala does not have side-effecting keywords such as break or continue - Scala does not have the special indexing syntax of arrays - Scala does not have special syntax for building arrays or maps, as the basic language is enough for doing that in an expressive way - Scala does not have operator overloading, or operators for that matter; as in Scala the operators are just plain methods And then indeed, we can talk about things like pattern matching or case classes, which in my opinion add tremendous value. But you know, static languages need features in order to be usable / expressive and cannot be minimal in the way that Scheme or Smalltalk are. For example people complain about implicit parameters, however implicit parameters happen anyway in any language (e.g. undocumented dependencies, singletons) and at the very least in Scala you can document those dependencies in the function's or the constructor's signature and have it statically type-checked and overridable. Plus implicit parameters allow one to work with type-classes and compared to Haskell, in Scala a type-class is just a plain interface and its implementation is just a value. And also the CanBuildFrom pattern is not a type-class and isn't possible in Haskell. So such a small feature such as implicit parameters yields tremendous power. I could probably go on, just wanted to point out that Java's simplicity and at the same time Scala's complexity is entirely misleading. And also, I happened to introduce many rookies to Scala and by far the biggest hurdles are posed by exposure to new concepts or design patterns, brought by functional programming of course. Even explaining Future is problematic, a standard library thing that otherwise leaked into Java and many other languages as well.
falcolas 11y ago
When I was learning Java recently in anticipation of a job programming Java - I was surprised by this reality. The core of Java is remarkably simple to learn - there's not really all that much to it. The complexity is indeed in all of the libraries and build frameworks and well intentioned but silly HammerFactoryFactoryFactoryFactories.
- zorked 11y ago
  Java, or, how "software engineering" can kill a decent enough language with incredible complexity.
  - collyw 11y ago
    "software over-engineering"
  - jimktrains2 11y ago
    I blame a lot of that on the type system. It's almost very nice, but in such a way that make compensating for the almost very painful.
- jerf 11y ago
  I think the case can be made that Java was too simple. It's inability to express very much within itself is what led to explosion of external tools to make it "better", or indeed, "work". I think it was deliberately designed as a simple language to be used by large groups of people in simple ways, but actually failed so epically at that goal because of being too simple that it actually destroyed the entire idea of building a language deliberately for large corporate use. (Note that it has grown a lot since then; it had to.) Go's the first language I've seen since Java try for that niche. I've said it before: In the short term Go may be stealing from Python and Node, but in the long term, Java's the one that needs to be worried about Go. Edit: Literally six minutes later, my feeds produce for me: http://www.businessinsider.com/google-go-update-from-jason-burberel-2015-6 http://www.businessinsider.com/google-go-update-from-jason-b...
  - davelnewton 11y ago
oconnor0 11y ago
That may have used to be true, but with every release of Java the language and standard library grows. More features means simplicity is lost, and Java is huge.
- spiralpolitik 11y ago
  The language hasn't changed very much since inception. Java 8 was probably the biggest of the changes with Lambdas. But even so Java 8 looks a lot like Java 1 at the language level. The standard library has always been bloated. Hopefully Java 9 and Project Jigsaw will break it up into smaller manageable trunks. Really a lot of it needs to be burned away for new stuff to grow. The tough part for Java will be when they have to break backwards compatibility to move the language and VM forward. If not done careful they will have another Python 3 on their hands.
javajosh 11y ago
Yes, it's a problem I call the Java Jungle - and it's something that happens (and will happen) to every successful language, I believe. Therefore it's not enough to ditch it and start again - devs need to figure out how to manage complex communities and library/architecture options. Although I'm not entirely convinced Java is going to be the one that really figures it out. It's probably Node or Go or Rust that will finally get it right (they already get it right tacitly acknowledging that it's okay to couple to linux, therefore it's okay to be native, and that the correct unit of deployment is the whole damn server image.)
- javajosh 11y ago
  You know if you're going to downvote, the least you can do is respond and say what you think is wrong. Otherwise, you're just being a jerk.
  - kweinber 11y ago
    +1... We could have learned something from a response.
jdmichal 11y ago
I would agree with you, except there's no way to fit type erasure into that sentiment. Type erasure is a complex solution to an easy problem, done purely out of laziness and a broken sense of what "backwards compatible" should mean. The moment you try to do anything "interesting" with generics, you realize the sham that they are and start passing around `Class<T>`, which is exactly what you would have done before generics anyway.
- fithisux 11y ago
  Type erasure kills the language. Otherwise, it would have a bright future.
edwinnathaniel 11y ago
Isn't that the same with _any_ ecosystem? Ruby => Rails (most of the time...) Python => Django NodeJS => ExpressJS Ruby => RubyGems + Rake + Bundler Python => (finally something ... static) pip NodeJS => NPM Browser JS => Bower NodeJS tries to be as simple as possible but at the end of the day, you need to use/download/learn libraries with different quality/documentation level and different API-feel/code-style.
- serve_yay 11y ago
  > Isn't that the same with _any_ ecosystem? It is!
  - reilly3000 11y ago
    Except it isn't. Attributes of languages include their documentation syntax and extension API. Getting this right makes a remarkable difference for how easily a person can grok a new library or extension and make it useful. A good language has a common "language" overall, not just code syntax.
    - bshanks 11y ago
      Which language(s) do you think do a particularly good job of documentation syntax and extension API?
- lmm 11y ago
  Java libraries tend to have "magic" that alters the language semantics. E.g. Spring's dependency injection breaks your reasoning about how an object is constructed. Hibernate breaks your reasoning about when object fields can change. Tapestry breaks your reasoning about basically everything. There's a difference between a library that follows the rules of the language and a framework that changes them. (admittedly to a certain extent I've heard the same said of rails)

orthecreedence 11y ago

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.

tjr 11y ago
I don't have the exact quote/source right here handy, but I believe that was Guy Steele's intention with Scheme.
- Jtsummers 11y ago
  https://en.wikipedia.org/wiki/Scheme_(programming_language)#R6RS https://en.wikipedia.org/wiki/Scheme_(programming_language)#... This was a concept for R6RS (not sure what happened, apparently some controversy with it) and R7RS has (attempted? succeeded?) in going in this direction.
  - duaneb 11y ago
    IIRC R6RS was deemed too modular for not much reason while abandoning backwards compatibility. Thus, R7RS was split into small/large specs, and largely builds on R5RS.
    - bitwize 11y ago
      R6RS was the systemd of language standards. It went against the very philosophy of the language it purported to standardize, and was basically a prescriptive standard based on a few influential individuals' notion of what Scheme "should" be. That's another reason why I remain unswayed in my detestation for systemd: I'd seen this movie before and I don't like how it ends.

lisper 11y ago

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: https://github.com/rongarret/ergolib https://github.com/rongarret/ergolib 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.

collyw 11y ago
I don't know Lisp, so correct me if I am wrong. The whole idea of embedding your own language sound pretty much the same as a growing the language, except that you are doing it yourself, in a non standard way.
- agumonkey 11y ago
  The 'standard' thing is both a gift and an issue. You're free to fulfill your needs, but everyone will do so. The community needs to be mature and sensitive, sharing good ideas, not building silos.
  - ZenoArrow 11y ago
    Both rigidly defined and flexibly defined languages appear to have their issues. I'm not much of a historian of Lisp but my basic understanding is that it's great for lone developers, but a pain for larger teams, and the flexibility of the language is the reason behind both of these. In the Go language the tool gofmt formats the source code to certain standards. I haven't heard a single developer complain about gofmt, developers seem to appreciate that it takes away the bikeshedding over style, there's one established way to lay out your Go code and that's to use gofmt. Now if bikeshedding can happen over something as trivial as code layout, imagine what's going to happen if you make it trivial to change the language. Someone didn't design a regex library the way you like it? Code your own. So will everyone else. You end up with thousands of developers reinventing the wheel, all building their own versions of the same thing, that aren't necessarily compatible. CL now has its own package manager (Quicklisp), I'd be curious to know if this has had an impact on fragmentation, that's CL's best bet for reestablishing itself as a language that's growing in use.

davelnewton 11y ago

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 (http://www.nhplace.com/kent/Papers/cl-untold-story.html http://www.nhplace.com/kent/Papers/cl-untold-story.html) 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.

lukego 11y ago
I really did not enjoy Lisp50. I was surprised to discover such a disconnect between the old-school and new-school Lispers. Guy Steele and co really didn't seem to have any interest at all in what people have done with Common Lisp these past 20 years or so. That is a pity because I had always really valued the perceived continuity of the Lisp community.
- davelnewton 11y ago
  I think Clojure's reception was great--the oldies, overall, were very positive.
  - lukego 11y ago
    Agreed. That was classy. But that is also a sign of them having no interest in the modern Common Lisp community :).
    - davelnewton 11y ago
      I read it differently; I think they thought it was an interesting direction, but only that, another direction. The oldbies are pretty CL-oriented, although obviously many of them have moved on (e.g., Fortress for GLS).

chubot 11y ago

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. https://github.com/lukehoban/es6features https://github.com/lukehoban/es6features http://es6-features.org/ http://es6-features.org/

mkozlows 11y ago
Yeah, I share the linked author's opinion of ES6 -- it's good stuff, but it's also a dangerous direction. Part of me thinks that maybe what's needed is an updated version of "use strict" -- "use es6" or whatever -- that would let you use the new features, but also prevent you from using some deprecated features, to keep the surface of the language somewhat smaller even as new stuff gets added.
- fithisux 11y ago
  For many years I was fiercely against ES. With ES6 I start to change. Your suggestion make sense and I applaud it. Something like "use strict es6" would make our lives easier. Backwards incompatibility here has a goal.
- dangoor 11y ago
  That was seriously considered some years back and thrown out as likely to cause poor adoption and poor intermingling of language features. http://www.2ality.com/2014/12/one-javascript.html http://www.2ality.com/2014/12/one-javascript.html
serve_yay 11y ago
https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 :)
warfangle 11y ago
It's expanding the language, but adding such sorely needed features. I've been working in it for a little while now, and egads is it painful to go back. Block scoping, arrow functions, and destructured assignments are all a godsend.

upofadown 11y ago

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

Animats 11y ago

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.

hga 11y ago
See now the R7RS which is split into a small and large standard (the latter still in progress). R6RS was largely ignored by the community, and there wasn't huge growth prior to it.

hydandata 11y ago

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.

mkramlich 11y ago
seeing this comment on HN, made my PG, a Lisp book author, is amusing. I have to admit that while I don't do Lisp day-to-day probably my favorite Lisp book(s) were written by him. The practical hacker in me prefers Python, Java and C. But the elegant hacker in me? Prefers Lisp. And PG captured that in his writing.
- PuercoPop 11y ago
  IDK where the elegant but impractical (as it was a trade off). CL is a practical language. Consider loop, format, multiple values or the standard methd combination in CL. While the only practical thing about python is that it has more libraries. Nevermind the fact that python scope is misdesigned even in Python 3!

kazinator 11y ago

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?

realityking 11y ago
I think the post was more about syntax, not standard library. Functions and methods are reasonable easy to lookup, syntax much less so. Also try googling for some unknown syntax.
- kazinator 11y ago
  > I think the post was more about syntax, not standard library If that is so, it has no point. The bulk of the 1153 pages of the Common Lisp standard is in fact describing a standard library, so if the definition of "large language" is one that has a large core syntax, excluding standard library, then it's a small language, in fact. Most of the syntax of a typical Lisp dialect (Common Lisp included) takes the form of a standard library. If you seen an unfamiliar syntax, it consists of a form with an unfamiliar symbol in the leftmost position: (unfamiliar-symbol ... stuff (you (do not)) understand) You search your help resources for "unfamiliar-symbol". The lexical syntax ("read syntax" in Lisp terms) is quite very small. It consists of elements like what constitutes a symbol token, what numeric and other constants look like, and other such elements. Stuff like: #(this is a vector) #c(3.0 4.0) ;; complex number 3.0i + 4.0. `(quasi ,quote) '(quoted list) package::symbol

pg_is_a_butt 11y ago

what a joke of a response. no, because no, and if it's yes, i'll employ murder. why? because new things mean too many things... ALWAYS. no to everything. let yourself get fucked;

jaunkst 11y ago

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 11y ago

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

braythwayt 11y ago

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?

inglor 11y ago
For what it's worth - the authors know each other from before and knowing both parties Mark did not intend to mean any offense.
- braythwayt 11y ago
  I came back to note that Mark has subsequently clarified that he meant absolutely no slight against Kyle. He is a gentleman.

gongador 11y ago

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": 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. https://web.archive.org/web/20100706204555/http://danweinreb.org/blog/complaints-im-seeing-about-common-lisp https://web.archive.org/web/20100706204555/http://danweinreb... (Daniel Weinreb was, among other things, one the designers of Common Lisp.) Zach Beane has some more information on this at https://xach.livejournal.com/319717.html https://xach.livejournal.com/319717.html 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.

TazeTSchnitzel 11y ago

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.

benaston 11y ago
I think the jury is still out on `class`. I can say that `class` is somewhat "dishonest" both the sense that it makes the language more complicated, under a guise of simplification; and in the sense that it lures developers from classical languages into thinking that JavaScript has classes in the same manner, when `class` in JS is just sugar.
- phpnode 11y ago
  I see this line of thinking a lot and I think it's a mistake. Are classes in other languages consistent with each other? Clearly not, so why is this distinction made here? ES6 classes ARE classes, it's not just sugar, that is what they are.
  - 11y ago

dschiptsov 11y ago

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.

pjmlp 11y ago

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.

newuser88273 11y ago

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

Grue3 11y ago

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?