[plt-scheme] The perfect teaching language--Is this too much to ask for?

On Sun, Jun 14, 2009 at 02:38:35PM -0400, Matthias Felleisen wrote:
> 
> On Jun 14, 2009, at 1:54 PM, Luciano Ramalho wrote:
> 
> >Prof. Shriram, I never meant to convince you or anyone else here that
> >the "usability cost" of parenthetical syntax outweights its benefits.
> >Even a newbie like me understands the trade-off and appreciates the
> >benefits.
> >
> >I just wanted to point out that the "simple" syntax of Scheme does not
> >make it necessarily easier to read than other syntaxes that are not so
> >regular.
> 
> 
> (Luciano, you don't have to call us professors or anything. The fact  
> that we have academic titles is meaningless. Too many 'professors'  
> think the title is enough to intimidate people into believing them.  

Not to mention titles like Herr Professor Doktor :)

> It's awful. The fact that we're older is meaningless, too. It just  
> means we're closer to death (on the average).)
> 
> What is meaningful is that we have demonstrated and keep  
> demonstrating a broad and deep grasp of the material.
> 
> As for syntax, I think you're onto something. It is also true that  
> even we're stumped when reading others' code.

And if others freely invent further syntax, the code can get much harder 
to read.  Unless the syntax is very well-designed, and follows familiar 
conventions.

> I bet that I could  
> stump Shriram with 1000s of snippets of code from our code basis and  
> I bet that the converse is true, too. While it is true that tools and  
> experience in reading lots of code help people like us a lot, a tool  
> solution is also unsatisfactory. Everyone claims that everything can  
> be solved with tools, and we kow from decades of experience that  
> linguistic solutions are almost always superior in the long run.

Natural languages had nouns and verbs and adjectives and adverbs and 
prepositions (only some have postpositions) and main clauses and 
subordinate cluses and prepositional phrases and so on.  They are way 
more complex than programming languages (perhaps this is evolution vs. 
design).  Yet we find them convenient in 
everyday use.

There's probably something to be learned from this variety of syntax.  
Not that I'd advocete programming in natural language.  They are very 
unsuited to the task.  But having variety in syntax seems to alleviate 
problems with understanding nested constructions.  Yes, I appreciate 
being able to parenthesize anything in a programming language and use 
the entire language within the parentheses (I severely fault C ans 
Pascal and Modula 3 and all Java ans all those languages for this), but 
that kind of nesting is useful mostly while doing formal, possibly 
mechanical operations on code.  It often doesn't mean the code is easier 
to read.  Unless of course, the code is what's input into the formal 
transformatino engine, in which case the engine can provide useful 
notation.

> As for types, please do respect that we have tons of work behind us  
> with typed models of languages and meta-theorems concerning types.  
> When we actively choose not to program in an existing typed language  
> (but yes I have started to program in Typed Scheme) then there is a  
> reason.

Typed Scheme hjas broad compatibility with regulsr Scheme.  So you can 
mix typed with untyped code if you need to.

> 
> As for type is a type, please do read the papers on loop holes in  
> languages, probably starting with Albert Meyer's papers and Luca's in  
> the 1980s. When Python makes something look trivial, it's probably  
> wrong.
> 
> As for run-time tags, please everyone do understand that types should  
> really be our terminology for things that are checked before the  
> program runs and whose purpose it is to help us enforce a discipline  
> of data (abstraction, as things are always called abstraction in CS)  
> onto our programs.

That's the convention I've always used -- that types are static, and 
run-time tags are part of the data (and could be described by a type).

Yes, we can have abstract types, too.  They're what you get when you let 
a lambda-variable be of type 'type'.  Type-checking can still be static, 
(else I wouldn't call it a type), and you don't have to have any 
run-time representation for the type itself (just for its calues, of 
course).

Of course, you could design the language differently, and possibly end 
up confused or confusing.

-- hendrik