Fri May 16 23:06:01 2003
On Friday, May 16, 2003, at 05:30 AM, PB wrote:
> - 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)
I'm not certain I would go so far as to assume newbies would know a
strict functional language in any depth. But I agree with you that the
first two would be common.
> - once you know a language, you know them all
Once you know C or Java, you know Haskell and Prolog and CLOS? There
are certain languages that give such a breadth of knowledge in learning
that this becomes nearly true, but I think that in the context of
newcomers, this is wrong.
> - 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
I think it is less difficult to show how to effectively use a concept
when the user can be shown exactly /how/ to use the concept, in a
language they understand well. Yes, we can show how multiple
dispatching works differently in X or Y, but that does not give a
person the ability to write a program in X or Y which takes advantage
of multiple dispatching -- which I think is important. What use is a
concept that is not usable? :) In addition, as you mentioned above,
"once you know one language, you know them all" -- I think that if a
student learns a couple of languages like Smalltalk, CL/CLOS, et al, in
depth, their ability to grasp complex concepts will be greatly improved.
> 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.
I chose Squeak because I like Squeak; I think it is easy to learn, and
very powerful. I also think that the environment provided by Squeak
will allow programmers to write useful things. In addition...
> 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
> state "hey, the HLL will be a (beautified, improved, whatever)
> Smalltalk. Study Squeak and you're done".
Well, the choice of language at the beginning can be fairly arbitrary
given certain constraints -- that a number of complex ideas expected in
the HLL are easy to work with in that language, and that the language
is expressive enough and has enough API to allow useful programs to be
written. There are many languages that fit this bill; I just happen to
pick what I like. I also think Squeak is easy to learn.
I also think that perhaps we do need to "begin" stating what the HLL
will be. Without a clear definition, where do we go? Tunes has been in
a design phase for a very long time. There is a "Best Way" and a "Right
Way", perhaps. But if we don't start pinning things down now, Tunes may
never happen. I think that the design of Tunes now points towards a
very evolutionary system, so I do not think any bad decisions we make
now will be so irreversible in the future.
So let me go ahead and propose that the HLL will be something like
Slate; that Slate is something like CLOS and something like Smalltalk,
and that a thorough grasp of CLOS & Smalltalk should aid greatly in
giving a programmer the ability to develop with the HLL, once it
exists. This seems to be a direction that is forming; even if it is
incorrect, it would allow us to observe Tunes from another point of
view, and I think that at least is better than the current fairly
static state the project seems to have assumed.
Also note that I do not encourage the adoption of a single language
during education; I would choose two or three good languages. Maybe
even the adoption of languages during education would help show which
paradigms are important -- if we decide that language X lacks useful
multi-methods, and we can show how language Y's multi-methods are
useful, then we know something. And the most visible way to do this is
to write useful code -- even if it is not core Tunes code. Let us
encourage the authoring of serious pieces of software that use
technologies we think will be core to Tunes, even if such software will
never run on Tunes proper. At the least, this will show us that we are
on the right path -- that the concepts embodied by Tunes can/will be
I don't want Tunes to be an esoteric project for highly skilled
theorists -- I want Tunes to be a system my mother could use, and would
want to use (even if she didn't know she was using Tunes), without
restricting it's ability to be useful to highly skilled theorists. I
think Squeak is very much a step in that direction -- a fairly
expressive, general-purpose language, with a lot of very powerful, and
realistically useful features.
> 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
I think that case studies are more appropriate at advanced levels,
where those case studies can surely be understood. I think for a newbie
that case studies will be overwhelming, because a newbie may not know
how to work through material without being given a clear path. I think
perhaps first we must teach people how to learn; it seems that many
schools at least in the US do a poor job of this. And I don't care for
the sink-or-swim method. Again, this comes back to lowering the
> 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
But we're getting into some rather high-learning-curve stuff now; I
want to stay away from this at this point in time. People ready to
tackle Joy probably don't need much hand-holding.
> 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.
I would assume that these people are not our target audience, as
someone ready to pursue such topics probably has the ability to locate
and understand the resources without help, or perhaps with pointers.
> Hope I've been able to explain what I mean. Comments,
> suggestions, critiques?
> P.S. also we did not consider philosophical topics, as
> cybernethics, utilitarianims, etc. Should they be in?
Interesting question...philosophical topics seem to be very important
to some projects (I think they are important to Tunes and to GNU, for
example) -- but I wouldn't like to see the kind of problems that,
perhaps, GNU faces, where philosophy gets in the way of code.