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

https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks

by error54 • 11 years ago

144 134 11 years ago

PaulHoule• 11 years 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.

falcolas• 11 years 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• 11 years ago

Java, or, how "software engineering" can kill a decent enough language with incredible complexity.

jerf• 11 years 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-b...

oconnor0• 11 years 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• 11 years 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.

javajosh2• 11 years 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.)

javajosh2• 11 years 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.

jdmichal• 11 years 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.

fithisux2• 11 years ago

Type erasure kills the language. Otherwise, it would have a bright future.

edwinnathaniel2• 11 years 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_yay2• 11 years ago

Isn't that the same with _any_ ecosystem?

It is!

lmm7• 11 years 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)

sbilstein• 11 years 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.

edwinnathaniel2• 11 years 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_user3• 11 years 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.

orthecreedence2• 11 years 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• 11 years ago

I don't have the exact quote/source right here handy, but I believe that was Guy Steele's intention with Scheme.

Jtsummers• 11 years ago

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.

tikhonj• 11 years ago

He gave a brilliant talk about it: "Growing a Language"[1].

The idea is to make languages that grow—ones that provide a small, uniform core that can be extended by the user. Ideally, these extensions feel like first-class citizens: things added by users should feel on par with built-in language features.

It's still one of the best technical talks I've ever come across.

[1] https://www.youtube.com/watch?v=_ahvzDzKdB0

nabla9• 11 years ago

If that's so important why has nobody done it? CL is programmable programming language.

It would take less than a hour to separate those core 25+ symbols in Common Lisp into core package and then separate other symbols into other packages. Common Lisp has less than 1000 symbols.

orthecreedence2• 11 years ago

Actually, I think I might do it. After thinking about it for a few minutes, you're right, the work is somewhat minimal. Then you have a standard library. Instead of :use'ing :cl, you'd just use what you want out of the lib.

If it caught on, implementations could use it for hinting when compiling, and everything would be backwards compatible by just using :cl again.

Blackthorn• 11 years ago

I think nobody's efforts there have really caught on because Common Lisp as a community is hopelessly conservative.

At least Lisp as a whole isn't -- Clojure is a hell of a lot simpler than CL, though even it now has someone with a "let's separate things out into different packages" project (called Dunaj -- I actually think it's a pretty good idea, but nobody's really talked about it).

bitwize2• 11 years ago

This exists; it's called the R7RS standard for Scheme. It basically divides Scheme into two languages: a small core with a basic module system, and a more extensive language with a robust standard library packaged as modules.

lisper9• 11 years 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

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.

collyw3• 11 years 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.

agumonkey4• 11 years 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.

lisper9• 11 years ago

If you build one new feature that subsumes N>1 old features then you're effectively shrinking the language because you never need to use those N old features any more. You can then support legacy code with macros that compile the old features into the new feature. At that point you've actually shrunk the language. You can even have those legacy support macros give compile-time warnings that the old, now-deprecated feature is being used and that the code ought to be changed. In fact, you can even easily write tools that will do this translation automatically. So yes, you really can shrink the language.

dschiptsov3• 11 years ago

The key idea is to grow layers of your own DSLs embedded in a Lisp. It is a bottom-up process of growing of a layers of abstractions, similar to building if a house (but, paradoxically, without blueorints) which some people called 'exploratory programming'.

PG in his "On Lisp" book explained this process in details. In some sense, those who never read it cannot claim to be a Lisp programmer.

So, you are not extending the language, you are growing a several new ones (layers) according to the domain at hands.

jlarocco• 11 years ago

I don't think it's much different than the library situation with most other programming languages.

The one big difference is that Lisp libraries can add new controls structures to the language in ways that most language's libraries can't.

For example, in Python, I can fetch a website using the stdlib's http.client, or I can use the more convenient functions from the Requests library.

In Lisp, I can iterate and loop using the built-in "loop" construct, or I can use the more convenient control structures defined in the Iterate library.

sklogic7• 11 years ago

Not necessarily. If you do not allow a fallback to your host language from your DSL, it's possible to narrow it any way you like.

yason• 11 years ago

The standard way to embed your own language is to use a Lisp to begin with.

Any Lisp language is effectively designed to provide standard tools and mechanisms for adding new language constructs so that you can write your own language without having to write either a full implementation from the tokenizer to the interpreter or use non-standard glue to hook an existing scripting language into a compatible C runtime.

dmytrish• 11 years ago

Can you disable a part of language reliably? For example, is there a way to ban `setf` in a package/file?

If not, what's the point of pretending that a part of the language does not exist if anyone can break this status quo anywhere?

lisper9• 11 years ago

Sure, just create a new package and don't import CL:SETF into it.

