Learning Lounge

PB schizophonic@tiscali.it
Fri May 16 03:32:01 2003

Marc Santoro wrote:
> I agree with you a great deal; the first 5-6 topics you described in
> detail included, essentially, the reasons I would choose to teach CL and
> Squeak.  I think that many of those subtopics would be good
> learning projects/topics involving a course on learning a language.
> I also do not want to "remove" the fundamental topics -- but I would like
> to see the definition of fundamental topics change to include (and perhaps
> be centered around) topics that must be understood before the more
> advanced topics can be learned.

Let's say "foundational" rather than "fundamental".
You're right when you say that one can get along
and program without the foundations, so they're
not really fundamental for everyone.

> The pattern I envisioned is based on the topics and skills I would like a
> person to have, placed into a development-oriented framework. I want
> people writing code! I want people sharing.

100% agree.

> I think also that you are starting too quickly; I would like to introduce
> a single language (Squeak), which would allow for the development of
> understanding of many important core concepts. Once these concepts are
> understood, the process of learning different languages should be
> expedited greatly. While Squeak is not the best platform (nor is CL) for
> each of Tunes' core concepts, I think that a solidly grounded
> understanding of one or two languages is much more important at the
> beginning than a weak grasp of many languages (in the first topic you
> mention 12.9 -- do you really expect a newbie to be able to tackle that? I
> would not dare to give more than 1, unless they are already
> well-experienced with stuff that is non-traditional or
> non-systems-programming) -- particularly when the only concepts in a
> language the student is forced to learn are the concepts specifically
> related to Tunes.

In effects, the PL topic should be broken and simplified, ad
a newbie section should be introduced. However, I did not
mean that all the languages I mentioned should be studied
as a whole. My idea was:

- if they come here, they already know at least one language, very
likely an imperative procedural language, perhaps a class-based
object-oriented one, perhaps also a strict functional one (implicitly
assuming that there are no complete newbies)

- once you know a language, you know them all;

- the course should therefore be *not* a course on Squeak,
or on CL, or on Haskell, or on Joy, or on whatever. It should
be a course on programming languages *concepts*, where you show
how a same concept, say, multiple dispatching, is differently
interpreted in CL, in Cecil, in Slate, etc, how it can be used
effectively to do useful things, and which troubles and hassles,
on the other way, it brings. In brief: showing just snippets of
many languages as a mean to present ideas and, er, paradigms.

Perhaps you are right when you say that you want to introduce
more thoroughly a single language, and perhaps you are right in
choosing Squeak. But for people to code TUNES, we just need a full
fledged course for the HLL and the LLL, when their design and
implementation will be sufficiently stable. The fact is that now we're
in a *design* phase for HLL and LLL. The learning lounge was born
as an answer to a frustration in understanding what Fare, Armin and
Brian et al are speaking about when they tackle the issue.
This should be the purpose of the lounge: Reducing the knowledge
gap, introducing *concepts*. No single PL can be used as a paradigmatic
case for everything, also because we do not exactly know which paradigms 
we need. By basing a course on, say, on Smalltalk we risk to implicitly
state "hey, the HLL will be a (beautified, improved, whatever) 
Smalltalk. Study Squeak and you're done". I think that we don't want to
put this strong bias, that's why IMHO the right approach is detecting
the concepts and presenting them *by means* of many case studies. If
then one wants to go deeper in some specific language he will know
enough to do it on his/her own. Notable exceptions could be Maude and
Joy, which come with their own theory and perhaps would deserve a
thorough tractation to be grasped.

Same thing for foundational topics. I've no clear idea of which of them
we really need, so I think we should at least say which they are,
how they are related and explain the main connections between them.
If one wants a full-fledged course on, say, universal coalgebra
(s)he can follow the links and download the papers.

Hope I've been able to explain what I mean. Comments,
suggestions, critiques?


> Thanks,
> Marc.

P.S. also we did not consider philosophical topics, as
cybernethics, utilitarianims, etc. Should they be in?