If you like this kind of content, consider joining the SDF. It's a free public access computing community with lots of artists, hackers, and grognards of all stripes. Your support is appreciated: https://sdf.org/
This is really cool. So is http://sdf.org . You can get a lifetime Unix (NetBSD) shell account at them for as little as $5, mail, http/gopher hosting, etc. included, and more.
The donate button on sdf.org seems to fail unfortunately. It'd be fantastic if I could get in, as I've been looking for something like this since bur.st closed down.
Thank you for the link, and for those who come along next and see this link, you'll want to reference the @AceJohnny2 comment where one learns that the spacebar starts the game (up arrow key does as well; just ensure the page itself has focus, and not the location bar).
Then, if you haven't read the article you might not know that the dino crouches with the down arrow.
Thanks to the OP for the great article, and for the comments instructing on how we mere humans can play.
N.B. the dino game has sound for a score that is a multiple of 100, so it might not be appropriate to try during a meeting, or at least mute first
This is one of the most fun and informative programming posts I've seen on Hacker News recently. I also killed my wifi immediately after reading the article to play the game.
Regarding the code, its ok although there are some parts that are unnecessarily messy. Here[0], and in other parts you use labels in the middle the function. It is best to do in the outer level form. I like the rlabels of misc-extension[1] when using local functions but I understand most people would prefer not to add 'util' dependencies. Another thing in that function. The (let ((data (or ...)))) is unnecessary. You place the form in the default case of the keyword argument So it would end up looking like:
> Also if not using asdf, the quickload form should be
> wrapped in an eval-when. It will fail If I Try to
> compile the file (C-c C-k) on a fresh session.
Also, I was particularly embarrassed this weekend... my cable modem went down, as it has been doing a lot recently (!#$%# Charter...) and I showed my daughter the Chrome game. She told me "oh, I already know about that." She's eleven...
To beat the dino game, the author played the "write a game AI" game. That's a much harder game, which is going to take a while to beat. The general gameplaying work being done at the moment stands a good chance (e.g. DeepMind's Atari playing system, AIXI approximations, etc.), although I still think Nomic is a harder game to beat than Go ;)
After that, we can start playing the "write an AI generator" game. The fun never stops!
Apart from Clojure (which is not LISP, really), I haven't seen end-user applications written in LISP dialects (I don't think emacs is end-user software). Scheme (and its PLT dialect Racket) was in academia for so long that it literally got "friend-zoned" and has little (read "no") use in the industry.
Then again, I expected to see more Common LISP around. Paul Graham really put it right, but I guess any leverage/advantage LISP had on other languages, it waned in the 90's (maybe Viaweb was one of the last projects done in LISP, and even that was translated later to other langs...)
I don't think s-expressions are _that_ problematic. The main issue with LISP's nowadays is lack of _momentum_. Java gained its momentum by Sun, after that it just keeps rolling in the industry and apparently, there's no stopping that. Python also has its momentum from the academia, what with all the great libraries and all. But one would expect to see some _major_ projects done entirely in LISP (and not a Trojan Horse LISP like Clojure), after that, it's only a matter of time for developers to become LISPers.
Of course, one could also claim that LISP actually _did_ have like half a century to prove itself, or gain momentum. After all, Golang and ruby are relatively new, but they eat LISP's lunch at launch of new apps.
I really appreciate things like this project. It's not enough, but what is?
What you see on-line is mostly the fashion part of the IT industry. Common Lisp is alive and kicking, but it's not fashionable (except maybe as a counterculture).
There are many more stories like that. I was surprised to learn that Delphi is alive and well, and people earn their bread with it writing applications for various industries.
It's easy to see the world skewed by blog posts. There's growing use of Perl[1] outside of the 'SF startup scene' echo chamber, huge quantity of new projects in Oracle APEX, power plant simulations in Tcl[2] and the gardens full of thousand flowers blooming.
> If Common Lisp is a failure, how is it that there are multiple commercial offerings for it?
Well, one possible explanation is that they were sufficiently popular at one point that codebases were built that are large enough to need maintaining but too large to justify re-writing.
I haven't had that experience with a Common Lisp implementation but I have with Smalltalk, Cobol and System-W (although the latter was eventually replaced at considerable expense).
Obviously, that argument fails if the commercial offerings are relatively new and not updates of old implementations.
Maxima? I mean, it traces its lineage to the golden age of Lisp, but it's still being released.
And you say Scheme was friend-zoned by the industry. While I understand why this was, it's a shame: Scheme is a very nice language, and with several high quality implementations, some excellent FFI, and finally some good library support (CHICKEN is excellent here), not to mention Racket's deluge of features and libraries (not really a fan of it myself, and it's not scheme, but I'm willing to admit it's a good system, to say nothing of impressive), it's finally slowly reaching the point where it might be usable in an industrial environment. Although it's not there yet, you can definitely write useful things in it.
Earlier accessibility of a top Scheme implementation could have helped make it more popular earlier. Just like with Smalltalk and Common Lisp before which also got into trouble because of good implementations being out of reach of most people.
What about SCM, T, Larceny, Bigloo, Gambit, Chicken, Guile, and Racket? All were open source before Chez. T, in particular, while no longer active, was at the time a pioneer of fast and effective scheme compilation.
One could make a number of arguments about at least half of these. Racket/PLT has been free for a long time but ten years ago, a friend of mine simply left it for Common Lisp for the sole reason of speed. Gambit is great - I'd say almost as good as Chez - but there's no proper modules or native multi-threading. The Scheme->C model is also cumbersome; reintroduction of a native compiler was promised but if I'm not mistaken, still hasn't happened (although some other interesting things did - the recent mobile code support is very interesting!). T was a research vehicle but apparently the closest thing to an accessible environment for it was A/UX on Mac. Say what you want about IBM PCs but they won.
End user Lisp deployment is little, but Lisp use in commercial and scientific environment is not. It does not have the recent momentum spike that some other things have or had, but it has a stable-and-slightly-increasing momentum that it had since the beginning. Ruby has RoR and Go has cool guys and Google, but Lisp has been doing good without any of these all along.
I don't see why Clojure is not Lisp. The only major problem with it is its memory demand, which is a problem it you don't have RAM in abundance. But it's been the first Lisp widely deployable thanks to Java, and thus all the deserved hype around it.
The one big trouble in Scheme is the too-late standard module system. In absence of a standard, everybody created their own, so intercompiler portability is hard (although I'm not all that familiar, maybe I'm mistaken). Another problem is the name, as I can't say it without a blush here in Turkey :)
Unfortunately, the module system's not enough. When R7RS-large hits, you'll hopefully finally be able to port between implementations by simply cond-expanding your FFI interactions, and adding a makefile. With the the approaching release of Red, it looks like this may finally be happening.
Clojure is definitely a lisp, but an odd one. It uses a foreign read syntax, is too close to Java for my tastes (reasonable people my disagree with my irrational hatred of Java), and it screws with Lisp tradition in ways even Scheme doesn't: Ways I don't think are necessarily for the better.
() isn't nil, nil is kinda-not-really like scheme's #f, keywords aren't symbols, nil isn't a symbol, `x isn't the same as 'x, ~ is unquote, there are not cons cells, so cons doesn't do what you think it does, car and cdr don't exist afaik, but first and rest do, lambda is fn, which is also defun (or define in scheme), = is the new equal (or equal?), collections are more generic, and the whole thing is lazy.
To conclude, the difference in spirit and ideas between Kawa and most other JVM lisps and Clojure is similar to the difference between *BSD and Linux:
Clojure is what happens when a bunch of Java hackers write a lisp for the JVM, Kawa/ABCL is what happens when a bunch of Lisp hackers port a lisp to the JVM.
"Clojure is what happens when a bunch of Java hackers write a lisp for the JVM"?
That sounds "clever", but you should be aware that Hickey developed several Lisps before Clojure and was active in the Common Lisp community in the years leading up to it.
Also, some of your statements about Clojure are just incorrect; e.g., Clojure is not wholly lazy.
Well, the laziness yes, thanks for the correction, but much of it was from Clojure's own page about how it is different from other Lisps. And I am aware of Hickey's history. I was trying to provide a summary of the difference in outlook between Clojure and Kawa/ABCL: Clojure is decisively more "java-ey" than either of the others, and very much feels like a lisp for those already familiar with that language, with some FP on the side. I don't know if that's just my interpretation of Hickey's ideas, or if it was a deliberate design decision, or if it fell out of the Java interop. It could be any of them. But the language has a distinctly unlispy feel as a result, even though it IS a lisp, lack of cons cells not withstanding.
I always read the history as Hickey wanting first-class Java interop after his experience with FOIL[1]. In addition he wanted Clojure to be specifically for functional programming (something Common Lisp doesn't excel at).
IMO, most of the things that make early versions of Clojure different from previous Lisps do fall out from the requirement of first-class Java interop and being opinionated about pure data being the Right Way to do multithreaded.
From that point on Clojure is its own thing, and will naturally diverge.
I think we have to get rid of the idea that any language with parentheses is a Lisp. For all practical purposes languages like Scheme, Lisp, Clojure are fully incompatible on all levels: syntax, semantics and pragmatics. All they share are some distant ideas (some form of s-expression syntax, some form of macros, ...) provided in incompatible ways. They share no code, no libraries, no books, no community, ... that's a consequence of being different.
Note that this says nothing about their usefulness for developing software.
...And I think we need to get rid of the idea that those differences necessarily precludes them from being Lisps. Because make no mistake, they are all Lisps.
You said that they didn't share code, libraries, books, or community. First off, they do share community to some degree: there's a good bit of overlap between all of them. It's not all overlap, but there's plenty there.
Second off, you know what other languages don't share code, library, or books with the Common Lisp we know today? MACLisp. Interlisp. Portable Standard Lisp. Lisp 1.5. Emacs Lisp. AutoLisp. ISLISP. Eulisp. Arc. To say nothing of Hy, LFE, MDL, Newlisp, NIL, Picolisp, and yes, Clojure and Scheme. And there are countless others.
Lisp has always been a language of many different dialects. Why should we pretend it's any different now?
Second tthis. The term Lisp in CS is like Romance in linguistics, it indicates a family of languages that belong to different similar but not identical cultures which contribute to them and yet still the languages come from a common ancestor and are more similar than not while at times not easily mutually comprehensible.
People who can speak German dialects can understand each other. Books written in some form of German can be understood by most readers.
Same for English dialects.
For Germanic languages this is not the case. English and German are both Germanic, but knowing German does not let me read English literature.
Lisp is like English: a basic vocabulary, a basic syntax, basic semantics understood by all readers. I can look at some basic Lisp code and I will understand the program. A Lisp developer looking at Clojure code will understand very very little.
English is such an oddball in the Germanic family that I'd count it an outlier. About 40% of its vocabulary is of Latin origin, and in sum about 60% of its vocabulary is made up of loan words. A couple years ago I submitted the "Uncleftish Behaviour" here [1], which demonstrates English with only germanic words.
Around three from thirteen special forms have roughly the same name/meaning in Lisp.
Let's look at printing: pr-, prn-, print-, println-, newline-. None Lisp names, either they don't exist in Lisp under that name or they do something else. PR and PRN don't exist in Lisp. PRINT prints a newline before printing the object. PRINTLN does not exist in Lisp. NEWLINE is called TERPRI. Thus even for a simple thing as basic IO the API is different.
Thanks kaz, but I've already got the manpage bookmarked. I haven't looked at it in-depth yet, but it seems to be awk, but better, which is pretty awesome.
You can also completely ignore the "awk-but-different" TXR pattern-based extraction language, and just use it as a Lisp, too. The REPL is nothing but Lisp, and code stored in ".tl" files is treated as Lisp. TXR Lisp is designed to be a nice Lisp dialect on its own, not to just fill in the gaps in another language.
Maclisp came from Lisp 1.5. Code was simply ported to Maclisp. Some Lisp 1.5 code runs mostly unchanged in CL.
Maclisp shared code with Common Lisp. For a lot of stuff there was a single code base at MIT for several Lisp dialects, including Maclisp. After some time Maclisp development ended and sharing ended. For example the source code for the complex LOOP macro was at one time a single file for Maclisp, NIL, Lisp Machine Lisp and Common Lisp.
People ported programs from Maclisp to CL by changing them or by translating them with tools, not by rewriting them.
There were also code bases which worked both in early Scheme and CL.
Emacs Lisp has a huge CL subset and even includes a version of CLOS. Since both Emacs Lisp and Common Lisp are coming from Maclisp, both languages are very similar anyway. Basic operators are the same, differing in various details - like dialects often do.
Common Lisp had Interlisp compatibility packages, while Interlisp was still used. There were translators, too.
Xerox had Interlisp and Common Lisp integrated in one Lisp.
Kent Pitman wrote an ISLISP compatibility package for Common Lisp.
There are compatibility packages for Portable Standard Lisp, which allow the unchanged use of PSL code in Common Lisp.
etc etc
There is zero code sharing between Lisp, Clojure and Racket. Compatibility with the Lisp 1, Lisp 1.5, Maclisp, Common Lisp, Emacs Lisp, CL, ISLISP, main line of Lisp wasn't a goal for Clojure and Racket. That's fine. They got rid of historical baggage and could design new languages.
Basic rule: if a language has LISP in its name, there is some chance that it actually is a LISP.
People usually name their language LISP something, to give the impression that the language is compatible with Lisp. They use different names, when the language is different: Scheme, Javascript, Logo, Dylan, Clojure, ...
Take a Lisp 1.5 manual, look at the function index and check which functions and special forms are provided. If most of those are absent (or doing something different), it's not a Lisp: append, atom, car, cdr, cond, cons, eq, eval, intern, list, load, map, member, pair, print, read, prog, quote, reverse, return, set, setq, trace, ...
What is the point of this genealogy? What makes a language a Lisp is (i) natural and practical homoiconicity with sexps, (ii) automatic memory management and (iii) advanced interactive development features, including the REPL, the image, restarts and hot code loading. These are the features that distinguish it and make it an advanced tool. (i) is quite particular to it, (ii) is invented for it and (iii) is a big part of the power, and for me, Lisp means a language that has (i), (ii) and (iii) in one package. Otherwise whether or not it include code from Lisp 1.5 or allow effortless porting is not all that important. For the latter, most compilers are cross-platform anyways, so one can just grab a suitable binary tarball and get going.
Clojure fails at (iii), as it just propagates Java exceptions, but I don't think that is impossible to fix, so not a fundamental flaw. JVM is too heavy, and that is a problem for some. Otherwise, it's a well thought-out Lisp with a thriving community and some cool guys and a BDFL (i.e. Hickey).
Common Lisp excels at all the three of the items I listed, plus it's batteries included and has lots of libraries around. Also, it has a standard, so that you can develop on SBCL and deploy with Clozure CL or CMU CL. It's downside is there's some historical baggage and there are no DHH or Hickey or Torvalds in the community, which isn't a downside for me, even an upside.
Those aren't what make a language a Lisp. There are Lisps without Automatic Memory Management, there are Lisps without restarts or images (although hot code loading is fairly common, and I've never seen a Lisp without a repl). Homoiconic expressions are an important part of it, but there are many lisps without macro systems.
I'm a Schemer, and Scheme IS a lisp: we don't have restarts, but we do have call/cc, and images as Lisp has them are an optimization hack in any case. And we're finally getting some well supported implementations. Yes, we have hot code loading in most implementations.
Come to the dark side, we have (lexical) cookies (encoded with the current continuation after baking, of course).
Clojure has a primitive repl by default with lots of Java shining through. It has no image dumping. No restarts. Hot code loading is limited. Clojure even has no interpreter.
Images are not a hack. They allow us to save the state of a program and use it later. My Lisp Machine at home would not even work without it. It's the software the machine boots into.
Image dumps are also a useful way to create applications or use pre-assembled program state during development. Makes faster startup times, than loading objects during start each time.
Even an editor like GNU Emacs boots up a Lisp image. Which makes it much faster than loading code at start.
They're an optimization in most dialects that support it: it's not like Smalltalk, where you can reload your app state and continue exactly where you left off.
Smalltalk doesn't do that and if it does, it's because the runtime is dumb. For example, a Smalltalk which saves and restores threads in an image, can only do that, because it does not use native threads. Various Lisp systems are using native threads. If a Smalltalk image starts, formerly open files may be opened again. If the files is not there, then nothing happens. Same for network connections.
I would be very irritated if my Lisp Machine on start would reopen all network connections... But it has a controlled restart process, where I tell Lisp what to restart on a reboot. Actually a Lisp Machine has a list in memory, where the restart tasks are kept. If the image is restarted, one of the tasks it does is to go through this list and execute the various restart tasks...
I don't know all of smalltalk's semantics for transient connections: However, when a smalltalk image is shut down, a snapshot of all objects in a live system are kept. I would assume that the VM signals a shutdown, and that would tell all the transient entities to close themselves.
Anyways, Lisp images don't work like that: a lisp image is a static preloaded environment. If you redefine some functions, exit lisp, and reopen the interpreter, those redefinitions won't be there.
Why would you exit? On a Lisp Machine you can make the image and continue working. It also has incremental images, etc.
If I save and load an image, the new definitions are still there.
What you refer to has very little to do with imags, Smalltalk keeps a database of code in files under system control. That's also how Interlisp worked.
On a Symbolics Lisp Machine I would configure the machine, load my software and create an image. After starting that image I would on login load any changes from the code bases. If this would be too long, I would save an incremental image.
The Lisp Machine had many more image related features...
Well, on a lispm, yes. However, most of us don't have lispms (as much as we might want one!), and the symbolics VM is a pain to run. In CL, you don't do that sort of thing.
In any case, at least a few Schemes have images, so it's a moot point in that debate. It's still interesting, though.
Oh, something like LispWorks has extensive support for using images, too. It has a very extensive application/library delivery mechanism based on images.
LispWorks can also save 'sessions', even automatically as periodically timed events. Even without quitting Lisp. Sessions are basically IDE states (files, listener history, lisp image, windows, ...).
Most of those things appear in scheme. Slightly different naming, but the same, more or less.
To say that there's compatability between Scheme and CL, and no compatability with Racket is ridiculus: Racket has Scheme compatability modes.
As for the language being called Lisp if it's Lisp, two of the examples you list in the "non lisp" category do so: Clojure's website claims it is a "dialect of lisp," and AIM-349 describes scheme as "essentially a full-funarg LISP."
As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. They have the same origins, and they share many of the same ideas.
> AIM-349 describes scheme as "essentially a full-funarg LISP
That's long ago. That was kind of true in the mid 70s.
> and no compatability with Racket is ridiculus
CL has no Racket compatibility. Zero. Racket has no CL compatibility. Zero.
Porting programs is a full rewrite.
> Clojure's website claims it is a "dialect of lisp,"
Best it is a new language, derived from Lisp and influenced by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket, Ruby.
'Dialect' in this case is the euphemism for 'fully incompatible' with 'random operator renames and shuffling functionality' where it kind of looked compatible.
> As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects.
Sure, but not of Lisp. Of those three, only Common Lisp is a Lisp dialect.
> They have the same origins, and they share many of the same ideas.
Less and less. As a starter: Clojure has no Lisp lists as basic data structure.
So scheme WAS a lisp, and now isn't? What changed that makes you think that?
And it had better not be nil/false equality. Even McCarthy says that was, if not a mistake, then an accident.
As for Clojure not having Lisp lists, its list implementation is... eccentric, but it DOES have lists.
Actually, scratch that, its list implementation, from a Lisp perspective is broken. Psychotically broken. But it DOES have one. Even if it's insane. What, will you say the same about newlisp lists?
In another comment, @bitwize says No. AutoCAD is written in C++. It has a crude Lisp as an extension language, [...]
Same story for emacs. It's written in C and implements something called "emacs lisp". I'm not inclined to call it crude, but few would defend it if I did... :)
But emacs is special, it's more "extension" than not. That means, the elisp-language extensions that it ships with make up the majority of the "basic" functionality of emacs.
GNU Emacs is written in C and Emacs Lisp. Much of the editor functionality is implemented in Emacs Lisp, while the Emacs Lisp runtime (plus some libs and some external tools) is written C.
Many/most Lisp systems have a runtime written in C and/or assembler.
Thanks. I didn't know about it, but I think this makes Mezzano a failed project anyway. Sure it's good as a "proof of concept" to demonstrate CL's potential, but if I haven't heard about it, how can you expect an ordinary user to know, let alone, use it?
BTW, I'm strongly against the idea of creating new OS's just because we _can_. By end-user app, I mean something along the lines of a browser, fully capable back/front-end framework, essential industrial software, etc.
What about server-side applications? You never know if your favorite website is running Lisp or whatever. We're nearing the days where the only end user application that matters is a browser anyway. Making a web app in Lisp is pretty easy and provides many advantages over traditional languages.
No. AutoCAD is written in C++. It has a crude Lisp as an extension language, but that has been deprecated years ago in favor of VBA and loadable C++ DLLs.
