7 ms·

This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :) (And this is probably Lisp's greatest weakness as well – wi

by nnq 13y ago

This sums up quite a lot about Lisps in general. I'm amazed OP got so fast to this "insight" :) (And this is probably Lisp's greatest weakness as well – with this level of possible diversity, everyone has to use the “common lowest denominator” simply because nobody can agree on what alternative syntax / library / etc. is better and should be used.) Off-topic: it's not enough to give everyone opportunity to improve the language; you have to choose the winners and promote them heavily. The rules of free market don't work here; people won't use the best thing, they'll use the one which is available out of the box and which is used by their peers.

grn 13y ago
That's very true and I think that it's related to the topic of Rich Hickey's talk Simple Made Easy [1]. Maybe what we need is to study the economics of software and come up with a system in which market outcome is promotion of good libraries. I think that the social/economic dynamics of software development play a huge role in building a successful product, both free and commercial. Has anyone studied the subject in greater detail? [1] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
pavelludiq 13y ago
As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats good for teaching and research, and possibly even real work(tm). Classic scheme unfortunately is fragmented into implementations who all do things slightly differently and occupy their own niches. In the clojure world, they have a) a BDFL who sets the course of the language. b) A very strong core community of very smart people who managed to build a nice culture based on common ideas about software and design. In the common lisp world, because we have a very high-quality standard, implementations are almost completely compatible. Compatibility libraries make it easy to write very portable code, avoiding the scheme problem. At the same time implementations are free to experiment. The other problem of everybody developing their own little universe tends to be rare. Because common lisp is so old, we have a long history and traditions that guide future design, but don't constrict it. There is a subtle balance here. We have a lot of old examples to learn from, but we are not locked in by too many bad old decisions(not always the case, but good enough in practice). A few examples where this does not work include utility libraries and things like json libraries, libraries for outputing html etc. Since we don't have a BDFL we are left to figure things out amongst our selves and sometimes, like with utility libraries(there are dozens such, which is ridiculus) it doesn't work. In other cases, it works very well, for example quicklisp, ASDF, bordeaux-threads, closer-mop, hunchentoot etc. are either de-facto standards, or sufficiently popular to be a very good default. As with clojure, there are a lot of common ideas about what is good design in the community, we have a lot of examples to learn from, as I mentioned. In the end, at least in the case of common lisp and clojure, I see it as an advantage to have this "level of possible diversity", it's what has kept lisp alive for 50+ years! The fact that lisp can adopt to each new era of software development philosophy is a great reason to study it. It will be with us for many more decades because of this.
- oblio 13y ago
  At this point we can safely say that any programming language will be with us for many decades. Cobol (http://en.wikipedia.org/wiki/Cobol#COBOL_20XX http://en.wikipedia.org/wiki/Cobol#COBOL_20XX), Fortran (http://en.wikipedia.org/wiki/Fortran#Fortran_2015 http://en.wikipedia.org/wiki/Fortran#Fortran_2015), Basic (http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12.0.29 http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12...) are still evolving. Heck, Python is already 23 years old and I don't see it going anywhere. I'm not even going to talk about the ubiquitous C/C++ or Java, as they'll probably be around long after we're dead. Adaption is neat, but I don't see this argument as being a very solid argument in favor of Lisp - it's just the norm.
  - sp332 13y ago
    I think you're just conveniently forgetting all the languages that didn't go anywhere. https://en.wikipedia.org/wiki/Timeline_of_programming_languages https://en.wikipedia.org/wiki/Timeline_of_programming_langua...
- PeterisP 13y ago
  To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.
  - pavelludiq 13y ago
    Show me a language with >1 implementation where at least two are completely compatible. Common Lisp has one of the best track records in this aspect. C, C++ and JavaScript are all far worse.
  - TheLoneWolfling 13y ago
    Not necessarily. Java 6 and 7 are "almost completely compatible". Most programs written in Java 6 will run in Java 7, and vice versa. But not all.
    - 13y ago
artyomkazak 13y ago
I think this was a cached thought – a year ago I was reading a bit about Lisp and probably had stumbled upon what is known as the Lisp Curse.
Dewie 13y ago
I dream of a modular language in which languages, or dialects, can be built from a small base language, which can then be extended, and so on. Of the languages that I've seen, Racket looks the most promising. Forth might be good for this, too, but to build large hierarchies of languages seems the antithesis of Forth - or at least, Chuck Moore's - philosophy. On the other hand, such a language might just end up as an incredibly fragmented mess of different languages, with little interoperability between languages - some one makes a 'typed' version of the language, another takes that version and tunes it just enough for it to be incompatible with the original version and, in turn, all languages that are built on top of that original typed language, and so on. Maybe incredible modularity is fundamentally at odds with (social) interoperability.
- dmytrish 13y ago
  It's ironic that Haskell is such a language: it grows from a tight, small core into larger and greater abilities as you learn it even without using its extensions. I agree that Common Lisp a very powerful language, but I can't live with all that power uncontrollably thrown on me. Common Lisp grossly lacks self-discipline and self-limitation when it's needed.
  - sparkie 13y ago
    I suspect the parent thread was dreaming of a framework where languages with arbitrary syntax can be mixed and matched in user-defined ways. Haskell isn't necessarily that language, partly because it still requires centralized coordination of development of these "extensions" to ensure they're interoperable - that is, there is only one parser for the language and its supported extensions, and many of them are build into the compiler rather than added as libraries, except those extensions which are done through quasi-quotation, such as with MetaHaskell, or some EDSL. Even that has it's own problems, and you'll have issues parsing if your quoted language happens to have delimiters which conflict with Haskell's quasiquoting delimiters `[| |]` - producing syntax which cannot be parsed unambiguously (perhaps very rare or unlikely though). Perhaps the biggest hurdle of having a modular language is that we do not understand how unambiguously parse the combination of two or more syntaxes. We only know that composition of two CFGs results in another CFG, but with no guarantee of unambiguity, and other parsers such as PEG rely on ordered choice, where the computer can't decide which choice you really want. What makes lisps great for composition of languages (or "EDSLs" in market speak), is that it bypasses the parsing problem by asking you to just write your language directly in terms of the syntax tree which a parser would generate - and perhaps use macros or other functions to simplify the use of that tree. Instead of a language being vocabulary+syntax, we create new vocabulary for what would be done through syntax in other languages - and we can thus refer to it unambiguously. Similar can be done in haskell too, through regular functions and quotation. The parse problem is only really a problem because we're stuck with this silly model of "sequential text files" to describe code, and we're required to limit our languages such that a parser can take one of these text files and make sense of it. When we break out of this model, and use intelligent editors, we can reach the point where syntaxes can be composed arbitrarily, because we can indicate where each new syntax begins and ends. Diekmann and Tratt have demonstrated how this can be done while still appearing much like traditional text editing, which they call Language Boxes.[1][2] Language Boxes only provide the means to compose syntaxes, but handling the semantic composition of languages is left to the authors of the languages which are being composed. Haskell is perhaps a good choice of language for providing the kind of glue needed here, where we can decide where languages can be composed based on the types returned by their parsers. [1]:https://www.youtube.com/watch?v=LMzrTb22Ot8 https://www.youtube.com/watch?v=LMzrTb22Ot8, [2]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_composed_grammars_with_language_boxes.pdf http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...

by nnq 13y ago

grn 13y ago

That's very true and I think that it's related to the topic of Rich Hickey's talk Simple Made Easy [1]. Maybe what we need is to study the economics of software and come up with a system in which market outcome is promotion of good libraries. I think that the social/economic dynamics of software development play a huge role in building a successful product, both free and commercial. Has anyone studied the subject in greater detail? [1] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

pavelludiq 13y ago

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways. In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats good for teaching and research, and possibly even real work(tm). Classic scheme unfortunately is fragmented into implementations who all do things slightly differently and occupy their own niches. In the clojure world, they have a) a BDFL who sets the course of the language. b) A very strong core community of very smart people who managed to build a nice culture based on common ideas about software and design. In the common lisp world, because we have a very high-quality standard, implementations are almost completely compatible. Compatibility libraries make it easy to write very portable code, avoiding the scheme problem. At the same time implementations are free to experiment. The other problem of everybody developing their own little universe tends to be rare. Because common lisp is so old, we have a long history and traditions that guide future design, but don't constrict it. There is a subtle balance here. We have a lot of old examples to learn from, but we are not locked in by too many bad old decisions(not always the case, but good enough in practice). A few examples where this does not work include utility libraries and things like json libraries, libraries for outputing html etc. Since we don't have a BDFL we are left to figure things out amongst our selves and sometimes, like with utility libraries(there are dozens such, which is ridiculus) it doesn't work. In other cases, it works very well, for example quicklisp, ASDF, bordeaux-threads, closer-mop, hunchentoot etc. are either de-facto standards, or sufficiently popular to be a very good default. As with clojure, there are a lot of common ideas about what is good design in the community, we have a lot of examples to learn from, as I mentioned. In the end, at least in the case of common lisp and clojure, I see it as an advantage to have this "level of possible diversity", it's what has kept lisp alive for 50+ years! The fact that lisp can adopt to each new era of software development philosophy is a great reason to study it. It will be with us for many more decades because of this.

