A common remark I find on websites is that "Scheme is a heavily academic language by nature while Common Lisp is geared more for real world development". I've read this more than a few times, actually.
Why do people seem to frequently make this remark?
> A common remark I find on websites is that "Scheme is a heavily > academic language by nature while Common Lisp is geared more for real > world development". I've read this more than a few times, actually.
> Why do people seem to frequently make this remark?
Some entity, AKA "Griff" <gret...@gmail.com>, wrote this mindboggling stuff: (selectively-snipped-or-not-p)
> Why do people seem to frequently make this remark?
Because it is so much easier to get people wasting time on triviality urging them to do something usefull takes more.
Cor
-- The biggest problem LISP has is that it does not apeal to dumb people If this failed to satisfy you try reading the HyperSpec or woman frig (defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux"))) Read the policy before mailing http://www.clsnet.nl/mail.html
"Griff" <gret...@gmail.com> writes: > A common remark I find on websites is that "Scheme is a heavily > academic language by nature while Common Lisp is geared more for real > world development". I've read this more than a few times, actually.
Scheme is frequently applied to secondary- and university-level teaching. Common Lisp is frequently applied in industry. It is a truth universally acknowledged that if a computer language is frequently used in a given area, then that area is what the language is geared for.
> A common remark I find on websites is that "Scheme is a heavily > academic language by nature while Common Lisp is geared more for real > world development". I've read this more than a few times, actually.
> Why do people seem to frequently make this remark?
> Regards,
> Grant
[Since this topic is historically flamebait and I'm going to express actual opinions, I'd like to take this moment to ask everyone to respond calmly if at all. I'm trying to be fair to both languages]
Scheme has historically striven to be a minimal, complete, consistent, multiparadigm language. That means the standards have been very short relative to other languages, covering relatively few concepts and structures but making sure that the semantics of each concept are mathematically as simple as possible, and that those concepts and structures are sufficient to synthesize pretty much anything and lend themselves to programming in pretty much any style.
As a result, it's been ideal for teaching computer science - and I want to emphasize the word 'science', as opposed to 'trade'. 'engineering' is somewhere inbetween. The trade of programming means studying individual languages and systems and tools and libraries and coding standards and protocols and gaining some proficiency in using them. The science of programming is about how each of these things are designed, the math behind them, and what kind of design and mathematical tradeoffs are involved in different ways of doing things.
When you're studying computer science, you don't want to waste too much time teaching the students a language. So you want a language that smart students accustomed to rigorous thought can literally pick up in a couple of days. And scheme has been that language. When you're studying object orientation and how OO systems should be designed, you want a base language that contains the facilities necessary to roll your own object orientation extensions, so you can try out several different types of OO in the course of a single semester. And scheme has served that need as well. When you want to talk about functional, OO, and procedural programming (and if you're completist, even unification programming) you need a language that easily or with the addition of a library or two lends itself to all three. Scheme works great for that.
The fact is that Scheme doesn't have a lot of readymade things that other languages have. Instead, it has the facilities to easily build them. And that means it lets you freely experiment with different designs or different *ways* of building them, or even design individual programs using different facilities depending on what fits the individual problem best.
But this extreme flexibility tends to play bloody hell with interoperability. Typical scheme programs contain infrastructure code that virtually everything "interesting" about the program depends on. If you want to reuse code, you have to do some serious work to make sure it can get the kind of object-oriented functionality it wants, and the version of the TCP stack code that has the particular functions and argument orders that it requires, and the version of the CGI library that provides CGI variables with the variable names it expects in the scope it expects, the particular module system that it depends on, the "wrappers" for common functions that it expects, etc, etc, and etc.
And if you attempt to reuse code from several different projects, as is typically the case with opensource programming, you learn the true name of pain. Many of these extensions conflict with each other, requiring namespace control. But many of the module systems granting namespace control also conflict with one another. And you start by trying to sort it out, and if you're like me, end by throwing a bunch of stuff out the window and coding it from scratch - again. Because scheme makes it very easy to code from scratch and very hard to integrate code that diverse people relying on diverse libraries wrote.
Such systemic conflict is also in the heritage of Common Lisp, but Common Lisp took a different route. Where scheme did not standardize that which was controversial or multiply-defined and instead included sufficient "good stuff" to build it whichever way you wanted from scratch, Common Lisp undertook standardization with the express purpose of supporting (or at least easily porting to the new standard) and permitting interoperability of a vast body of legacy code, and actively locked a lot of the "good stuff" up (such that you now have to jump through serious hoops if you want to redefine any standardized function, and rolling your own control constructs with general reified continuations is simply out of the question) to prevent people from re-creating the quagmire.
The result is that the Common Lisp standard adopted wholesale the structures and designs of several different lisp systems which no longer really exist in the wild. There is duplication of purpose in many standard functions, with subtle differences and variations made necessary by different design decisions in the ancestral lisp systems. On the plus side, this gives you a "standard" function that's a drop-in replacement for nearly any function in the ancestral lisp systems, standardizes an exact semantics for each, and saves you having to implement such things yourself. On the minus side, Common Lisp is a relatively huge language, and most students are not going to pick it up in a couple of days. Also, because its design is relatively fixed, you have a single object system and that means it's extra painful to experiment with multiple different other object systems. Likewise module systems, etc. Also, the mathematics and semantics of Common Lisp are more complex and sometimes opaque, with subtleties about referencing the "data" value or the "function" value in expected and unexpected ways seriously getting in your way if you try to do (or analyze rigorously) pure functional programming.
Like all larger structures, it has to be more rigid. Thus there is far less room in Common Lisp to experiment than there is in Scheme, and so while it has served the needs of software engineers and tradesmen rather well, it hasn't been as kind for designers and scientists, who need to experiment. One of the things that makes scheme *hugely* flexible, and which computer scientists love to use in experiments, is general reified continuations. The facility simply can't exist in Common Lisp because it would enable code that would actively subvert the semantics of, or unexpectedly expose implementation details of, a lot of common libraries and implementation strategies.
But CL has largely achieved its goal of providing interoperability for a vast quantity of old lisp code and providing a stable platform for writing new code. And the duplication of purpose in many of its functions has translated into the ability to express certain kinds of subtle differences simply and precisely. And because those different versions of functions exist with standardized names, first you don't have to implement the particular version of them your code requires, and second you won't usually get subtle name conflicts when porting or integrating code. Both of these greatly lower the mental overhead of integrating code from diverse sources into a single program.
Bear (Who's been studying the "ancestral" lisps recently....)
>> A common remark I find on websites is that "Scheme is a heavily >> academic language by nature while Common Lisp is geared more for real >> world development". I've read this more than a few times, actually.
>> Why do people seem to frequently make this remark?
>> Regards,
>> Grant
> [Since this topic is historically flamebait and I'm going > to express actual opinions, I'd like to take this moment to > ask everyone to respond calmly if at all. I'm trying to be > fair to both languages]
[I feel I have to respond to a few issues here, but I will try to stay as calm as you. ;)]
> Also, because [Common Lisp's] design is relatively > fixed, you have a single object system and that means it's > extra painful to experiment with multiple different other object > systems.
This is, to the best of my knowledge, incorrect. The Common Lisp Object System has been designed with the flexibility in mind to adapt it to different kinds of object systems. So for certain styles of object systems, it is especially easy to experiment with variations thereof. Especially, it is relatively painless to make non-trivial modifications and still get reasonable efficiency such that such modifications can actually be used in practice. (You're correct that the latter is not necessarily an important requirement, but can be interesting nonetheless in some cases.)
> Like all larger structures, it has to be more rigid. Thus there > is far less room in Common Lisp to experiment than there is in > Scheme, and so while it has served the needs of software engineers > and tradesmen rather well, it hasn't been as kind for designers > and scientists, who need to experiment.
It's relatively painless to get rid of all the baggage that you don't need in your concrete experiments due to the ability to shadow almost anything with Common Lisp's package system. (Module systems for Scheme give you a similar degree of flexibility. Some people find it hard to get used to Common Lisp packages, though.)
> One of the things that > makes scheme *hugely* flexible, and which computer scientists > love to use in experiments, is general reified continuations. The > facility simply can't exist in Common Lisp because it would > enable code that would actively subvert the semantics of, or > unexpectedly expose implementation details of, a lot of common > libraries and implementation strategies.
This danger exists for any library, no matter whether implemented in Scheme or Common Lisp for that matter. The possibility to reify continuations is one of many possible ways to do reflection on the computational state of a program. Both Scheme and Common Lisp are lacking other reflective facilities, and Common Lisp provides some that Scheme doesn't have. [1]
I mostly agree with your other remarks.
Pascal
[1] It would be nice if either dialect would provide a more complete set of reflective facilities, and would integrate them in cleaner ways, but that's of course not an easy task.
On Jan 31, 10:15 am, Bruce Lewis <brls...@yahoo.com> wrote:
> "Griff" <gret...@gmail.com> writes: > > A common remark I find on websites is that "Scheme is a heavily > > academic language by nature while Common Lisp is geared more for real > > world development". I've read this more than a few times, actually.
> Scheme is frequently applied to secondary- and university-level > teaching. Common Lisp is frequently applied in industry. It is a truth > universally acknowledged that if a computer language is frequently used > in a given area, then that area is what the language is geared for.
LOL, come off it! Hows BRL doing? have you tried scsh at all? I am on arch linux now and it comes with a scsh package!! I remember trying BRL but I never went to MIT so the book talking about MIT's email system and its programability confused me. More time perhaps would have helped me... BRL!!!
> > A common remark I find on websites is that "Scheme is a heavily > > academic language by nature while Common Lisp is geared more for real > > world development". I've read this more than a few times, actually.
> > Why do people seem to frequently make this remark?
HI I saw your scsh. Do I need to read sicp before attacking the scsh manual if I am new to programming? or can I use scsh with sicp? I want to get a scheme environment going on arch linux. to learn
> Ray Dillinger wrote: > > Griff wrote: > >> Hi folks,
> >> A common remark I find on websites is that "Scheme is a heavily > >> academic language by nature while Common Lisp is geared more for real > >> world development". I've read this more than a few times, actually.
> >> Why do people seem to frequently make this remark?
> >> Regards,
> >> Grant
> > [Since this topic is historically flamebait and I'm going > > to express actual opinions, I'd like to take this moment to > > ask everyone to respond calmly if at all. I'm trying to be > > fair to both languages]
> [I feel I have to respond to a few issues here, but I will try to stay > as calm as you. ;)]
> > Also, because [Common Lisp's] design is relatively > > fixed, you have a single object system and that means it's > > extra painful to experiment with multiple different other object > > systems.
> This is, to the best of my knowledge, incorrect. The Common Lisp Object > System has been designed with the flexibility in mind to adapt it to > different kinds of object systems. So for certain styles of object > systems, it is especially easy to experiment with variations thereof. > Especially, it is relatively painless to make non-trivial modifications > and still get reasonable efficiency such that such modifications can > actually be used in practice. (You're correct that the latter is not > necessarily an important requirement, but can be interesting nonetheless > in some cases.)
> > Like all larger structures, it has to be more rigid. Thus there > > is far less room in Common Lisp to experiment than there is in > > Scheme, and so while it has served the needs of software engineers > > and tradesmen rather well, it hasn't been as kind for designers > > and scientists, who need to experiment.
> It's relatively painless to get rid of all the baggage that you don't > need in your concrete experiments due to the ability to shadow almost > anything with Common Lisp's package system. (Module systems for Scheme > give you a similar degree of flexibility. Some people find it hard to > get used to Common Lisp packages, though.)
> > One of the things that > > makes scheme *hugely* flexible, and which computer scientists > > love to use in experiments, is general reified continuations. The > > facility simply can't exist in Common Lisp because it would > > enable code that would actively subvert the semantics of, or > > unexpectedly expose implementation details of, a lot of common > > libraries and implementation strategies.
> This danger exists for any library, no matter whether implemented in > Scheme or Common Lisp for that matter. The possibility to reify > continuations is one of many possible ways to do reflection on the > computational state of a program. Both Scheme and Common Lisp are > lacking other reflective facilities, and Common Lisp provides some that > Scheme doesn't have. [1]
> I mostly agree with your other remarks.
> Pascal
> [1] It would be nice if either dialect would provide a more complete set > of reflective facilities, and would integrate them in cleaner ways, but > that's of course not an easy task.
Paul Graham on his site mentions how he would choose common lisp over scheme because it has real macros. Do they (if they are still superior in 2007) make clisp a better choice for building web based e commerce apps today?
gavino wrote: > On Jan 31, 3:56 am, Pascal Costanza <p...@p-cos.net> wrote: >> Griff wrote: >>> Hi folks, >>> A common remark I find on websites is that "Scheme is a heavily >>> academic language by nature while Common Lisp is geared more for real >>> world development". I've read this more than a few times, actually. >>> Why do people seem to frequently make this remark? >> ...because it easily starts useless flame wars.
> HI I saw your scsh. > Do I need to read sicp before attacking the scsh manual if I am new to > programming? or can I use scsh with sicp? > I want to get a scheme environment going on arch linux. to learn
I am not involved in scsh. You probably mean someone else.
gavino wrote: > Paul Graham on his site mentions how he would choose common lisp over > scheme because it has real macros. Do they (if they are still > superior in 2007) make clisp a better choice for building web based e > commerce apps today?
I don't know what you mean by "real" macros, but the specific characteristics of a macro system are completely unrelated to the possibility to develop web applications with the underlying language.
In <45c0f093$0$68952$742ec...@news.sonic.net> Ray Dillinger wrote:
> When you're studying computer science, you don't want to waste > too much time teaching the students a language.
Hi Ray --
It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java and Python have a simple language syntax. Now, it may be that, in this day and age, when programmers are asked to learn so many things, a language with a simplified syntax is actually on that has a higher "adoption factor."
> The fact is that Scheme doesn't have a lot of readymade things > that other languages have. Instead, it has the facilities to > easily build them. And that means it lets you freely experiment > with different designs or different *ways* of building them, > or even design individual programs using different facilities > depending on what fits the individual problem best.
> But this extreme flexibility tends to play bloody hell with > interoperability. Typical scheme programs contain > infrastructure code that virtually everything "interesting" > about the program depends on. If you want to reuse code, > you have to do some serious work to make sure it can get > the kind of object-oriented functionality it wants, and > the version of the TCP stack code that has the particular > functions and argument orders that it requires, and the version > of the CGI library that provides CGI variables with the variable > names it expects in the scope it expects, the particular module > system that it depends on, the "wrappers" for common functions > that it expects, etc, etc, and etc.
> And if you attempt to reuse code from several different projects, > as is typically the case with opensource programming, you learn > the true name of pain. Many of these extensions conflict with > each other, requiring namespace control. But many of the > module systems granting namespace control also conflict with > one another. And you start by trying to sort it out, and > if you're like me, end by throwing a bunch of stuff out the > window and coding it from scratch - again.
Oh, that sounbds really bad! But I thought the whole point of Scheme being a small language that wants to have libraries was a way to prevent this sad state of affairs. From what I've read from R6RS it seems these issues are addressed in this new standard. Wanna commoent on that?
> things yourself. On the minus side, Common Lisp is a relatively > huge language, and most students are not going to pick it up > in a couple of days.
Common Lisp is huge and there are obscure corners. When a language is huge, you get "gurus" (a bad sign).
> Paul Graham on his site mentions how he would choose common lisp over > scheme because it has real macros. Do they (if they are still > superior in 2007) make clisp a better choice for building web based e > commerce apps today?
Pascal Costanza wrote: > Ray Dillinger wrote: >> Griff wrote: >>> Hi folks,
>>> A common remark I find on websites is that "Scheme is a heavily >>> academic language by nature while Common Lisp is geared more for real >>> world development". I've read this more than a few times, actually.
>>> Why do people seem to frequently make this remark?
>>> Regards,
>>> Grant
>> [Since this topic is historically flamebait and I'm going >> to express actual opinions, I'd like to take this moment to >> ask everyone to respond calmly if at all. I'm trying to be >> fair to both languages]
> [I feel I have to respond to a few issues here, but I will try to stay > as calm as you. ;)]
>> Also, because [Common Lisp's] design is relatively >> fixed, you have a single object system and that means it's >> extra painful to experiment with multiple different other object >> systems.
> This is, to the best of my knowledge, incorrect. The Common Lisp Object > System has been designed with the flexibility in mind to adapt it to > different kinds of object systems. So for certain styles of object > systems, it is especially easy to experiment with variations thereof.
No, Bear is right. CLOS is a single object system. Yes, you are right. It is a particularly flexible object system.
[...]
>> One of the things that >> makes scheme *hugely* flexible, and which computer scientists >> love to use in experiments, is general reified continuations. The >> facility simply can't exist in Common Lisp because it would >> enable code that would actively subvert the semantics of, or >> unexpectedly expose implementation details of, a lot of common >> libraries and implementation strategies.
> This danger exists for any library, no matter whether implemented in > Scheme or Common Lisp for that matter. [...]
Support of continuations is more profound than that. That's why he also said "implementation strategies."
joe nada wrote: > In <45c0f093$0$68952$742ec...@news.sonic.net> Ray Dillinger wrote: >> When you're studying computer science, you don't want to waste >> too much time teaching the students a language.
> Hi Ray --
> It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java > and Python have a simple language syntax. Now, it may be that, in this > day and age, when programmers are asked to learn so many things, a > language with a simplified syntax is actually on that has a higher > "adoption factor."
Scheme simply can't be beat in the syntax department. But I don't think that's what he was talking about. The real problem with all those languages is that they all heavily impose a programming methodology specific to their design. When you learn Java, you learn Java.
Thant Tessman wrote: > Pascal Costanza wrote: >> Ray Dillinger wrote: >>> Also, because [Common Lisp's] design is relatively >>> fixed, you have a single object system and that means it's >>> extra painful to experiment with multiple different other object >>> systems.
>> This is, to the best of my knowledge, incorrect. The Common Lisp >> Object System has been designed with the flexibility in mind to adapt >> it to different kinds of object systems. So for certain styles of >> object systems, it is especially easy to experiment with variations >> thereof.
> No, Bear is right. CLOS is a single object system. Yes, you are right. > It is a particularly flexible object system.
CLOS together with its metaobject protocol actually defines a family of object systems, not just one. That's what I was getting at.
>>> One of the things that >>> makes scheme *hugely* flexible, and which computer scientists >>> love to use in experiments, is general reified continuations. The >>> facility simply can't exist in Common Lisp because it would >>> enable code that would actively subvert the semantics of, or >>> unexpectedly expose implementation details of, a lot of common >>> libraries and implementation strategies.
>> This danger exists for any library, no matter whether implemented in >> Scheme or Common Lisp for that matter. [...]
> Support of continuations is more profound than that. That's why he also > said "implementation strategies."
> Pascal Costanza wrote: > > Ray Dillinger wrote: > >> Griff wrote: > >>> Hi folks,
> >>> A common remark I find on websites is that "Scheme is a heavily > >>> academic language by nature while Common Lisp is geared more for real > >>> world development". I've read this more than a few times, actually.
> >>> Why do people seem to frequently make this remark?
> >>> Regards,
> >>> Grant
> >> [Since this topic is historically flamebait and I'm going > >> to express actual opinions, I'd like to take this moment to > >> ask everyone to respond calmly if at all. I'm trying to be > >> fair to both languages]
> > [I feel I have to respond to a few issues here, but I will try to stay > > as calm as you. ;)]
> >> Also, because [Common Lisp's] design is relatively > >> fixed, you have a single object system and that means it's > >> extra painful to experiment with multiple different other object > >> systems.
> > This is, to the best of my knowledge, incorrect. The Common Lisp Object > > System has been designed with the flexibility in mind to adapt it to > > different kinds of object systems. So for certain styles of object > > systems, it is especially easy to experiment with variations thereof.
> No, Bear is right. CLOS is a single object system. Yes, you are right. > It is a particularly flexible object system.
Just because it's there though doesn't mean you have to use it. If you like you can create your own object system using functions, macros etc. This is what was done in the Garnet toolkit for example.
You can do fairly much the same things possible in scheme, but for the some extra things call/cc may allow.
Some entity, AKA "gavino" <gavcom...@gmail.com>, wrote this mindboggling stuff: (selectively-snipped-or-not-p)
> Do I need to read sicp before attacking the scsh manual if I am new to > programming? or can I use scsh with sicp? > I want to get a scheme environment going on arch linux. to learn
The MIT SICP web-site has all the tools and the paticular scheme-implementation for use on linux to do the 6.001 courseware stuff.
Cor
-- The biggest problem LISP has is that it does not apeal to dumb people If this failed to satisfy you try reading the HyperSpec or woman frig (defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux"))) Read the policy before mailing http://www.clsnet.nl/mail.html
joe nada wrote: > In <45c0f093$0$68952$742ec...@news.sonic.net> Ray Dillinger wrote:
>>When you're studying computer science, you don't want to waste >>too much time teaching the students a language.
> Hi Ray --
> It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java > and Python have a simple language syntax. Now, it may be that, in this > day and age, when programmers are asked to learn so many things, a > language with a simplified syntax is actually on that has a higher > "adoption factor."
It's true that those languages have simple syntax. But they simply are not as flexible as scheme. You cannot compare different OO systems, for example, in smalltalk or Java. Nor can you compare side-effecting and non-side-effecting implementations of things in Haskell. etc. Each of those languages are exactly what they are, and don't provide *any* "good stuff" for experimenting with different types of languages. Scheme, on the other hand, is easily made into any language you want to talk or think about.
>>one another. And you start by trying to sort it out, and >>if you're like me, end by throwing a bunch of stuff out the >>window and coding it from scratch - again.
> Oh, that sounbds really bad! But I thought the whole point of Scheme > being a small language that wants to have libraries was a way to prevent > this sad state of affairs. From what I've read from R6RS it seems these > issues are addressed in this new standard. Wanna commoent on that?
Indeed, the new standard under consideration does seem to be trying to address this. I was careful to mention that I was talking about the history of scheme, not it's future. But whether the standard does what people hope it does, remains to be seen.
>>> A common remark I find on websites is that "Scheme is a heavily >>> academic language by nature while Common Lisp is geared more for real >>> world development". I've read this more than a few times, actually.
>>> Why do people seem to frequently make this remark?
>>> Regards,
>>> Grant
>> [Since this topic is historically flamebait and I'm going >> to express actual opinions, I'd like to take this moment to >> ask everyone to respond calmly if at all. I'm trying to be >> fair to both languages]
> [I feel I have to respond to a few issues here, but I will try to stay > as calm as you. ;)]
>> Also, because [Common Lisp's] design is relatively >> fixed, you have a single object system and that means it's >> extra painful to experiment with multiple different other object >> systems.
> This is, to the best of my knowledge, incorrect. The Common Lisp Object > System has been designed with the flexibility in mind to adapt it to > different kinds of object systems. So for certain styles of object > systems, it is especially easy to experiment with variations thereof. > Especially, it is relatively painless to make non-trivial modifications > and still get reasonable efficiency such that such modifications can > actually be used in practice. (You're correct that the latter is not > necessarily an important requirement, but can be interesting nonetheless > in some cases.)
In fairness, I haven't masterd the CLOS MOOP. I may be underestimating the flexibility of the object system available.
> [1] It would be nice if either dialect would provide a more complete set > of reflective facilities, and would integrate them in cleaner ways, but > that's of course not an easy task.
It is difficult to imagine how a truly complete set of reflective facilities could be, um, "clean".
Ray Dillinger wrote: >> [1] It would be nice if either dialect would provide a more complete >> set of reflective facilities, and would integrate them in cleaner >> ways, but that's of course not an easy task.
> It is difficult to imagine how a truly complete set of reflective > facilities could be, um, "clean".
Ray Dillinger wrote: > Pascal Costanza wrote: >> The Common Lisp >> Object System has been designed with the flexibility in mind to adapt >> it to different kinds of object systems. So for certain styles of >> object systems, it is especially easy to experiment with variations >> thereof. Especially, it is relatively painless to make non-trivial >> modifications and still get reasonable efficiency such that such >> modifications can actually be used in practice. (You're correct that >> the latter is not necessarily an important requirement, but can be >> interesting nonetheless in some cases.)
> In fairness, I haven't masterd the CLOS MOP. I may be underestimating > the flexibility of the object system available.
If you want to learn more about it but want to avoid learning the rest of Common Lisp, Tiny CLOS for Scheme is a pretty good starting point. Eli Barzilay's Swindle is based on this (part of PLT Scheme), as is STklos. The latter two seem to be pretty good approximations of full CLOS.
However, none of the CLOS derivatives for Scheme I have seen so far are as complete as CLOS itself.
The paper "User-Level Language Crafting" by Andreas Paepcke gives an excellent introduction to the CLOS MOP (and it should be relatively straightforward to see how this maps to Tiny CLOS). You can find it on his homepage.
There is, however, no substitute for reading The Art of the Metaobject Protocol sooner or later. ;)
> >>> A common remark I find on websites is that "Scheme is a heavily > >>> academic language by nature while Common Lisp is geared more for real > >>> world development". I've read this more than a few times, actually.
> >>> Why do people seem to frequently make this remark?
> >>> Regards,
> >>> Grant
> >> [Since this topic is historically flamebait and I'm going > >> to express actual opinions, I'd like to take this moment to > >> ask everyone to respond calmly if at all. I'm trying to be > >> fair to both languages]
> > [I feel I have to respond to a few issues here, but I will try to stay > > as calm as you. ;)]
> >> Also, because [Common Lisp's] design is relatively > >> fixed, you have a single object system and that means it's > >> extra painful to experiment with multiple different other object > >> systems.
> > This is, to the best of my knowledge, incorrect. The Common Lisp Object > > System has been designed with the flexibility in mind to adapt it to > > different kinds of object systems. So for certain styles of object > > systems, it is especially easy to experiment with variations thereof. > > Especially, it is relatively painless to make non-trivial modifications > > and still get reasonable efficiency such that such modifications can > > actually be used in practice. (You're correct that the latter is not > > necessarily an important requirement, but can be interesting nonetheless > > in some cases.)
> In fairness, I haven't masterd the CLOS MOOP. I may be underestimating > the flexibility of the object system available.
Whilst CLOS is very flexible, incredibly so compared to C++ for example, there's nothing stopping you from completely ignoring that it is there if you want to use some completely different OOP style. It's pretty much the same as Scheme from that point of view, except that it has a standard OOP system there if you want it.
>In <45c0f093$0$68952$742ec...@news.sonic.net> Ray Dillinger wrote:
>> And if you attempt to reuse code from several different projects, >> as is typically the case with opensource programming, you learn >> the true name of pain. Many of these extensions conflict with >> each other, requiring namespace control. But many of the >> module systems granting namespace control also conflict with >> one another. And you start by trying to sort it out, and >> if you're like me, end by throwing a bunch of stuff out the >> window and coding it from scratch - again.
>Oh, that sounds really bad! But I thought the whole point of Scheme >being a small language that wants to have libraries was a way to prevent >this sad state of affairs. From what I've read from R6RS it seems these >issues are addressed in this new standard. Wanna commoent on that?
It's not quite all that bleak. Writing portable code is an issue in Scheme because of the large number of different implementations and the fact that many aspects of the programming environment are not standardized. But CL isn't really that much better - things like GUIs, networking, conditions/exceptions[1], FFI, etc. are implementation dependent in both languages.
CL's standard package and object system mean that more CL code is more easily portable among implementations - but code which is not portable in CL deals largely with same issues as code which is not portable in Scheme.
Heavy-weight Scheme and CL implementations come with built-in libraries for many common programming tasks. The solution for either language is to pick one of these implementations and stick with it as much as possible. Open source libraries usually try to support the popular implementations, and when you must port something, the heavy-weights generally have better documentation and more user support available.
WRT R6RS, we'll have to wait until we have implementations and people get some experience with it. The library system is similar enough to CL's package system that it should provide many of the same benefits.
The exception system also appears inspired by CL's condition system - and I predeict it will have the same portability problems (see [1]). Regardless, if people use it, it will be an improvement over the complete anarchy we have now.
George
[1] The CL standard defines the portable functions/macros and semantics of the condition system. However there are only a few conditions defined which all CL implementations must respect. Because conditions are user definable, each implementation has defined its own unique hierarchy.
