4 ms·

Yes, the world has been busily re-inventing (parts of) Common Lisp for 20 years. But they still haven't got one of the most important features: generic functio

by lisper 4y ago

Yes, the world has been busily re-inventing (parts of) Common Lisp for 20 years. But they still haven't got one of the most important features: generic functions, and so every programmer who doesn't use Common Lisp has to shoulder the cognitive burden of figuring out whether to write x.f(z) or f(x,z) every single time they want to invoke f. I shudder to think of the aggregate effort wasted by this additional cognitive load over all the non-Lisp code that has been written over the years.

aidenn0 4y ago
Off the top of my head, Generic Functions have these features: 1. Dynamic Dispatch 2. Multiple Dispatch 3. Auxiliary Methods 4. Namespace independent of specialization parameter(s) I find it interesting that you focus on #4. People coming to Lisp complain about #4 a lot, and people leaving lisp complain about the lack of #4. If you aren't going to use multiple dispatch (which, empirically is rare in CL code), then #4 seems to be more a matter of what one is used to. Heck, when I program in a Lisp-1, I struggle with the semantic overhead of avoiding accidentally binding a variable that happens to be the name of a function. Also, the fact that many Lispers end up writing GFs named things like widget-frobnicate and sprocket-frobnicate might indicate that coupling the namespace with the primary operand might not be completely unwanted. Also, Python is almost certainly the worst offender with consistency here -- e.g. "len(x)" vs "x.len()". P.S. C++, Javascript, and Python have libraries available implementing multiple dispatch.
- lisper 4y ago
  > many Lispers end up writing GFs named things like widget-frobnicate and sprocket-frobnicate If they do that, they're doing it wrong. Probably because they are bringing in ideas from the non-Lisp world, not realizing that these techniques are not actually good programming practice, they are strategies for dealing with deficiencies in mainstream languages. IMHO languages should be made to serve programmers. Programmers should not have to work to serve the language. So if I want to frobnicate something I want to be able to write (frobnicate the-thing) and have it Just Work. Common Lisp gives me that (when it's is used properly). No other language does. > when I program in a Lisp-1, I struggle with the semantic overhead of avoiding accidentally binding a variable that happens to be the name of a function Yes, that is why Lisp-2 is the Right Answer.
Banana699 4y ago
>the world has been busily re-inventing (parts of) Common Lisp for 20 years There is a certain sleight of hand that every lisp advocate pulls when this conversation comes : claiming that every single inspiration or language feature that is remotely related to lisp is "re-invention", with the additional implication that it's an inferior imitation. APL, Algol60, ML, Smalltalk, Simula, Prolog, Perl, Ada, Erlang and Eiffel are all extremly influential languages that all modern languages (including Lisp, ironically) are imitating and re-inventing all the time. But it's always the lispers who are obsessed with who took ideas from them, you never see smalltalkers raving about how the rest of the world took JITs, MVC and most OOP from them, or MLers about how the rest of the world learned proper static typing and module systems from them. Only lisp is that special snowflake that the PL community, countless researchers and language implementers, have been stuck helplessly imitating since 1960 and failing. "The thing about re-inventing the wheel is : you can actually do it better the second time" - Paraphrased, allegedly from one of JSON creators in response to somebody telling them they are re-inventing XML. ------- Among the endless "exclusive" features claimed for lisp are : - Homoiconity: Which Mathematica does better, with its extremly expressive and diverse syntax that nonetheless all boils down to Lists in the end. Unlike Lisp which tries to force its inferior syntax on me as a "feature", Mathematica understands that concrete syntax is not abstract syntax, the former can be (indeed, needs to be in a high level language) rich and expressive, the latter can be spartan and pure. Also Elixir. - Macros: Which countless languages does with a myriad of forms and functions. Some are : Elixir, Rust, Julia, Scala, and those are just the ones that call them "macros", AST manipulation and compile-time code reification are very general concepts that are called a lot of things in different languages. ("Templates" in Haskell, "Annotations and Annotation Processors" in Java and Groovy.) - Dynamicity: Come on, Ruby can redefine the base language from underneath you. - Image-Based Development: Fair enough, but I will politely point to Smalltalk and Erlang, and beg lispers to read some PL history before claiming that their programming languages is the O N L Y one to do so and so. - The Condition System: Also fair, and this is the only one that is truly without analog in any other programming languages I know, but it's also only in Common Lisp, not scheme or Clojure or Arc or Racket or any other lisp dialect, and it doesn't meaningfully (as far as I know) depend on "Lisp" the language, what prevents anyone from implementing it in any language they like ? What's so "Lispy" about it exactly? Lispers need to wake up to the fact that Lisp is not special in 2020. They needed to wake up to that fact since 2000, but better late than never I guess. >the cognitive burden of figuring out whether to write x.f(z) or f(x,z) every single time they want to invoke f huh ?

