3 ms·

Yeah right. Elisp was dynamic-scoping-only until version 24.1. That means elisp code written before that (i.e., 99.999% of emacs code that's not in C) as well

Yeah right. Elisp was dynamic-scoping-only until version 24.1. That means elisp code written before that (i.e., 99.999% of emacs code that's not in C) as well as most of the code written after that, has essentially the feel of hacky cruft which will drown a modern programmer into an abyss of cognitive pain and headache when (s)he attempts to understand, modify, or debug it. (not unlike GOTO ridden spaghetti) How many programmers have you come across that claim to use elisp as their primary programming language? (to give you an idea, enough of emacs users/hackers are sick of elisp enough that emacs is now offered in two configurations: based on elisp or based on guile)

deleted 9y ago
[deleted]
DonHopkins 9y ago
Hey at least Elisp wasn't ever as bad as Mock Lisp, the extension language in Gosling (aka UniPress aka Evil Software Hoarder) Emacs. It had ultra-dynamic lazy scoping: It would defer evaluating the function parameters until they were actually needed by the callee (((or a function it called))), at which time it would evaluate the parameters in the CALLEE's scope. James Gosling honestly copped to how terrible a language MockLisp was in the 1981 Unix Emacs release notes: https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosling_Unix_EMACS_Dec81_djvu.txt https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosl... 12.2. MLisp - Mock Lisp Unix Emacs contains an interpreter for a language that in many respects resembles Lisp. The primary (some would say only) resemblance between Mock Lisp and any real Lisp is the general syntax of a program, which many feel is Lisp's weakest point. The differences include such things as the lack of a cons function and a rather peculiar method of passing parameters. "Rather peculiar" is an understatement. More info, links and code examples: https://news.ycombinator.com/item?id=8727085 https://news.ycombinator.com/item?id=8727085
- kazinator 9y ago
  That's why Java is the way it is. Like father, like abomination.
armitron 9y ago
Have you ever programmed with dynamic binding in Emacs Lisp or are you talking out of your ass? Because it's sort of obvious to me that the latter is the case here. For 99.999% of cases in Emacs, there is no difference between dynamic and lexical binding regarding how code reads & feels. Not to mention that Elisp was not dynamic-scoping-only (sic) until version 24.1, there exist lexical-let & friends. Not to mention that guile-emacs is basically a hack at this point in time that very few ppl actually care about, the vast majority of Emacs users being very happy with Emacs Lisp. Not to mention that even if guile-emacs becomes viable and more popular, it'll still be running Emacs Lisp on top of the Guile VM. For someone that can't even get his facts straight you sure have a lot of strong opinions.
- kazinator 9y ago
  Anyone who is used to coding in a Lisp with closures will be handicapped by a lambda that is just code without an environment. It only makes next to no difference if you're writing Fortran in Lisp: just block scoped functions with parameters and locals, but no expectation of function indirection that carries environments. You know, even Wirth's Pascal lets you at least pass a functional argument downward, with its lexical environment ("downward funarg")! Lambdas with no environment can sort of fake downward funarg, if nothing is dynamically shadowed on the way down. I.e. (some-function (lambda () x)) If nothing in the activation chain inside some-function binds x between here and the point where the lambda is called, then we're good: the x dynamically resolves to our x. If something binds x, we have a bug. Or worse; we don't have a bug: it's set up that way on purpose.
lispm 9y ago
That's nonsense. Emacs Lisp has served well as programming language for 30 years. There is some really fantastic code written in Emacs Lisp. Dynamic Binding is a minor issue. People have been writing whole operating systems in dynamically bound Lisp and I'm not talking about GNU Emacs itself. There is no GNU Emacs based on Guile in the sense that the Elisp code has been translated to Scheme. All there is is an Emacs based on the GNU Guile runtime. The code is still written in Emacs Lisp - it just runs on a different runtime. From https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs > Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile. It's a different compiler. You can write stuff in Scheme, too. But who would do it, since then it would not be compatible with the main GNU Emacs editor...

deleted 9y ago

[deleted]

DonHopkins 9y ago

Hey at least Elisp wasn't ever as bad as Mock Lisp, the extension language in Gosling (aka UniPress aka Evil Software Hoarder) Emacs. It had ultra-dynamic lazy scoping: It would defer evaluating the function parameters until they were actually needed by the callee (((or a function it called))), at which time it would evaluate the parameters in the CALLEE's scope. James Gosling honestly copped to how terrible a language MockLisp was in the 1981 Unix Emacs release notes: https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosling_Unix_EMACS_Dec81_djvu.txt https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosl... 12.2. MLisp - Mock Lisp Unix Emacs contains an interpreter for a language that in many respects resembles Lisp. The primary (some would say only) resemblance between Mock Lisp and any real Lisp is the general syntax of a program, which many feel is Lisp's weakest point. The differences include such things as the lack of a cons function and a rather peculiar method of passing parameters. "Rather peculiar" is an understatement. More info, links and code examples: https://news.ycombinator.com/item?id=8727085 https://news.ycombinator.com/item?id=8727085

kazinator 9y ago
That's why Java is the way it is. Like father, like abomination.

armitron 9y ago

Have you ever programmed with dynamic binding in Emacs Lisp or are you talking out of your ass? Because it's sort of obvious to me that the latter is the case here. For 99.999% of cases in Emacs, there is no difference between dynamic and lexical binding regarding how code reads & feels. Not to mention that Elisp was not dynamic-scoping-only (sic) until version 24.1, there exist lexical-let & friends. Not to mention that guile-emacs is basically a hack at this point in time that very few ppl actually care about, the vast majority of Emacs users being very happy with Emacs Lisp. Not to mention that even if guile-emacs becomes viable and more popular, it'll still be running Emacs Lisp on top of the Guile VM. For someone that can't even get his facts straight you sure have a lot of strong opinions.

kazinator 9y ago
Anyone who is used to coding in a Lisp with closures will be handicapped by a lambda that is just code without an environment. It only makes next to no difference if you're writing Fortran in Lisp: just block scoped functions with parameters and locals, but no expectation of function indirection that carries environments. You know, even Wirth's Pascal lets you at least pass a functional argument downward, with its lexical environment ("downward funarg")! Lambdas with no environment can sort of fake downward funarg, if nothing is dynamically shadowed on the way down. I.e. (some-function (lambda () x)) If nothing in the activation chain inside some-function binds x between here and the point where the lambda is called, then we're good: the x dynamically resolves to our x. If something binds x, we have a bug. Or worse; we don't have a bug: it's set up that way on purpose.

lispm 9y ago

That's nonsense. Emacs Lisp has served well as programming language for 30 years. There is some really fantastic code written in Emacs Lisp. Dynamic Binding is a minor issue. People have been writing whole operating systems in dynamically bound Lisp and I'm not talking about GNU Emacs itself. There is no GNU Emacs based on Guile in the sense that the Elisp code has been translated to Scheme. All there is is an Emacs based on the GNU Guile runtime. The code is still written in Emacs Lisp - it just runs on a different runtime. From https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs > Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile. It's a different compiler. You can write stuff in Scheme, too. But who would do it, since then it would not be compatible with the main GNU Emacs editor...