5 ms·

Interesting points. As a matter of style, I still prefer using currying over "one trick pony" (single method/function) classes, though. Sometimes this means I

Interesting points. As a matter of style, I still prefer using currying over "one trick pony" (single method/function) classes, though. Sometimes this means I have several "layers" of references to the original function, with varying numbers of parameters applied as each layer further specializes (adds configuration). I'm doing most of this type of work in Javascript, though, so YMMV. (PS - also did some work with Lisp in Uni back in the 80s, and sundry imperative/oop/func ; static/dynamic things since)

chubot 10y ago
If you're using JavaScript, I think that's actually an advantage because your closures can return multiple named methods (in a JS dictionary). To me, closures in Lisp seem a bit impoverished since it's awkward to return more than one method. (Another problem is that I don't like reifying random local variables as program state. State is important; it should be both minimized and made explicit. Classes make it explicit.) Classes with one method are useful, but so are classes with multiple methods. I just stumbled across this post again, and HIGHLY agree with it. Yegge is basically outlining why JavaScript is a better language than Emacs Lisp. I had the same experience with hacking on femtolisp and trying to write my shell in it. http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int... OCaml and Lisp both have problems with polymorphic print. There were some recent posts on HN about the expression problem, and the duality between FP and OOP, which I liked. But I have to say that print should be polymorphic, full stop. And if your functional language has problems with that, that's the language's problem and not my problem :) Related: http://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean http://stackoverflow.com/questions/2497801/closures-are-poor... http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent
- lispm 10y ago
  In Common Lisp it is easy to return multiple closures. Emacs Lisp now has lexical closures, too. Common Lisp has no problems with 'polymorphic print'.
  - chubot 10y ago
    Fair enough, but the appeal of Lisp to me is that it's a small axiomatic core, something that not only fits in your head, but the whole implementation fits in your head too. I wanted to use it to bootstrap languages, with no dependencies. But it turns out that this axiomatic core is too impoverished for a lot of programming. You DO need something like Common Lisp on top. And I'm not really willing to open that can of worms, both for this specific project, and in general. I would liken it to the language "Factor", which I've also experimented with... you took a specific and elegant paradigm, and tried to extend it to all paradigms, and ended up with a mess. A square peg in a round hole. Factor is basically Forth with OOP and a whole bunch of other stuff. The other problem I pointed out is that the first problem you hit when writing a language is writing a lexer. I don't see anything that Lisp offers you in that respect. I looked at how Julia does it: https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par... Julia is actually bootstrapped in femtolisp. If you look at the lexer, it just looks like C code written with Scheme syntax. There's nothing helpful about this. It doesn't help you manage state. I might as well just write C. (And actually I chose the code generator re2c, which is BETTER than C.)
    - lispm 10y ago
      > whole implementation fits in your head too Of the axiomatic core. But not of any programming language. > But it turns out that this axiomatic core is too impoverished for a lot of programming. It's not even a programming language. It's just an axiomatic core. If you try to use it for programming you must be doing something wrong. > is writing a lexer. I don't see anything that Lisp offers you in that respect. Lisp is a language family, not language implementation with a library, which happens to include a lexer library. If you mean Common Lisp as a programming language with implementations, there are portable lexers. http://www.cliki.net/LEXER http://www.cliki.net/LEXER https://github.com/drewc/smug https://github.com/drewc/smug https://github.com/lispbuilder/lispbuilder https://github.com/lispbuilder/lispbuilder Writing your own lexer in Lisp shouldn't be too hard. People have written applications in Lisp which includes lexer functionality.
      - 10y ago
- Roboprog 10y ago
  Back at CSU in the 80s, the Lisp exposure we had was so so. We learned about pure functions and a tiny bit about higher order functions, but that's about it. Nothing much about closures explicitly. It's funny that one of the other commenters mentioned Smalltalk and blocks. Version 5 of the "Clipper" language I was using at work, which came out around 1990, added (borrowed, stole) blocks to an "XBase" style language. I didn't quite know what to do with them, so I used them to simulate virtual method tables in a non-OOP language :-) It wasn't until I started tinkering with Ruby around 2006 or so that all the block / closure / lambda stuff REALLY sunk in ("Hmm. I could have been doing this - subroutines as closures, and not just "blank" call-backs - in all the Perl 5 code I've written the last 8 years"), some 20 years or so after I was in college. They did a good job of brainwashing proto-OOP into us back in the mid 80s. Never used any Lisp macros, but "eval" and dynamic languages sure help shorten many tasks vs static types bondage and discipline. There's another Yegge essay on that sort of thing ("code compression"). The PC "4GL" type languages I used at work in the 80s were dynamic, with runtime types, and quite productive for the jobs they were designed for (pre MS-Windows...). I'm tired of the static type authoritarians punishing us all for the sins of C/C++. (I need to stop before I go into another rant)

