3 ms·

The forty years of a teaching language comes with a cost: zillions of incompatible implementtions and a language which was designed for teaching, retrofitted wi

by lispm 9y ago

The forty years of a teaching language comes with a cost: zillions of incompatible implementtions and a language which was designed for teaching, retrofitted with more advanced stuff on top which integrate not very well. Common Lisp was designed early as a more practical language. Take for example error handling: Common Lisp has a nice error handling system integrated into the language since the mid 80s. Scheme never had something comparable specified in its standards. Sure you can add error handling on top, but it won't be integrated well into the wider language. There are many aspects where Scheme was underspecified for decades and efforts to redesign the core language were slow, controversial and not really providing nice results. Many Scheme designers wanted the language to be kept as small as possible (R5RS level). The R6RS design was controversial and R7RS 'large' is a very slow effort... In many ways, Common Lisp is as a practical Lisp language better designed than the average Scheme and Racket is just another Scheme going in its own direction. Actually if you read the Racket docs, it is a very complex system. One also could use the excellent Chez Scheme (which now is open source) or Chicken Scheme. The ideas of Racket onboarding beginners is also confusing: multiple languages with some integration mechanism with various degrees of different features and semantics. Much of that is not really needed, but a nice experiment in language modularity. Added to that an IDE which favors batch programming for beginners... In a teaching setting it helps reducing side-effects ... each 'Run' is a new program start.

brudgers 9y ago
To me, Racket does not suffer from the issues of incompatibility that occur with Scheme as a general family of languages because cross platform compatibility is sought at the ecosystem level rather than at the level of each individual user source code file. That is why I recommended the Racket ecosystem specifically rather than making a vague reference to Scheme. To be clear, I think Common Lisp is a great language and in no small part this is due to the stability that its design by consensus and reference standard over approximately a decade by a group of seriously competent programmers and computer scientists. The price of Common Lisp is the RTFM tradition of onboarding users, TANSTAAFL. I agree that Racket ecosystem is complex. There is a valley that contains the basic abstractions of Erlang [1] and Algol Mesa is accessible right out of the box and Scribble for writing documentation. Of course, the fact that all that complexity is documented in the standard distribution (and generally very well documented) is [at least for me] a feature not a bug. Finally, my current take is that 'easy' onboarding of users is a bait and switch for any programming language [2]. Eventually there is an inflection point where the answer is RTFM. It just comes earlier or later in different language communities. With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language. [1]: http://docs.racket-lang.org/guide/parallelism.html#%28part._effective-places%29 http://docs.racket-lang.org/guide/parallelism.html#%28part._... [2]: http://norvig.com/21-days.html http://norvig.com/21-days.html
- lispm 9y ago
  > Racket does not suffer from the issues of incompatibility Just pick any language implementation exclusively -> no more incompatibilities. > With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language. Well Steele's Common Lisp the Language is outdated anyway. Today one uses the ANSI CL standard, which is less confusing than CLtL2, which was documenting a language in flux. Actually I don't think Common Lisp users will need to refer to documentation earlier than Racket or any other complex programming system (Java, Scala, Haskell, ...). I have seen now a lot of people coding Java and I can tell you that documentation-less attempts at development don't work well. Many of the programs and coding styles I have seen are just horrible. It's actually kind of sad. I have seen senior Java developers not knowing how the language works at basic levels, even though they claim to work with complex frameworks. Recently I have interviewed a professional Java programmer with a few years experience and he had lots of free time at work. He could have read some books to learn something instead of looking out of the window, but he said that he wasn't interested in computer science anyway... though it might have been a joke, I fear it was serious... Anyway, he was a nice person and had some potential.
  - pjmlp 9y ago
    You are kind of right, the problema is when that great library that would solve your problem that should already been written last week, doesn't work with your implementation of choice. This is one of the reasons I started to only use vendor SDK languages for production code, in spite of the languages not being as good as some alternatives.
  - brudgers 9y ago
    There are a host of good reasons not to choose Racket. An intent to explore the Lisp family of languages is not among those within a standard deviation or two of the median. Likewise approaching the Lisp family of languages with tooling expectations in the fat part of today's Bell Curve probably makes Common Lisp a more frustrating tool than is necessary. In different circumstances, the value of tradeoffs would be different...for example reading an ANSI Standard might be perfectly acceptable as an alternative despite being on the long tail of ordinary practice for someone coming from "the JS, Java, Python world" -- with particular attention to the ECMAscript standard.

by lispm 9y ago

brudgers 9y ago

To me, Racket does not suffer from the issues of incompatibility that occur with Scheme as a general family of languages because cross platform compatibility is sought at the ecosystem level rather than at the level of each individual user source code file. That is why I recommended the Racket ecosystem specifically rather than making a vague reference to Scheme. To be clear, I think Common Lisp is a great language and in no small part this is due to the stability that its design by consensus and reference standard over approximately a decade by a group of seriously competent programmers and computer scientists. The price of Common Lisp is the RTFM tradition of onboarding users, TANSTAAFL. I agree that Racket ecosystem is complex. There is a valley that contains the basic abstractions of Erlang [1] and Algol Mesa is accessible right out of the box and Scribble for writing documentation. Of course, the fact that all that complexity is documented in the standard distribution (and generally very well documented) is [at least for me] a feature not a bug. Finally, my current take is that 'easy' onboarding of users is a bait and switch for any programming language [2]. Eventually there is an inflection point where the answer is RTFM. It just comes earlier or later in different language communities. With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language. [1]: http://docs.racket-lang.org/guide/parallelism.html#%28part._effective-places%29 http://docs.racket-lang.org/guide/parallelism.html#%28part._... [2]: http://norvig.com/21-days.html http://norvig.com/21-days.html

lispm 9y ago
> Racket does not suffer from the issues of incompatibility Just pick any language implementation exclusively -> no more incompatibilities. > With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language. Well Steele's Common Lisp the Language is outdated anyway. Today one uses the ANSI CL standard, which is less confusing than CLtL2, which was documenting a language in flux. Actually I don't think Common Lisp users will need to refer to documentation earlier than Racket or any other complex programming system (Java, Scala, Haskell, ...). I have seen now a lot of people coding Java and I can tell you that documentation-less attempts at development don't work well. Many of the programs and coding styles I have seen are just horrible. It's actually kind of sad. I have seen senior Java developers not knowing how the language works at basic levels, even though they claim to work with complex frameworks. Recently I have interviewed a professional Java programmer with a few years experience and he had lots of free time at work. He could have read some books to learn something instead of looking out of the window, but he said that he wasn't interested in computer science anyway... though it might have been a joke, I fear it was serious... Anyway, he was a nice person and had some potential.
- pjmlp 9y ago
  You are kind of right, the problema is when that great library that would solve your problem that should already been written last week, doesn't work with your implementation of choice. This is one of the reasons I started to only use vendor SDK languages for production code, in spite of the languages not being as good as some alternatives.
- brudgers 9y ago
  There are a host of good reasons not to choose Racket. An intent to explore the Lisp family of languages is not among those within a standard deviation or two of the median. Likewise approaching the Lisp family of languages with tooling expectations in the fat part of today's Bell Curve probably makes Common Lisp a more frustrating tool than is necessary. In different circumstances, the value of tradeoffs would be different...for example reading an ANSI Standard might be perfectly acceptable as an alternative despite being on the long tail of ordinary practice for someone coming from "the JS, Java, Python world" -- with particular attention to the ECMAscript standard.