Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Lisp (1993) [pdf]

dreamsongs.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: The Evolution of Lisp (1993) [pdf]

#11

Post by 0x445442 »

vindarel wrote: post #8
0x445442 wrote: post #5

Earlier quoted context omitted.

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

See the "editor-support" link: there's the Dandelion plugin for Eclipse, although basic; I said Atom support is getting very good. There's Vim, a basic plugin for VS Code, and Lem, a self-contained editor ready to use for CL and many other languages (though it is "emacsy", same keybindings by default, vim-mode included). There's a Jupyter kernel and a terminal-friendly ipython-like repl.

Dandelion doesn't run on linux

Re: The Evolution of Lisp (1993) [pdf]

#12

Post by 0x445442 »

newusertoday wrote: post #7
0x445442 wrote: post #5

Earlier quoted context omitted.

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

why is emacs not a solution? the link provided by parent is excellent beginner friendly environment ( http://portacle.github.io/ ).

I'm not slamming Emacs. I'm just pointing out that there are millions of developers that won't use it and making it a, more or less, requirement to get into Common Lisp is not good.

Re: The Evolution of Lisp (1993) [pdf]

#14

Post by kazinator »

mruts wrote: post #3

I’ve always thought it unfortunate that fexprs were dropped for macros in lisp. For a language that touts homoiconicity and first class functions/objects, it feels strange that macros aren’t first class. My understanding is that fexprs have some perfomance problems over macros, but I’m not really sure why or if the state of the art has advanced since then. A really interesting evolution of lisp is Shen. The license i…

Fexprs have performance problems over macros because fexprs are interpreters whereas macros are compilers. A macro compiles the semantics that the equivalen fexpr would interpret. In 2019, compilation is still generally faster than interpretation.

Fexprs are theoretically interesting in one regard: they can avoid hygiene problems. A fexpr explicitly evaluates material in some explicit environment, so it can work out which environment is used for what. It has straightforward access to its own local material that doesn't interfere with the interpretation of the incoming form, that is done using its own environment. A loop that has an implicit counter which is invisible to the program, if implemented as a fexpr, can just use the fexpr's own local variable as a loop counter, and thus doesn't have to insert a hidden gensym into a code template. A fexpr is not confused if the interpreted form defines a local function called list, even if the fexpr uses list. Macros combine everything into one clump of code, so achieving the same environmental separation requires significant hoops (which are omitted entirely in traditional Lisp macro systems).

Re: The Evolution of Lisp (1993) [pdf]

#15

Post by bitwize »

newusertoday wrote: post #7
0x445442 wrote: post #5

Earlier quoted context omitted.

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

why is emacs not a solution? the link provided by parent is excellent beginner friendly environment ( http://portacle.github.io/ ).

Because it's 2019 and most developers don't want to use a UI from the 1970s.

Re: The Evolution of Lisp (1993) [pdf]

#16

Post by vindarel »

0x445442 wrote: post #11
vindarel wrote: post #8

Earlier quoted context omitted.

See the "editor-support" link: there's the Dandelion plugin for Eclipse, although basic; I said Atom support is getting very good. There's Vim, a basic plugin for VS Code, and Lem, a self-contained editor ready to use for CL and many other languages (though it is "emacsy", same keybindings by default, vim-mode included). There's a Jupyter kernel and a terminal-friendly ipython-like repl.

Dandelion doesn't run on linux

I tried it on Linux though.

Re: The Evolution of Lisp (1993) [pdf]

#17

Post by PuercoPop »

0x445442 wrote: post #12
newusertoday wrote: post #7

Earlier quoted context omitted.

why is emacs not a solution? the link provided by parent is excellent beginner friendly environment ( http://portacle.github.io/ ).

I'm not slamming Emacs. I'm just pointing out that there are millions of developers that won't use it and making it a, more or less, requirement to get into Common Lisp is not good.

> I'm just pointing out that there are millions of developers that won't use

You are just stating it. Without any reason. One can't argue against a statement, you have to provide reasons behind your statement for there to be an argument.

For example: "Asking people to use an editor where C-c doesn't copy and they have to relearn the keybindings is an unnecessary barrier of entry". I would agree with that and note that as a stop measure they can use the mouse for most tasks so they can postpone learning Emacs until they have learned CL.

If you are on OSX CCL has an alternate IDE that's pretty good. Otherwise you can pay Lispworks or Allegro. Yeah it would be awesome if there were a multitude of IDEs, but people are not going to write IDEs for environments they don't use for free, it is unreasonable to expect that.

I've never heard people say 'it is unreasonable to ask people to use Android Studio to develop for Android' so I'm not inclined to agree that it is unreasonable to ask people to use a Emacs to develop for CL. Especially after Shinmera has gone to great lengths to package a pre configured version. I know of a recent lisper that just uses Emacs for CL without previous Emacs exposure. It is an unnecessary barrier, but not more than a hump.

Re: The Evolution of Lisp (1993) [pdf]

#18

Post by m463 »

0x445442 wrote: post #5
vindarel wrote: post #4

To refresh your ideas on CL (I know I needed it): https://github.com/CodyReichert/awesome-cl There may be more libraries than you think. Also recently some usual complaints have been fixed: - hard to set up environment ? -> http://portacle.github.io/ There's also Lem, and Atom is getting good. https://lispcookbook.github.io/cl-cookbook/editor-support.ht... - horrible website ? http://common-lisp.net/ (they fixed it l…

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

I watched a fascinating presentation and when I saw the speaker typing (lambda ...) and having it change to (λ ...) and not having to deal with parens.. I was jealous.

Does emacs do this?

EDIT: the presentation:

William Byrd on "The Most Beautiful Program Ever Written"

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

Re: The Evolution of Lisp (1993) [pdf]

#20

Post by Jim_Heckler »

m463 wrote: post #18
0x445442 wrote: post #5

Earlier quoted context omitted.

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

I watched a fascinating presentation and when I saw the speaker typing (lambda ...) and having it change to (λ ...) and not having to deal with parens.. I was jealous. Does emacs do this? EDIT: the presentation: William Byrd on "The Most Beautiful Program Ever Written" https://www.youtube.com/watch?v=OyfBQmvr2Hc

Yes, M-x prettify-symbols-mode, it's very cool. For parens, there's the built-in electric-pair-mode, paredit, smartparens, and lispy.
Post reply on HN