danidiaz• 11 years ago

In Haskell, there are language pragmas that enable extra features for a given module, but sometimes can also remove them (completely forbidding unsafe functions, disabling record syntax, and the like).

ihuman2• 11 years ago

Do you have the code for those macros somewhere online?

lisper9• 11 years ago

https://github.com/rongarret/ergolib

lmm7• 11 years ago

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.

Not true. If a language has adequate general constructs then you can replace language features with ordinary code written in the language. E.g. in Scala no-one uses "return" any more, because you can get the same functionality (in a better / more consistent way) using library types - just ordinary classes with ordinary methods, no macros needed.

lisper9• 11 years ago

in Scala no-one uses "return" any more

Huh??? Does Scala even have a "return" statement? I can't find it in the docs.

sklogic7• 11 years ago

Ok. Replace an optimising static BNF compiler macro with "classes" and "methods".

modarts• 11 years ago

I've worked in Clojure for years and have no clue what you're even talking about

davelnewton4• 11 years 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) 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.

lukego2• 11 years 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.

davelnewton4• 11 years ago

I think Clojure's reception was great--the oldies, overall, were very positive.

chubot• 11 years 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

http://es6-features.org/

serve_yay2• 11 years ago

https://www.youtube.com/watch?v=PSGEjv3Tqo0

mkozlows• 11 years 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.

fithisux2• 11 years 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• 11 years 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

warfangle• 11 years 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.

TazeTSchnitzel5• 11 years ago

From one of his more recent talks, Crockford said that most of the new features in ES6 had not yet been proven to be good parts. Fairly damning, I think.

upofadown• 11 years ago

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

Animats• 11 years 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• 11 years 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.

a8da6b0c91d• 11 years 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.

hydandata• 11 years 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• 11 years 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• 11 years 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!

kazinator4• 11 years 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• 11 years 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.

kazinator4• 11 years 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

jaunkst• 11 years 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• 11 years ago

Here's a title for a rebuttal in case anybody wants to write it. ;)

The Tragedy of ISLISP, Or, Why Small Languages Implode

braythwayt2• 11 years 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• 11 years 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.

braythwayt2• 11 years ago

I came back to note that Mark has subsequently clarified that he meant absolutely no slight against Kyle. He is a gentleman.

gongador• 11 years 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...

(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

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.

TazeTSchnitzel5• 11 years 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• 11 years 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.

phpnode2• 11 years 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.

Arnavion• 11 years ago

If you want to scope something to a block, you can just use an IIFE.

Now try doing that in a loop that you want to break out of. Edit: To save you the trouble - https://github.com/babel/babel/issues/644

"class" is unnecessary at best. ... Why lock users into one paradigm?

It canonicalizes one of the popular ways of doing classes (the other being the same but without `new`).

Why the hell is {bar} equivalent to {bar: bar}? Isn't that a set literal (Python, math)?

{ ... } in JS has never meant set literals. It does however mean objects (dictionary literals) which is also how Python uses it.

You'd logically expect {[1+1]:2} to be an object with an Array (coërced to string?) key, because [] is an Array literal.

[] has also always been used to index objects and arrays, so using it when generating the object with keys and values follows as an extension of that.

Method properties, e.g. { foo(a,b) { ... } }, are unnecessary given => functions.

Arrow functions capture lexical this, which method properties do not. Compare `({ x: 5, foo() { return this.x; } }).foo()` with `({ x: 5, foo: () => this.x }).foo()` Arrow functions also do not have an arguments object.

TazeTSchnitzel5• 11 years ago

Now try doing that in a loop that you want to break out of.

Fair point, although this can be worked around. Though it begs the question of why you need block scoping anyway. If you have a function large enough to need it, you should probably break it down into smaller functions, and compose them.

It canonicalizes one of the popular ways of doing classes

But there are other popular ways, and this way new users will have the underlying details hidden from them, meaning they'll encounter problems later. It's also potentially misleading.

{ ... } in JS has never meant set literals.

Yes, but it's never been { a, b } - there's always been a colon. Python also uses {} for dictionaries, but with colons. Having { a } magically use the variable's name as a key name, and also use the variable's value, is unintuitive. { a, b } in another language would be an array (C, C++) or a set literal (Python, mathematics). Nobody would expect it to do what it does here in ES6.

[] has also always been used to index objects and arrays, so using it when generating the object with keys and values follows as an extension of that.

I suppose that makes some sense, but we don't use [] for string keys in literals.

Arrow functions capture lexical this, which method properties do not.

Oh, right, good point.

dschiptsov3• 11 years 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.

raymondh• 11 years 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.

pjmlp• 11 years 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• 11 years ago

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

Grue3• 11 years 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?

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

Related Stories