3 ms·

I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't com

by lispm 3y ago

I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ... > entry for 'kludges' That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especially Guy L Steele. For example Dave Moon said about the search for a name for the language: "...whatever we call this common Lisp" and this time, among great sadness and consternation that a better name could not be had, it was selected."

Paul-Craft 3y ago
> That's a form of self-deprecating humor, if you missed it. No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.
- lispm 3y ago
  Scheme is from 1975 with huge influences from Lisp -> 48 years. Sussman is 76, Steele is 68. I don't think it's a only a problem of Common Lisp, which, btw., is younger than Scheme (which wasn't created completely new in a vacuum). The Scheme Report revisions upto R5RS for example ignored a lot of practical problems (no error handling, no namespaces, no object system, ...). The kludges then were outside of the language definition. But having no error handling in the language definition is not better than having one with less than ideal integration into the language. It's just a different way to deal with the problem of features which need a deep language integration: writing a larger standard with compromises or just pretend that one defines a language primarily for teaching computer science concepts (and which lacks really necessary features like error handling). The language definition then should only have as many (very dense) pages, as a student could handle in introductory course. R6RS was an attempt to get a more complete language, which then kind of failed and was controversial amongst users and implementors. I'd think, a to defined a language with kludges, but which tries to address practical problems, is a respectable and useful approach. Being self-aware that not everything is ideal is also nothing to look down to.

by lispm 3y ago

Paul-Craft 3y ago

> That's a form of self-deprecating humor, if you missed it. No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.

lispm 3y ago
Scheme is from 1975 with huge influences from Lisp -> 48 years. Sussman is 76, Steele is 68. I don't think it's a only a problem of Common Lisp, which, btw., is younger than Scheme (which wasn't created completely new in a vacuum). The Scheme Report revisions upto R5RS for example ignored a lot of practical problems (no error handling, no namespaces, no object system, ...). The kludges then were outside of the language definition. But having no error handling in the language definition is not better than having one with less than ideal integration into the language. It's just a different way to deal with the problem of features which need a deep language integration: writing a larger standard with compromises or just pretend that one defines a language primarily for teaching computer science concepts (and which lacks really necessary features like error handling). The language definition then should only have as many (very dense) pages, as a student could handle in introductory course. R6RS was an attempt to get a more complete language, which then kind of failed and was controversial amongst users and implementors. I'd think, a to defined a language with kludges, but which tries to address practical problems, is a respectable and useful approach. Being self-aware that not everything is ideal is also nothing to look down to.