Live data from Hacker News

Dinosaur and Lisp

vito.sdf.org

31–40 of 97 posts

Re: Dinosaur and Lisp

#31
post #22
post #8

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/adva…

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 majo…

I heard about that. :-D

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.

Re: Dinosaur and Lisp

#32
post #5

Quite inspiring. That's how you beat an endless game.

That's how I see programming in general. 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…

I'm not really good enough to Play the Game yet, but it's endlessly entertaining to watch those who are.

Re: Dinosaur and Lisp

#33
post #28

Earlier quoted context omitted.

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.

...That's what I said.

I guess the self deprecation wasn't appreciated! (I'm a devout emacs user, you know..)

Would you accept that temacs[0] is written in C and emacs is written in emacs lisp?

I'd argue that sbcl is written in C and the sbcl common lisp implementation is written in common lisp.

Is that not the common way of viewing it?

0: https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...

Re: Dinosaur and Lisp

#34
post #29
post #8

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/adva…

I've made this comment before, and I don't intend it to be flippant, but am honestly curious. 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. [0] http://franz.com/products/allegro-common-lisp/ [1] http://www.lispworks.com/

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.

Re: Dinosaur and Lisp

#35
post #24

To see this error page without disconnecting from the internet, visit chrome://network-error/-106.

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…

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

Re: Dinosaur and Lisp

#36
post #22

Earlier quoted context omitted.

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 majo…

I heard about that. :-D 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…

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

Re: Dinosaur and Lisp

#37
post #36

Earlier quoted context omitted.

I heard about that. :-D 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…

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

Re: Dinosaur and Lisp

#39

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…

Thank you PuercoPop, I am learning Common Lisp, your comment helps me a lot, problem fixing...

Re: Dinosaur and Lisp

#40
post #10

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.
Post reply on HN