3 ms·

> people talking about having to learn a new LISP (or Scheme) each time they switch to a different company. Which people, where? Do you have a URL to a discuss

> people talking about having to learn a new LISP (or Scheme) each time they switch to a different company. Which people, where? Do you have a URL to a discussion? I've not seen heard or read such talk almost 25 years of being involved in open source Lisp. Needless to say, I've often seen such narrative repeated by programmers not working in Lisp, who heard it from such others. Someone talking about any industry work in Lisp whatsoever, even just one job, from any angle, is extremely rare.

shagie 2y ago
It's a browsing about https://wiki.c2.com/?WhyWeHateLisp https://wiki.c2.com/?WhyWeHateLisp And that does get into the "25 years ago" area. Really neat place to browse and see as a historical record of discussion from back then. The issue is that languages that allow/encourage writing domain specific languages within the environment leads to people doing exactly that - writing a DSL that is then used in that company. Lisp, Ruby, Groovy, Raku (possible in perl 5 as demonstrated by https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/Lingua/Romana/Perligata.pm https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L... )... These languages (and Scala too) allow for writing a dialect of the language that differs substantially from the main language. I've seen it in ruby. I've personally done it in groovy (wrote categories to make certain reports easier to write)... twice (also wrote a DSL in groovy that matches the script used as input for powershell doing ftp so that instead of `ftp.ps1 script` it looked like "add this import to the top of the script and do `groovy script`")... for that matter gradle is a groovy script that has gone well beyond groovy as a DSL. Just as the problem existed with "having to learn a new LISP dialect" 25 years ago, many times going from languages that allow for such flexibility in how its written from one shop to another have the "having to learn a new {language} dialect" today. For code that I have to work on with someone else, I believe it is better/easier to work in a language that doesn't allow you to rewrite the language so that when I have to work with yet another person, they don't need to learn a completely different way of doing it from what they knew previously.

shagie 2y ago

It's a browsing about https://wiki.c2.com/?WhyWeHateLisp https://wiki.c2.com/?WhyWeHateLisp And that does get into the "25 years ago" area. Really neat place to browse and see as a historical record of discussion from back then. The issue is that languages that allow/encourage writing domain specific languages within the environment leads to people doing exactly that - writing a DSL that is then used in that company. Lisp, Ruby, Groovy, Raku (possible in perl 5 as demonstrated by https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/Lingua/Romana/Perligata.pm https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L... )... These languages (and Scala too) allow for writing a dialect of the language that differs substantially from the main language. I've seen it in ruby. I've personally done it in groovy (wrote categories to make certain reports easier to write)... twice (also wrote a DSL in groovy that matches the script used as input for powershell doing ftp so that instead of `ftp.ps1 script` it looked like "add this import to the top of the script and do `groovy script`")... for that matter gradle is a groovy script that has gone well beyond groovy as a DSL. Just as the problem existed with "having to learn a new LISP dialect" 25 years ago, many times going from languages that allow for such flexibility in how its written from one shop to another have the "having to learn a new {language} dialect" today. For code that I have to work on with someone else, I believe it is better/easier to work in a language that doesn't allow you to rewrite the language so that when I have to work with yet another person, they don't need to learn a completely different way of doing it from what they knew previously.