Learning Lounge

[Marc Santoro]

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 
> implicitly
> 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 
useful.

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 
learning curve.
> 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?
>
> Pietro
>
>> Thanks,
>> Marc.
>
> 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.