oblio 13y ago
At this point we can safely say that any programming language will be with us for many decades. Cobol (http://en.wikipedia.org/wiki/Cobol#COBOL_20XX http://en.wikipedia.org/wiki/Cobol#COBOL_20XX), Fortran (http://en.wikipedia.org/wiki/Fortran#Fortran_2015 http://en.wikipedia.org/wiki/Fortran#Fortran_2015), Basic (http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12.0.29 http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12...) are still evolving. Heck, Python is already 23 years old and I don't see it going anywhere. I'm not even going to talk about the ubiquitous C/C++ or Java, as they'll probably be around long after we're dead. Adaption is neat, but I don't see this argument as being a very solid argument in favor of Lisp - it's just the norm.
- sp332 13y ago
  I think you're just conveniently forgetting all the languages that didn't go anywhere. https://en.wikipedia.org/wiki/Timeline_of_programming_languages https://en.wikipedia.org/wiki/Timeline_of_programming_langua...
PeterisP 13y ago
To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.
- pavelludiq 13y ago
  Show me a language with >1 implementation where at least two are completely compatible. Common Lisp has one of the best track records in this aspect. C, C++ and JavaScript are all far worse.
- TheLoneWolfling 13y ago
  Not necessarily. Java 6 and 7 are "almost completely compatible". Most programs written in Java 6 will run in Java 7, and vice versa. But not all.
  - 13y ago

artyomkazak 13y ago

I think this was a cached thought – a year ago I was reading a bit about Lisp and probably had stumbled upon what is known as the Lisp Curse.

Dewie 13y ago

I dream of a modular language in which languages, or dialects, can be built from a small base language, which can then be extended, and so on. Of the languages that I've seen, Racket looks the most promising. Forth might be good for this, too, but to build large hierarchies of languages seems the antithesis of Forth - or at least, Chuck Moore's - philosophy. On the other hand, such a language might just end up as an incredibly fragmented mess of different languages, with little interoperability between languages - some one makes a 'typed' version of the language, another takes that version and tunes it just enough for it to be incompatible with the original version and, in turn, all languages that are built on top of that original typed language, and so on. Maybe incredible modularity is fundamentally at odds with (social) interoperability.

dmytrish 13y ago
It's ironic that Haskell is such a language: it grows from a tight, small core into larger and greater abilities as you learn it even without using its extensions. I agree that Common Lisp a very powerful language, but I can't live with all that power uncontrollably thrown on me. Common Lisp grossly lacks self-discipline and self-limitation when it's needed.
- sparkie 13y ago
  I suspect the parent thread was dreaming of a framework where languages with arbitrary syntax can be mixed and matched in user-defined ways. Haskell isn't necessarily that language, partly because it still requires centralized coordination of development of these "extensions" to ensure they're interoperable - that is, there is only one parser for the language and its supported extensions, and many of them are build into the compiler rather than added as libraries, except those extensions which are done through quasi-quotation, such as with MetaHaskell, or some EDSL. Even that has it's own problems, and you'll have issues parsing if your quoted language happens to have delimiters which conflict with Haskell's quasiquoting delimiters `[| |]` - producing syntax which cannot be parsed unambiguously (perhaps very rare or unlikely though). Perhaps the biggest hurdle of having a modular language is that we do not understand how unambiguously parse the combination of two or more syntaxes. We only know that composition of two CFGs results in another CFG, but with no guarantee of unambiguity, and other parsers such as PEG rely on ordered choice, where the computer can't decide which choice you really want. What makes lisps great for composition of languages (or "EDSLs" in market speak), is that it bypasses the parsing problem by asking you to just write your language directly in terms of the syntax tree which a parser would generate - and perhaps use macros or other functions to simplify the use of that tree. Instead of a language being vocabulary+syntax, we create new vocabulary for what would be done through syntax in other languages - and we can thus refer to it unambiguously. Similar can be done in haskell too, through regular functions and quotation. The parse problem is only really a problem because we're stuck with this silly model of "sequential text files" to describe code, and we're required to limit our languages such that a parser can take one of these text files and make sense of it. When we break out of this model, and use intelligent editors, we can reach the point where syntaxes can be composed arbitrarily, because we can indicate where each new syntax begins and ends. Diekmann and Tratt have demonstrated how this can be done while still appearing much like traditional text editing, which they call Language Boxes.[1][2] Language Boxes only provide the means to compose syntaxes, but handling the semantic composition of languages is left to the authors of the languages which are being composed. Haskell is perhaps a good choice of language for providing the kind of glue needed here, where we can decide where languages can be composed based on the types returned by their parsers. [1]:https://www.youtube.com/watch?v=LMzrTb22Ot8 https://www.youtube.com/watch?v=LMzrTb22Ot8, [2]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_composed_grammars_with_language_boxes.pdf http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...