It seems to me that the type system made in sections 2.4 and 2.5 are highly similar to inheritance and polymorphism in object oriented languages. It seems like a lot of work to gain very little over OO languages. If a program needs something like that, wouldn't it be best to simply write it in an OO language? What are the benefits of what they create over the equivalent in, say, C++ or Python?

Quote:It seems to me that the type system made in sections 2.4 and 2.5 are highly similar to inheritance and polymorphism in object oriented languages.

See footnote 52 in section 2.5. :)

Quote:It seems like a lot of work to gain very little over OO languages. If a program needs something like that, wouldn't it be best to simply write it in an OO language?

It's (a bit of) work because it's not using language support; it's building a type dispatch system manually to illustrate the concept.

It would be better to write it in python or C++ IF your problem fits into their respective object systems AND you want to teach use of that particular object system instead of the concept of dispatching on type.

Scheme is a minimalist language. Matrix manipulation code would be more easily written in matlab than scheme. String manipulation code would be more easily written in perl than scheme. Code that fits runtime single-dispatch polymorphism will be more easily written in languages with explicit support for runtime single-dispatch polymorphism (ie typical OO languages).

SICP is not about teaching features but general concepts, and Abelson and Sussman obviously don't think typical OO is general enough to qualify as a central concept. So they teach dispatch-on-type, which can easily be used to implement typical object systems, while the converse isn't true (see the need for the visitor and other 'patterns' in typical OO languages).

Single-dispatch polymorphism and inheritance (python or C++ OO) is a specialised restriction of what is being taught here. Abelson and Sussman aim higher.

If you miss OO, you can always implement an object system in a few lines of scheme using what you learnt in SICP or use one of the many object systems provided as libraries. :)

Thanks for the reply. I see a bit of why this is desirable. Would someone mind providing an example as to why this is helpful in some cases?

Quote:Original post by Ezbez
What are the benefits of what they create over the equivalent in, say, C++ or Python?

For starters, they don't have to write it in C++ or Python. [wink]

More seriously, Scheme has many features C++ and (to a lesser extent) Python lack. Most obviously, C++ doesn't support continuations, and hardly supports functional programming.

Scheme doesn't support C++-style OOP, out of the box, but you can add it seamlessly. You can add better functional programming support to C++, but the result is ugly and the seams show everywhere.

With Scheme (and languages of its ilk), therefore, you can get the best of all possible worlds: You get the OOP system of choice; the concurrency system of choice; the object persistence system of choice; the exception handling system of choice. Assuming, of course, you have the time and expertise to implement them.

With less flexible languages, you get to pick one and struggle on with subpar implementations of the rest.

So, you're basically saying that there isn't any major benefit from this OO-in-Lisp over 'traditional' OO, the benefit comes from all the *other* parts of Lisp. Correct?

Quote:Original post by Muhammad Haggag

Quote:Original post by Nathan Baum
With Scheme (and languages of its ilk), therefore, you can get the best of all possible worlds: You get the OOP system of choice; the concurrency system of choice; the object persistence system of choice; the exception handling system of choice. Assuming, of course, you have the time and expertise to implement them.

This leads to the obvious question: Doesn't the lack of a standard OOP system lead to the creation of many similar but slightly incompatible OOP systems by different people? i.e. If I use libraries X, Y and Z in a project, and each of them uses an OOP system of its own, I'll have to learn and deal with the pecularities of each.

It seems a likely hazard. Whether or not this actually happens in the real world I have no idea: my experience with Scheme is limited. The only effective curative I can think of is to encourage people to share their code under unrestrictive licenses. If somebody wants an OOP system, they are likely to be able to find one already made.

It's possible that X, Y and Z are different enough that they really need different OOP systems. In this case it is probably better that they have their own OOP system. It will probably be easier to learn and deal with than if they used a standardized OOP system in a weird or complicated way.

Quote:
Or does Scheme have some sort of an "open" repository of informally standardized libraries/techniques, like Boost for C++ for example?

There are the Scheme Requests for Implementation.

There is also SLIB (Site was unresponsive when I last tried). This is not an informal standard in the way that the SRFIs are, but it has a huge amount of functionality, and is portable. It includes such features as: color space transformations, Rayleigh scattering (!), an in-process relational database, a HTTP server and FFT, as well as more mundane data structures and algorithms.

Quote:Original post by Ezbez
So, you're basically saying that there isn't any major benefit from this OO-in-Lisp over 'traditional' OO, the benefit comes from all the *other* parts of Lisp. Correct?

More-or-less.

However, there is a major benefit over traditional OO (by which, I suppose, you mean Smalltalk-derived OO): if Smalltalk-derived OO isn't a good fit to the problem domain, you can use a variant of OO which is.

For example, if you find yourself using the Visitor pattern a lot, then you can modify the OO system to do multiple-dynamic dispatch. Now the system takes care of Visitor for you. The same applies to many other patterns. If you have many singletons, you can make specific syntax for singletons.

Depending upon the problem, the ability to craft a OO system to match may be a significant factor in whether you get it done or not.

But if, let's say, C++ would have been a good substrate for the object model, then most of the benefit would be derived from other aspects of Scheme, yeah.

Thanks Nathan, I believe I understand it now, even if I haven't come across a specific time when I'd prefer it. Then again, I'm just getting started!