chubot 10y ago

If you're using JavaScript, I think that's actually an advantage because your closures can return multiple named methods (in a JS dictionary). To me, closures in Lisp seem a bit impoverished since it's awkward to return more than one method. (Another problem is that I don't like reifying random local variables as program state. State is important; it should be both minimized and made explicit. Classes make it explicit.) Classes with one method are useful, but so are classes with multiple methods. I just stumbled across this post again, and HIGHLY agree with it. Yegge is basically outlining why JavaScript is a better language than Emacs Lisp. I had the same experience with hacking on femtolisp and trying to write my shell in it. http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int... OCaml and Lisp both have problems with polymorphic print. There were some recent posts on HN about the expression problem, and the duality between FP and OOP, which I liked. But I have to say that print should be polymorphic, full stop. And if your functional language has problems with that, that's the language's problem and not my problem :) Related: http://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean http://stackoverflow.com/questions/2497801/closures-are-poor... http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

lispm 10y ago
In Common Lisp it is easy to return multiple closures. Emacs Lisp now has lexical closures, too. Common Lisp has no problems with 'polymorphic print'.
- chubot 10y ago
  Fair enough, but the appeal of Lisp to me is that it's a small axiomatic core, something that not only fits in your head, but the whole implementation fits in your head too. I wanted to use it to bootstrap languages, with no dependencies. But it turns out that this axiomatic core is too impoverished for a lot of programming. You DO need something like Common Lisp on top. And I'm not really willing to open that can of worms, both for this specific project, and in general. I would liken it to the language "Factor", which I've also experimented with... you took a specific and elegant paradigm, and tried to extend it to all paradigms, and ended up with a mess. A square peg in a round hole. Factor is basically Forth with OOP and a whole bunch of other stuff. The other problem I pointed out is that the first problem you hit when writing a language is writing a lexer. I don't see anything that Lisp offers you in that respect. I looked at how Julia does it: https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par... Julia is actually bootstrapped in femtolisp. If you look at the lexer, it just looks like C code written with Scheme syntax. There's nothing helpful about this. It doesn't help you manage state. I might as well just write C. (And actually I chose the code generator re2c, which is BETTER than C.)
  - lispm 10y ago
    > whole implementation fits in your head too Of the axiomatic core. But not of any programming language. > But it turns out that this axiomatic core is too impoverished for a lot of programming. It's not even a programming language. It's just an axiomatic core. If you try to use it for programming you must be doing something wrong. > is writing a lexer. I don't see anything that Lisp offers you in that respect. Lisp is a language family, not language implementation with a library, which happens to include a lexer library. If you mean Common Lisp as a programming language with implementations, there are portable lexers. http://www.cliki.net/LEXER http://www.cliki.net/LEXER https://github.com/drewc/smug https://github.com/drewc/smug https://github.com/lispbuilder/lispbuilder https://github.com/lispbuilder/lispbuilder Writing your own lexer in Lisp shouldn't be too hard. People have written applications in Lisp which includes lexer functionality.
    - 10y ago
Roboprog 10y ago
Back at CSU in the 80s, the Lisp exposure we had was so so. We learned about pure functions and a tiny bit about higher order functions, but that's about it. Nothing much about closures explicitly. It's funny that one of the other commenters mentioned Smalltalk and blocks. Version 5 of the "Clipper" language I was using at work, which came out around 1990, added (borrowed, stole) blocks to an "XBase" style language. I didn't quite know what to do with them, so I used them to simulate virtual method tables in a non-OOP language :-) It wasn't until I started tinkering with Ruby around 2006 or so that all the block / closure / lambda stuff REALLY sunk in ("Hmm. I could have been doing this - subroutines as closures, and not just "blank" call-backs - in all the Perl 5 code I've written the last 8 years"), some 20 years or so after I was in college. They did a good job of brainwashing proto-OOP into us back in the mid 80s. Never used any Lisp macros, but "eval" and dynamic languages sure help shorten many tasks vs static types bondage and discipline. There's another Yegge essay on that sort of thing ("code compression"). The PC "4GL" type languages I used at work in the 80s were dynamic, with runtime types, and quite productive for the jobs they were designed for (pre MS-Windows...). I'm tired of the static type authoritarians punishing us all for the sins of C/C++. (I need to stop before I go into another rant)