by lisper 4y ago

aidenn0 4y ago

Off the top of my head, Generic Functions have these features: 1. Dynamic Dispatch 2. Multiple Dispatch 3. Auxiliary Methods 4. Namespace independent of specialization parameter(s) I find it interesting that you focus on #4. People coming to Lisp complain about #4 a lot, and people leaving lisp complain about the lack of #4. If you aren't going to use multiple dispatch (which, empirically is rare in CL code), then #4 seems to be more a matter of what one is used to. Heck, when I program in a Lisp-1, I struggle with the semantic overhead of avoiding accidentally binding a variable that happens to be the name of a function. Also, the fact that many Lispers end up writing GFs named things like widget-frobnicate and sprocket-frobnicate might indicate that coupling the namespace with the primary operand might not be completely unwanted. Also, Python is almost certainly the worst offender with consistency here -- e.g. "len(x)" vs "x.len()". P.S. C++, Javascript, and Python have libraries available implementing multiple dispatch.

lisper 4y ago
> many Lispers end up writing GFs named things like widget-frobnicate and sprocket-frobnicate If they do that, they're doing it wrong. Probably because they are bringing in ideas from the non-Lisp world, not realizing that these techniques are not actually good programming practice, they are strategies for dealing with deficiencies in mainstream languages. IMHO languages should be made to serve programmers. Programmers should not have to work to serve the language. So if I want to frobnicate something I want to be able to write (frobnicate the-thing) and have it Just Work. Common Lisp gives me that (when it's is used properly). No other language does. > when I program in a Lisp-1, I struggle with the semantic overhead of avoiding accidentally binding a variable that happens to be the name of a function Yes, that is why Lisp-2 is the Right Answer.

Banana699 4y ago

>the world has been busily re-inventing (parts of) Common Lisp for 20 years There is a certain sleight of hand that every lisp advocate pulls when this conversation comes : claiming that every single inspiration or language feature that is remotely related to lisp is "re-invention", with the additional implication that it's an inferior imitation. APL, Algol60, ML, Smalltalk, Simula, Prolog, Perl, Ada, Erlang and Eiffel are all extremly influential languages that all modern languages (including Lisp, ironically) are imitating and re-inventing all the time. But it's always the lispers who are obsessed with who took ideas from them, you never see smalltalkers raving about how the rest of the world took JITs, MVC and most OOP from them, or MLers about how the rest of the world learned proper static typing and module systems from them. Only lisp is that special snowflake that the PL community, countless researchers and language implementers, have been stuck helplessly imitating since 1960 and failing. "The thing about re-inventing the wheel is : you can actually do it better the second time" - Paraphrased, allegedly from one of JSON creators in response to somebody telling them they are re-inventing XML. ------- Among the endless "exclusive" features claimed for lisp are : - Homoiconity: Which Mathematica does better, with its extremly expressive and diverse syntax that nonetheless all boils down to Lists in the end. Unlike Lisp which tries to force its inferior syntax on me as a "feature", Mathematica understands that concrete syntax is not abstract syntax, the former can be (indeed, needs to be in a high level language) rich and expressive, the latter can be spartan and pure. Also Elixir. - Macros: Which countless languages does with a myriad of forms and functions. Some are : Elixir, Rust, Julia, Scala, and those are just the ones that call them "macros", AST manipulation and compile-time code reification are very general concepts that are called a lot of things in different languages. ("Templates" in Haskell, "Annotations and Annotation Processors" in Java and Groovy.) - Dynamicity: Come on, Ruby can redefine the base language from underneath you. - Image-Based Development: Fair enough, but I will politely point to Smalltalk and Erlang, and beg lispers to read some PL history before claiming that their programming languages is the O N L Y one to do so and so. - The Condition System: Also fair, and this is the only one that is truly without analog in any other programming languages I know, but it's also only in Common Lisp, not scheme or Clojure or Arc or Racket or any other lisp dialect, and it doesn't meaningfully (as far as I know) depend on "Lisp" the language, what prevents anyone from implementing it in any language they like ? What's so "Lispy" about it exactly? Lispers need to wake up to the fact that Lisp is not special in 2020. They needed to wake up to that fact since 2000, but better late than never I guess. >the cognitive burden of figuring out whether to write x.f(z) or f(x,z) every single time they want to invoke f huh ?