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?
If Common Lisp is a failure, how is it that there are multiple commercial offerings for it?[0][1]
I would take the continued presence of these commercial offerings as a sign of health in the Common Lisp ecosystem.
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.
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.
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.
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.
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.
Many/most Lisp systems have a runtime written in C and/or assembler.
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.
https://groups.google.com/forum/#!topic/comp.lang.lisp/Bj8Hx...
Interestingly enough, KMP is on the side of "not lisp" and the thread was started by https://news.ycombinator.com/user?id=lisper
https://www.youtube.com/watch?v=V7axvT4fkF4
It's a real end-user applications that has nothing to do with programming. The user does not see Lisp and does not need to know Lisp.
Would Autocad qualify?
Get a login by sshing to new@sdf.org,then type verify at the command line
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
How'd they react to that one?
(defun x-find-color (rgba &key (x 0) (y 0)
(width default-width) (height default-height)
(test #'equal)
(snap-data (x-snapshot :x x :y y :width width :height height)))
...)
This are nitpicks, the code is understandable and easy to read. Nice writeup and cool idea!
[0]: https://github.com/VitoVan/cl-dino/blob/master/cl-autogui.li... [1]: https://github.com/slburson/misc-extensions
> 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.
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!