Subject: What the buzz? ( was: Re: Re: Prerequisite learning? (was: Re: Re: The purpose of paradigms...) )

From: Omer Musaev <[email-masked]>
Date: Sun, 3 Mar 2002 12:11:35 +0200

[ skipped a vast amount of Shlomi' frowning upon C++,patterns and all
  those heretics that do not use scripting languages wherever possible ]

> That you should use the most common programming language for 
> everything?
> Like I said earlier, I think it's pretty lame to teach Algorithms, or
> Compiler Theory, or to generate VRML pages with C. 

I tend to disagree. I had learned Compiler Theory in Scheme, and while 
I learned a whole lot about optimisation techniques ( most of them are 
about breaking referential transparency to pieces, btw ), I did not learn
nothing about lex or yacc. This days I think that learning Compiler Theory
in 
C++ or in Java would be better choice. 

> Why not teach Perl
> (/Python/Ruby, yeh yeh) and save the students a hearth of future
> frustration. Just because you decided to teach C as the introducery
> programming language (possibly a bad choice, but let's skip 
> it), does not
> mean it would be perfect for everything else the students 
> will have to do.

Because when you have 13 weeks to learn a subject, you do not want all 
that time wasted in teaching new programming language. It is possible to 
express very complex programs in C, as you had stated in one of your 
recent posts. So why should one teach a new programming language when 
there is not enough time to teach the subject itself, given that an 
average student is capable to express him/her/it-self in one language?

> I know teaching a distinct programming language for every 
> task will scare
> away the students or the readers. I'm also a bit frustrated 
> that there's
> seems to be an inflation of new languages recently (which I am partly
> responsible), and many languages compete for performing the same task.

What do you mean when you say ".. I am partly responsible.."? Randalf is not
a language yet...

> But my question is: why is it unthinkable to teach a course about
> Functional Programming in C, while teaching Compiler theory 
> with it makes sense?

1. Because FP is about functions, and having function as first level object
is almost a necessity for clear understanding of FP. In that sense, teaching

FP with C++ ( where functions can be expressed in terms of first class
objects )
can do.

2. Because compiler theory is about parsing and code generations. 

While it is possible to write recursive-descent parser for many languages, 
shift-and-reduce parsers are capable of solving much more classes of 
"parse grammar X" problems.

Which makes imperative programming much more valuable in parser creating
than 
recursion/FP techniques.

On the other hand, having ability to create memory-mapped data structures is

very helpful in teaching code generation. 
  
> Or alternatively, can a book about Patterns that uses C++, can
> actually teach about Patterns, rather than try to emphasize how to
> overcome its OO idiosyncrasies?

GoF does not teach about patterns. GoF is a _catalogue_ of patterns. 
Pick other book to learn patterns. You can start with "A little Java, a Few
Patterns", if you wish to learn a new programming language ( I bet have
never
seen Java used instead of Scheme by 2 hardcore schemers in a way that is 
presented in that book ). 

I use GoF as a reference only. It is not a good book for teaching patterns.
In 
addition, it is not a good book about C++ either - it is too much Smalltalk 
oriented. 

In addition, try to implement "template method" pattern in Python. You 
will find that you will _have to_ leave your driver code public. Otherwise,
you will not be able to use it. This inability renders the whole idea of
separating interface and implementation as cumbersome - you will have to 
split template methods into an interface and implementation, both fully 
public. This will set the design as evolvable, and you will not be able 
to enforce design decisions. No good:(

This was only one example of pattern that is widely used in C++/Java world,
yet is not applicable well to Python. I see many more examples when pattern
X does not fit well programming language Y. Fortunately, C++ is good enough
language to use almost all patterns with it. Unfortunately, many people 
frown on C++, from various reasons. Even more unfortunately, even C++ is 
not a perfect language for all purposes, since it is hardly possible to 
construct one. Fortunately, it is pretty close.

BTW: I did not understand your arguments. Can you bring examples of "how to 
overcome its OO idiosyncrasies", or at least what those idiosyncrasies are 
and why to overcome those?
 
> It's a trade-off, but that's life.

Engineering is about tradeoffs, isn't it?

> 
> Regards,
> 
> 	Shlomi Fish
> 
> 
> 
> >    Regards,
> >      Eran Tromer
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > [email-masked]
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

To unsubscribe from this group, send an email to:
[email-masked]

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 12:51:21 +0200 (IST)

If you'll excuse me I think I'll skip the

1. C++ good or evil
2. Should Compiler Theory courses teach Lex and Yacc.
3. Why can you teach it in Perl where Lex and Yacc are available.

discussions because judging from experience on this list, they are not
going anywhere.

But maybe the stuff about Patterns relevant only to one programming
language is important. When I read "Design Patterns" I wanted to learn
about Patterns that will be good in any programming language, or at least
any OO programming language. Yet, I got disappointed that the snippets
were in C++.

I do not object to the claim that identifying re-current patterns in code
is important. I do believe however, that the catalog of patterns presented
in the Gang of Four book is not complete, even AFA C++ is concerned.

Call me a C++-hater by blood, but I would have prefered a different
language were I to be introduced to the patterns paradigm. And I don't
hate C++ that much, I just think that trivial OO (or non-OO) tricks there
can become very awkward. Maybe I got too used to Dynamically Typed
languages, like Perl or Scheme, which are very flexible in this regard.

OTOH, I do like Haskell a lot and its strongly typed. But I find it
awkward to write code that is not too trivial or elegant with it. So I
guess Haskell falls into the "It has nice constructs, patterns and
concepts, but it's not useful for anything real" category. And
unfortunately, too many languages fall into this category.

Maybe it would be a good idea for language designers to make sure that
they design real-world languages. Most of the languages used today are not
academic languages. (The only exceptions that comes to my mind is Scheme
and LISP, and they are not very common) For instance, while I do design
Rindolf for fun, I do actually plan it to be useful in the real-world. But
then again, Rindolf is more of an incremental change to Perl 5/6 than a
language that is designed from scratch. Sort of like C++ to C.

Regards,

	Shlomi Fish

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 13:49:37 +0200

> FP with C++ ( where functions can be expressed in terms of first class

Can you explain it?

-- 
Oleg Goldshmidt | [email-masked] 
Only wimps use tape backup: real men just upload their important 
stuff on ftp, and let the rest of the world mirror it. [L. Torvalds]