4 ms·

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they h

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 20 years.

submeta 4y ago
> You could say the same about Java and 20 years. Or even COBOL and 40 or 50 years. What does that even prove. Edit: Typo
Hirrolot 4y ago
> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent the language so much (via macros, type system, etc.) so it's no longer like a bare language that was before. But I appreciate your point that macros can add cognitive burden in many cases where less powerful (and more easily understandable) mechanisms would suffice.
deleted 4y ago
[deleted]
akira2501 4y ago
> they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?
- dehrmann 4y ago
  Qt and React have been used for years by lots of people, so there's a lot of knowledge out there about them, their designs are more general-purpose and refined, and you're likely to have encountered them before.
- Capricorn2481 4y ago
  Yes. Because React has documentation and in-house Lisp almost never does
JonChesterfield 4y ago
> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? Yes. To both. All programming involves building up sets of abstractions that make sense to the domain. A new project usually means a whole new load of abstractions. If the language is opinionated about that, there's a good chance they'll be similar to other projects. Python, Java come to mind. C++ is heading in that broad direction. Most languages make application abstractions and language abstractions look different. Sometimes the standard library looks deliberately different as well. This seems to be the popular path. Common lisp has an inconsistent stdlib. Scheme has a small one. Both draw a distinction between builtins (which get weird indentation and syntax highlighting) and functions, but it's not as big a visual distinction as other languages. Both let you add a function which normally looks like other functions at the call site but has weird semantics and the special name macro. This is approximately making extensions look the same as builtins. Mixed with that, there's a credible risk of having limited continuations, or ideally delimited continuations, which are a complicated control flow construct. There's some risk of having first class environments. Also the character stream might get munged by reader macros before anything happens to it. You will have the compiler available at runtime and probably have weird phase separation hooks. If you combine leaky syntax abstraction (the macros), reified continuations and environments you get something very expressive with interesting composition challenges for greater than zero developers. The enterprisey lisp, clojure, drops a lot of power and adds a lot of convention. Kernel fixes the inconsistency in macros. It also goes with first class environments, which are the sane thing to do for module systems. I don't remember if it has reified continuations. The lambda calculus with environment style symbol lookup is a really nice core for a programming language. Lisp is about as close to that as any.
vindarel 4y ago
It's that you can do a lot with macros, at compile time -with all the language at hand, not a subset. https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-3-scientific-units-8e41d8a727ca https://medium.com/@MartinCracauer/a-gentle-introduction-to-... https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a https://medium.com/@MartinCracauer/static-type-checking-in-t...
varjag 4y ago
> You could say the same about Java and 20 years. Really doubt you'll get your EJB project from the day going now without major rework.
- whartung 4y ago
  Not necessarily. The biggest rock in the pond recently is the Great Renaming to Jakarta, but many containers still support the older package names. The only real legacy stuff from 20 years ago that has truly died on the vine is Entity Beans. But even then, Entity Beans we’re mostly horrible, and not many folks used them. But they may well still be supported in some modern containers. That said the old style way of using XML for everything (notably declarations of Session Beans and such) still exists today. Annotations rule the day today, but the old XML style still exists, and has not been deprecated, or if it has, it’s quite recently. There is in fact a lot of backward compatibility stuff still there in the modern containers because fundamentally the concepts have not changed, just how they are expressed in modern runtimes.
erik_seaberg 4y ago
We should be optimizing for committed experts to work and communicate concisely, not occasional drive-by contributors.

submeta 4y ago

> You could say the same about Java and 20 years. Or even COBOL and 40 or 50 years. What does that even prove. Edit: Typo

Hirrolot 4y ago

> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent the language so much (via macros, type system, etc.) so it's no longer like a bare language that was before. But I appreciate your point that macros can add cognitive burden in many cases where less powerful (and more easily understandable) mechanisms would suffice.

deleted 4y ago

[deleted]

akira2501 4y ago

> they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?

dehrmann 4y ago
Qt and React have been used for years by lots of people, so there's a lot of knowledge out there about them, their designs are more general-purpose and refined, and you're likely to have encountered them before.
Capricorn2481 4y ago
Yes. Because React has documentation and in-house Lisp almost never does

JonChesterfield 4y ago

> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? Yes. To both. All programming involves building up sets of abstractions that make sense to the domain. A new project usually means a whole new load of abstractions. If the language is opinionated about that, there's a good chance they'll be similar to other projects. Python, Java come to mind. C++ is heading in that broad direction. Most languages make application abstractions and language abstractions look different. Sometimes the standard library looks deliberately different as well. This seems to be the popular path. Common lisp has an inconsistent stdlib. Scheme has a small one. Both draw a distinction between builtins (which get weird indentation and syntax highlighting) and functions, but it's not as big a visual distinction as other languages. Both let you add a function which normally looks like other functions at the call site but has weird semantics and the special name macro. This is approximately making extensions look the same as builtins. Mixed with that, there's a credible risk of having limited continuations, or ideally delimited continuations, which are a complicated control flow construct. There's some risk of having first class environments. Also the character stream might get munged by reader macros before anything happens to it. You will have the compiler available at runtime and probably have weird phase separation hooks. If you combine leaky syntax abstraction (the macros), reified continuations and environments you get something very expressive with interesting composition challenges for greater than zero developers. The enterprisey lisp, clojure, drops a lot of power and adds a lot of convention. Kernel fixes the inconsistency in macros. It also goes with first class environments, which are the sane thing to do for module systems. I don't remember if it has reified continuations. The lambda calculus with environment style symbol lookup is a really nice core for a programming language. Lisp is about as close to that as any.

vindarel 4y ago

It's that you can do a lot with macros, at compile time -with all the language at hand, not a subset. https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-3-scientific-units-8e41d8a727ca https://medium.com/@MartinCracauer/a-gentle-introduction-to-... https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a https://medium.com/@MartinCracauer/static-type-checking-in-t...

varjag 4y ago

> You could say the same about Java and 20 years. Really doubt you'll get your EJB project from the day going now without major rework.

whartung 4y ago
Not necessarily. The biggest rock in the pond recently is the Great Renaming to Jakarta, but many containers still support the older package names. The only real legacy stuff from 20 years ago that has truly died on the vine is Entity Beans. But even then, Entity Beans we’re mostly horrible, and not many folks used them. But they may well still be supported in some modern containers. That said the old style way of using XML for everything (notably declarations of Session Beans and such) still exists today. Annotations rule the day today, but the old XML style still exists, and has not been deprecated, or if it has, it’s quite recently. There is in fact a lot of backward compatibility stuff still there in the modern containers because fundamentally the concepts have not changed, just how they are expressed in modern runtimes.

erik_seaberg 4y ago

We should be optimizing for committed experts to work and communicate concisely, not occasional drive-by contributors.