Precisely. The problem with the lisps of old was entirely cultural. People would go do crazy wild things and then not bother to interoperate with the rest of the world. Meanwhile, the Clojure community has lots of experimentation, but ultimately produces a large number of stable, quality, reusable libraries.
Large scale C++ teams often require approval for operator overloading or "dangerous" features. Can easily do the same for macros. Moreover, we now have distributed version control and can utilize lieutenant workflows, so we can dispatch with this silly "commit bit" notion that means bad code sneaks in past domain experts with ease.
Lisp has been already in times when the technology you are using today was still under invention. Lisp existed before Smalltalk, C, C++, Java, ... thus often technology was developed in an unstable surrounding where inventions are just being made. Lisp also had to keep track of the changing IT landscape. During the 70s people were using DEC PDP computers.
Thus you find evidence for everything.
There are well-documented stable, nicely reusable, code bases in Lisp.
Clojure is most of the time married to a small eco-system: Java/JVM.
Lisp has seen and supported many more eco-systems and will see even more in the future.
As a language geek, I tend to hunt the Internet for old papers and manuals related to OS and languages.
The actual mainstream situation could be so different if the Xerox PARC research in terms of programming languages and OS besides the GUI, had become mainstream instead of the AT&T ones.
The Interlisp, Smalltalk and Mesa systems were great computing platforms compared with what UNIX offered.
I tend to believe that with time, good genes that were previously trimmed for very pragmatic reasons, will reappear in more favorable contexts and spread.
It might be, but I imagine having an OS where Lisp is the systems programming language is way different from a system where it is just another language.
Yeah, but that does not make it 'better' or more useful.
Lisp-based operating systems are no longer used, because they were quite complex (coming out of a research environment) and provided LESS functionality in some crucial areas (for example they were not multi-user - they were one-person, one machine, one 'world'). Additionally they were expensive.
The Xerox Lisp and Xerox Smalltalk workstations one could buy were severely underpowered (RAM, speed, ...).
I don't think you can credibly describe Java/JVM as a small ecosystem.... there's nothing else remotely close in terms of the combination of runtime platform capabilities and the number of available open source libraries.
Enabling macros is the sole justification for the homoiconic syntax, which is often cited as the most offputting feature of lisps for uptake by large programmer teams. If you're going to have two "editions" of Clojure, one with the full feature set for language designers, and the other a more restricted sans-defmacro one for more general programmer use, then why not give that restricted one a more friendly syntax as well, or even just get them to use Java, Python, or whatever.
1) I genuinely prefer variadic prefix notation, even in the absence of homoiconicity.
2) Restricted does not mean "banned". It means that they need to be justified and subject to expert scrutiny.
3) Even if you never write a macro of your own, you're a beneficiary of the syntactic sugar and can leverage macroexpand to demystify otherwise opaque language constructs.
Pet peeve, sorry, but it irritates me that Clojure people act like this guilty-until-proven-innocent policy about macros is somehow original. It has been standard advice for decades. Chapter 8 of On Lisp (1994) is called "When to Use Macros" and its first section is "When Nothing Else Will Do":
By default we should use functions: it is inelegant to use a macro where a function would do. We should use macros only when they bring us some specific advantage.
I understand from a language marketing point of view why someone might say, "Oh, those other Lisps made wild and crazy use of macros. It was really bad! But we are enlightened and have restricted them." But it's a bogus way of playing to a bogus criticism. It would be better to just say that there's a tradition of how to use macros correctly.
You paint "Clojure people" - I'm one - with a pretty broad brush. If one of us has said something you disagree with, then please cite it along with your rebuttal.
It is unlikely that you have an informed opinion of "Clojure people" on the basis of a few posts that give you heartburn.
Comments
Precisely. The problem with the lisps of old was entirely cultural. People would go do crazy wild things and then not bother to interoperate with the rest of the world. Meanwhile, the Clojure community has lots of experimentation, but ultimately produces a large number of stable, quality, reusable libraries.
Large scale C++ teams often require approval for operator overloading or "dangerous" features. Can easily do the same for macros. Moreover, we now have distributed version control and can utilize lieutenant workflows, so we can dispatch with this silly "commit bit" notion that means bad code sneaks in past domain experts with ease.
Lisp has had widely different uses:
* a teaching language
* a research tool
* an application programming language
Lisp has been already in times when the technology you are using today was still under invention. Lisp existed before Smalltalk, C, C++, Java, ... thus often technology was developed in an unstable surrounding where inventions are just being made. Lisp also had to keep track of the changing IT landscape. During the 70s people were using DEC PDP computers.
Thus you find evidence for everything.
There are well-documented stable, nicely reusable, code bases in Lisp.
Clojure is most of the time married to a small eco-system: Java/JVM.
Lisp has seen and supported many more eco-systems and will see even more in the future.
As a language geek, I tend to hunt the Internet for old papers and manuals related to OS and languages.
The actual mainstream situation could be so different if the Xerox PARC research in terms of programming languages and OS besides the GUI, had become mainstream instead of the AT&T ones.
The Interlisp, Smalltalk and Mesa systems were great computing platforms compared with what UNIX offered.
I tend to believe that with time, good genes that were previously trimmed for very pragmatic reasons, will reappear in more favorable contexts and spread.
Still Lisp was on Unix on day two and was always a very popular platform for Lisp developers.
You could even get Lisp Machines from TI with embedded Unix and Lisp Machines from TI and Symbolics which were embedded in Unix.
Several Lisp companies made their entire business from Unix: Lucid, early Franz, early Harlequin/LispWorks, ...
It might be, but I imagine having an OS where Lisp is the systems programming language is way different from a system where it is just another language.
Yeah, but that does not make it 'better' or more useful.
Lisp-based operating systems are no longer used, because they were quite complex (coming out of a research environment) and provided LESS functionality in some crucial areas (for example they were not multi-user - they were one-person, one machine, one 'world'). Additionally they were expensive.
The Xerox Lisp and Xerox Smalltalk workstations one could buy were severely underpowered (RAM, speed, ...).
I don't think you can credibly describe Java/JVM as a small ecosystem.... there's nothing else remotely close in terms of the combination of runtime platform capabilities and the number of available open source libraries.
Enabling macros is the sole justification for the homoiconic syntax, which is often cited as the most offputting feature of lisps for uptake by large programmer teams. If you're going to have two "editions" of Clojure, one with the full feature set for language designers, and the other a more restricted sans-defmacro one for more general programmer use, then why not give that restricted one a more friendly syntax as well, or even just get them to use Java, Python, or whatever.
1) I genuinely prefer variadic prefix notation, even in the absence of homoiconicity.
2) Restricted does not mean "banned". It means that they need to be justified and subject to expert scrutiny.
3) Even if you never write a macro of your own, you're a beneficiary of the syntactic sugar and can leverage macroexpand to demystify otherwise opaque language constructs.
Pet peeve, sorry, but it irritates me that Clojure people act like this guilty-until-proven-innocent policy about macros is somehow original. It has been standard advice for decades. Chapter 8 of On Lisp (1994) is called "When to Use Macros" and its first section is "When Nothing Else Will Do":
By default we should use functions: it is inelegant to use a macro where a function would do. We should use macros only when they bring us some specific advantage.
I understand from a language marketing point of view why someone might say, "Oh, those other Lisps made wild and crazy use of macros. It was really bad! But we are enlightened and have restricted them." But it's a bogus way of playing to a bogus criticism. It would be better to just say that there's a tradition of how to use macros correctly.
Please name a language you use so that whenever you and I disagree I'll be able to cite the "Blub people".
Not sure what your point is? I'd be happy to be wrong here.
You paint "Clojure people" - I'm one - with a pretty broad brush. If one of us has said something you disagree with, then please cite it along with your rebuttal.
It is unlikely that you have an informed opinion of "Clojure people" on the basis of a few posts that give you heartburn.
Uh, I think maybe I'd better just quit while I'm behind.