Subject: Technion Computer Science Anomalities

From: Shlomi Fish <[email-masked]>
Date: Mon, 17 Sep 2001 14:31:50 +0300 (EEST)

This thread is a continuation of a thread that started in the Haifa Linux
Club mailing list. It discusses two issues:

1. Should the Technion teach Bourne Shell programming in its second-semester
courses of "Intro to Systems' Programming" (of the CS faculty) and
"Intro to Software Systems" (the corresponding course of the EE faculty)
instead of C-shell which is taught now.

2. Should the Technion teach ANSI C in its first-semester "Intro to
Computer Science" as it does now, or rather C++ or Java.

Here is my opinion on the subject:

1. I consider C-shell to be a _broken_ shell. There's "Csh programming
considered Harmful" by Tom Christiansen that gives a lot of compelling
reasons why not to use it. Unfortunately, tcsh did little to improve
its mis-behaviour. I realize that the Technion wishes to expose
students to the shell-scripting mode of thought (which is not a bad
idea IMO), but C-shell is not the right way to do it.<tm>.

Mulix have argued that the syntax of C-shell resembles C, which those
who learn the course are already familiar with. However, I told him
that it was like saying that English and French were the same, because
both use the Latin Alphabet. Knowing English will not make it
much easier for a non-French speaker to learn French, IMO. (I know it
did not help me for the short time I studied French). And I believe the
Technion should get people used to the fact that some languages use
alternate syntaxes, other than C. Besides, I believe that for a shell,
the Bourne shell has a much saner syntax than C-shell, which the
students will come to like.

2. I don't think either C or C++ or Java should be taught as the first
programming language. The problem with all of these languages is that
they are very complex, and filled with traps to the unwary.

In any case, there's an article by Damian Conway (of perl
fame) and L. McIver which find pedagogical faults in most of the modern
languages used today to teach programming:

http://www.csse.monash.edu.au/~damian/papers/PS/SevenDeadlySins.ps
(BTW, from a discussion I held with him on use.perl.org he said that
perl is not a good candidate either. Nor is Python.).

My first programming language was GW-Basic, which is incredibly limited
but very good for learning how to program, IMO. Visual Basic (or Visual
Basic for Application) is much better, but still incredibly limited.

None of the modern commonly used languages seem to be perfect for
teaching people how to program. However, C++ seems to be a worse
choice than ANSI C, because there are much more pitfalls involved in
it. In C++ it is very easy (even for very experienced programmers) to
write code where something doesn't work and you have no idea why. ;)

If you wish to expose people to object orientation, then your best bet
is probably something like perl or python or Scheme (or Java), where
things tend to work more flawlessly. There are many other languages
which I don't know as well, which may also prove useful.

But I'm not sure if exposing people to OOP is a must for a first
programming language. With Structured Programming, and OOP, and
Functional Programming, and Relational Data Programming, and all the
other paradigms I may be less aware of, there is too much ground to
cover in the first semester. OOP is very nice and useful, but people
can get exposed to it somewhat later without any side-effects.

Regards,

	Shlomi Fish

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

A more experienced programmer does not make less bugs. He just realizes
what went wrong more quickly.

---

From: Adi Stav <[email-masked]>
Date: Tue, 18 Sep 2001 02:50:58 +0300

Hi, I'm responding to this twice because they're long, and because
I think they belong in two different flamew^H^H^H^H^H^Hdiscussions.

> students will come to like.

I agree with you on that, and I don't think csh's syntax is close
enough to C (if any shell's can) to make csh an advantage to sh.
I had used csh in the past, and was surprised to learn that its 
syntax was meant to resemble C's long after I switched to sh.

Furthermore, I think that the shell's most important 
characteristic, from both the pedagogical and the practical points 
of view, is that it provides a direct but high-level interface to 
the Unix system call API. It lets the programmer take advnatage of 
Unix's timesharing and IO system, and the student to learn about 
them, without having to program directly for the CPU with C. I 
believe that sh accomplishes this goal better than csh. 

For example, sh does redirection by letting the programmer change 
and replace numbered file descriptors. This is completely flexible,
and, more important to students, is completely compatible with how 
Unix treats file descriptos. Csh, in contrast, has special syntax[1]
for the 0, 1 and 2 file descriptors, and lets you access them 
through this special syntax only. This actually hides Unix's own
semantics and will not let the student fully understand system 
calls such as dup(). It pretends that standard input, standard 
output, and (with some reluctance) standard error are each a 
special purpose entity that together consist all of the I/O 
system, rather then simply being the first three of a potentially 
long list of generic, use-and-throw file descriptors.

Another example is the "if" statement. Csh's "if" is a simple
textual and arithmetic operation, which in itself uninteresting.
Sh's "if", on the other hand, examines a given command's process 
exit status[2], and therefore gives a direct interface (and an 
opportunity to fully understand) the exit() and wait() system 
calls and their interaction. It also teaches more about "the 
Unix philosophy".

To sum it up, I only see a value in teaching shell scripting
together with learning about Unix. In its attempt to become
easier, csh has weakened many of aspects that can make shell
scripting a good thing to learn, and has reduces itself to
something closer to "just another scripting language with 
pipes". 

I suspect that the main reason csh caught in the first place 
was because it was the first to introduce advanced interactive 
features such as history expasion (feel free to correct me on 
that one), and that the main reason it is still relevant today 
is because it is the informal "default friendly shell" on 
Solaris, with its long-abondened but still remembered BSD roots. 
The first is now irrelevant because (for example) bash already 
has such features, and because we're interested in scripting here.
The second will become irrelevant eventually because you-know-what.

[1] sh's redirection also defaults to file descriptor 0 for input 
redirection and to 1 for output redirection, but those defaults
are purely a syntactic issue that a textbook can explain in one 
line. Teaching about those defaults can also be postponed until 
after redirection is fully understood. I still don't like pipes 
only working on 0 and 1, though.

[2] I'm aware that (for example) bash performs textual and
arithmetic operations by itself whenever you think you're
calling the "test" utility from "if". But I think this is 
irrelevant to both students and programmers, since the semantics 
are still exactly those of exit() and wait(). This is equivalent
to buffered IO does not changing Unix's traditional synchronous 
IO semantics.

---

From: Adi Stav <[email-masked]>
Date: Tue, 18 Sep 2001 04:41:34 +0300

> Here is my opinion on the subject:

[snip]
> they are very complex, and filled with traps to the unwary.

I agree about C. However, I don't think it is complex and
difficult to program in it because it is a complex and difficult
language; but because it relies solely on features available
in hardware, with which it is often complex and difficult to solve 
common higher-level problems (e.g., strings). In other words, C is 
not exactly a general purpose language. It is a language for
programming register machines with random access memory and stack
operations. All of our current computers are so, but for someone
who is trying to solve regular high-level problems and does not
care too much about efficiency or about what the CPU is actually
doing (i.e., a novice), C is simply a non-general-purpose language 
being used for something it was never meant for. I believe that 
just like teaching shell is worthless and confusing if it does not
come together or following a course on Unix, C is worthless and
confusing if it does not come together with teaching how processors 
work.

I say that because I don't know what the Technion's end-goal is. 
If it is to teach general programming principles to students,
I'd say C is definitely the wrong option. On the other hand, if
the object of the course is to teach electric engineering students
something about programming, and those students already have a good
idea of how computers work internally because of their electric
engineering background, C might be exactly the right language.

Without knowing Java well, I'd guess it is better than either C++
or C because of its focus on a single paradigm and its automatic
memory management.

Regarding C++, I simply don't see a point. If you are looking for
teaching generic programming or OOP, then simpler, easier languages
exist. If you want to teach how to program modern CPU's, use C. I
can't understand why so many educational institutions in Israel are
so eager to switch to C++ lately. The best explanation I can think
of is that they want to give students knowledge of a language 
commonly used and hyped in the industry (which is in itself a 
questionable goal). But since C++ is sometimes being replaced by Java 
and other high-level languages in the industry anyway nowdays, then 
this only serves to strengthen the stereotype of decision makers in
the education system as people who receive their updates about the
real world a little bit late.

By the way, you didn't mention Pascal. I think it is the wrong choice 
for the same reason that C++ is the wrong choice; there are better,
easier languages that would teach the same principles. Unless you
want to teach with strong typing.

> perl is not a good candidate either. Nor is Python.).

Great article. Thanks. 

I'd say Perl is the worst language one can start programming with of
all the languages I know even a little of. Its syntax and semantics
are perfectly logical and intuitive to anyone familiar with Unix to 
a certain degree, and are a complete and inconsistent mess to almost
anyone else. If the students don't already know shell, sed, awk and
C, they shouldn't try Perl; I've seen friends try it and it just
doesn't work. I think Perl should be the last language a person
learns, a conclusion to their tour of the computer language world, 
but not a first language.

I do think Python makes an excellent choice, though. Why didn't 
Conway like it, by the way? Was it only the whitespace thing, or did
he have other reasons too? I'd say that Python would get a perfect
score on almost every one of his items, except for the whitespace
dependency, about which he didn't elaborate much in the article.

> Basic for Application) is much better, but still incredibly limited.

I disagree. I started with Basic too, and it took me 18 months of
programming with Pascal to get rid of all the bad thinking habits
I had acquired. For a language to be a good teaching language, it
is not enough that it is high level, it should also allow and 
encourage the right ways to write programs. How much can you learn
from a language whose basic flow control structure is GOTO, whose 
basic information storage system is global variables, and whose best 
idea of flexibility and expansionability is to recommend that you 
number your lines in hops of 10?

I don't know VB, but from Chen I understand that it is not very
limited, but very confusing and inconsistent.

> can get exposed to it somewhat later without any side-effects.

I think OOP is very basic in today's world. While functional 
programming and relational data programming are their own fields, OOP
concepts are used everywhere, even in languages that are not designed
for OOP. The good habits it teaches about separating your functions
and data sturctures into small units are very useful in C too, for 
example. I don't think you have to learn all about the technicalities 
of multiple inheritence to understand the concepts of abstratction
that OOP is based on, and an OOP language will be good for teaching
those.

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 18 Sep 2001 10:11:08 +0300 (EEST)

> confusing if it does not come together with teaching how processors

I learnt C before I knew too much about how processors work. (it was the
second language I learned after GW-Basic) It took me time to fully master
it, but it was doable. I think C can be taught as a second programming
language if the lecturer will teach somethings about Random-Access Memory,
Random-Access Files, etc.

Knowledge of Computer Architectures can help but it is not entirely
compulsary.

> engineering background, C might be exactly the right language.

We are talking about the first course all students take in programming
during their first semester. By all I mean all students in the Technion,
including those whose fields are entirely unrelated to programming.
(except Medicine students, but that is a different story)

> or C because of its focus on a single paradigm and its automatic

Well I remember learning Java after being proficient in C, C++, Perl,
Pascal and Basic, and having problems grokking it. But it is possible that
it is better.

> want to teach with strong typing.

There is a course in the Technion which is an introduction to programming
in Pascal. No-one in his right mind ever takes it, because then you have
to work twice as hard to grok C in Matam/Mamat.

> but not a first language.

I learned perl when I only knew Basic and C/C++. I didn't even knew UNIX
well at those times. It took me a long time to fully grok it and learn how
to do everything there. (but then again, so it did in C and in C++)

However, I did not even knew UNIX well at that time. One of the problem
with perl is its man pages, which pre-assume they knew what they talk
about it. There are better resources on the web (including something I
wrote myself) but I agree that it is still not very suitable as a first
programming language.

> dependency, about which he didn't elaborate much in the article.

All I know is that I had to write two things in Python, one which I still
maintain. And I had problems, despite the fact I had already known 5 or 6
other languages (including Perl). There were some idiosyncrencies which I
had to overcome, and my code is still not very OOP/FP/Data-Driven Pish. I
did not take the time to learn Python from top to bottom, but I found that
it was not similar enough to the languages I was used to.

> number your lines in hops of 10?

Hmmm. I don't know how you learned BASIC, but when I did, I was used to
the fact that a certain combination of GOTO indicated a loop, that others
were break and continue and that there were conditionals. And naturally
there were gosub-return constructs which accounted for functions.

When I switched to C, it was easy to translate all those constructs into
C's built-in constructs. Don't get me wrong, I saw BASIC code which was a
goto-mess. But you can write very awful code in C too.

I'm not saying I recommend contemporary teachers to teach people BASIC,
but it can be taught properly.

> limited, but very confusing and inconsistent.

Hell. I programmed some very nice Excel and Word macros in Visual Basic
for Applications, and IMHHO it was not very confusing and incosistent.
Naturally, I did not program anything serious in Visual Basic, and I hope
I'll never will have to, so I don't know how it interacts with the Win32
API, etc. What I do know is that neither VB nor VBA has object
inheritance, or lexical scoping, or regular expressions, or any of the
features I came to love from perl programming.

> that OOP is based on, and an OOP language will be good for teaching

I was had a talk with someone who claimed pointer to functions in C were a
"twisted" way of doing things, since you had inheritance. Naturally, in
Java, inheritance is the only way I can think of (without using a dispatch
which is ugly) to do a callback. And in VB, you have to use a dispatch.

In any case, inheritance is useful in many cases, but so are pointers or
references to functions. A person should also know how to program well at
the function level.

My point was that it is possible to teach OOP techniques and methodologies
somewhat later after a person learned how to program. (assuming he learned
how to program well).

There was a fellow student whom I helped with "Structure of OS", which is
a course that EE students can take after Mamat. His code was positively
awful. I'm not just talking about OOP, but he also lacked proper
Structured Programmin techniques, as well as proper modular code. So, I
doubt how successful the Technion is, or can be, in teaching good software
engineering.

Regards,

	Shlomi Fish

>
> 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: "Nadav Har'El" <[email-masked]>
Date: Tue, 18 Sep 2001 19:06:57 +0300

> (except Medicine students, but that is a different story)

Are you sure? Maybe it's changed, but when I was in my first semester
(10 years ago already... time flies :( ) the math department took a course
based on Pascal, and the physics department took a course based on Fortran.
No Unix, no csh (or any shell), only Pascal. Interesting to know this has
changed, though it suprises me that CS students now take exactly the
same course as non-CS students. I'm not sure I understand why...

> to work twice as hard to grok C in Matam/Mamat.

I took that Pascal course. Didn't come to a single lecture (I already knew
Pascal), and then took the test ;)

> goto-mess. But you can write very awful code in C too.

My language-learning story is pretty weird. The first language I ever tried
to learn was Commodore-64 BASIC. I failed: it didn't feel fun (maybe the
fact I was only 9 had something to do with it ;) ), and for some reason (I'm
not sure I can pinpoint it exactly), it didn't feel natural to me. So I left
it alone, and played C64 games ;) About a year later, when my dad got access
to a Unix computer and Kernighan & Pike's book "The Unix Programming
Environment" and Kernighan & Ritchie's orignal "The C Programming Language",
I started learning C and shell, and I actually found it natural and fun (but
not easy - it took me *a lot* of time to become a good programmer).
Some time later I found a BASIC interpreter (written in C) for Unix, and
I returned to learning BASIC, and this time I got it :)

So I doubt anyone can really say things like "BASIC is the best language
to learn first" or "C is the best language to learn first". Any one of these
or other languages can be a good language to learn first, and perhaps even
the best language to learn first depends on the person's character.

But I think a good guideline is to learn a *useful* and *relatively simple*
language first. Useful is obvious (I think beginners like to see the computer
doing interesting things based on their program), and relatively simple
rules out languages like perl, which is a very complex mishmesh of ideas
and features from a dozen other languages. The "there is more than one
way to do it" idea probably isn't the best thing for a beginner, which
first needs to figure out *a* way, and then a *good* way to do things.

-- 
Nadav Har'El                        |      Tuesday, Sep 18 2001, 2 Tishri 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |I planted some bird seed. A bird came up.
http://nadav.harel.org.il           |Now I don't know what to feed it...

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 18 Sep 2001 19:45:06 +0300 (EEST)

> same course as non-CS students. I'm not sure I understand why...

Hmmm, well, let me correct myself. Everybody has to take a course in
programming (except Med Students). Now there is "Intro to CS", which is
taken by CS and EE people and those that wish to learn in a "maslul" which
is a joint of CS and something else. There there's "Intro to CS in C",
"Intro to CS in Pascal" and "Intro to CS in Fortran", which are
alternative courses. "Intro to CS in C" is "Intro to CS" light, and the
other ones are taken by people who want to get rid of this requirement in
their "maslul".

I took "Intro to CS in C" at the time, because I did not knew better at
the time.

> Pascal), and then took the test ;)

When I took "Intro to CS in C" I only came to the T.A. session for the
sole purpose of getting the home assignment. I could not talk the Lecturer
in charge to release me of the course. But I don't complain too much,
because the course required a very minimal amount of work, and I got 94 as
my final grade.

> first needs to figure out *a* way, and then a *good* way to do things.

I never said Perl was the best language to learn first. It is probably
not. In my "Perl for Perl Newbies" series I tried to teach the most
important subset of perl (modules, objects and function refs not included)
for people who are Perl Newbies. I tried to make it as good as possible
for people who are not proficient programmers, but nonetheless are
knowledgable in computers. I can't testify for my own success.

But I'm not sure if C is a better option than Perl. And in C++, OOP is so
picky that I'm not sure if it is worth the advantages of exposing a person
to an object-oriented language. But let's end this discussion that there
are popular languages out there that are better than all three.

Shana Tova to everyone,

	Shlomi Fish

---

From: guy keren <[email-masked]>
Date: Tue, 18 Sep 2001 20:26:33 +0300 (EET DST)

while y'all are biting the dust of all languages, you're forgetting the
simple fact that a good teacher is something that can make up for any
language idiocies, plus the fact that a limited language is good to
exercize one's brain cells. let me share a (life) story with you, to try
and show my point.

when i was in the army, i was a teacher at the 'techni shel cheil avir',
where high-school kids learn. i was teaching 'micro computers' to 11 and
12th graders. teaching started with DOS batch files, went on to some
assembly, and concluded with 808X hardware internals.

when we tought batch files, we showed students important principles, such
as:

1. check user input.
2. account for all possible states (most batch files got names of files or
   directories as parameters, and had to deal with file being there, not
   being there, directory creation failure, parameters missing, etc).
3. writing comments where that's needed.
4. indent the code in a consistent manne.

so, 'dos batch files' was the first language they ever learned.

after they got the hang of it, we moved into assembly language. the
material was never beyond doing bubble-sort, but we decided to take 2
classes far and beyond that point, into the real of programing graphics
games. on the 'formal side', we tought them:

1. structured programming, by use of functions all over the code.
2. handling data structures (it can be done, and easily done, even
   in assembly).
3. debugging techniques (the course was split into frontal classes and
   lab classes, in front of the computer).
4. looping of multi-dimentional arrays and beyond. this was done by
   letting them write a program that draws a chess board on screen.
5. letting them go wild. some students wrote programs such as:

  1. Simon (including sounds and graphical display).
  2. animation cartoons.
  3. a graphical drawing program.
  4. super breakout (the game in which you need to hit a ball and use it
     to break a breek wall).
  5. space invaders (this game wasn't fully completed, due to lack of
     time).

you should note that they were working in pairs, and that not all of them
eventually did anything beyond that chess board drawing program (there
were 2 or 4 which didn't even manage to do that).

eventually, they learned all the things one wishes to teach in an
introduction to programming course. they learned how to write clean code,
how to break code into smal units (functions in our case), hor to lay out
their data structures properly. and all that - using 2 languages which
everyone likes to critisize.

so what was it there? the idea was that we wanted to teach how to programm
and how to think ike a programmer. the programming language itself did not
realy matter, as long as we stuck to a simple syntax (and in this, dos
batch files as well as assembly quite excell). we also made them think in
a non-standard manner. a good example is a lab exam we gave them with dos
batch files - we asked half the class to write a probatch file that prints
out the current time (and ONLY the current time), without using the 'time'
command. and they all managed to do that, btw. i think it shows that they
did learn how to think creatively about problems (or that they already had
that ability beforehand?). you see - one of the advantages of a very
limited language is that it forces you to think (i.e. how to get around
its limitatins, when coming to solve non-trivial problems).

i think that after that, learning other programming languages won't be
hard for them - they already master the _concepts_. true, we didn't teach
them OOP - but i got a feeling that even OOP can be easily tought while
using assembly.

and above all - it was fun.

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: Omer Zak <[email-masked]>
Date: Tue, 18 Sep 2001 19:40:22 +0200 (IST)

> because the course required a very minimal amount of work, and I got 94 as

Betraying my ripe old age, I recall that when I studied Electrical
Engineering in the Technion, the cumpulsory programming course taught
PL/1.  Does anyone nowadays know what was PL/1?  :-)

I got exemption from the English courses, thanks to my good command of
English.  But there was no established way to be exempted from the
cumpulsory programming course for EE students.  So I took the course,
even though I already knew the language.  The grade I got there was good
to my grade average, and offseting the grade which I got in the gym
courses.
                                             --- Omer
There is no IGLU Cabal.  All former IGLU members went back to school.
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

---

From: "Nadav Har'El" <[email-masked]>
Date: Tue, 18 Sep 2001 22:34:48 +0300

> to my grade average, and offseting the grade which I got in the gym

Seeing that everyone is also sharing their Technion programming-course
experience, I'll continue mine :) True, there was no way to get exempt from
the course, but all I had to do was to hand in homework and do a test in the
end. Homework was done in pairs (as typically happens in Technion departments
who are too lazy to really check exercises...), so I paired up with a good
friend who was also taking the course; He brought me the assignment, and I did
half of them and he did half of them. The assignments were pretty easy.
I also went to the first lecture to hear the sylabus and make sure I really
knew the material (I've been programming in pascal, especially Turbo Pascal,
for 4 years before I took that course, and in C for 6 years).

On the final exam I got a 70. I was quite surprised (I thought I was quite
good in programming and the relevant theory), but because it was my first
semester I was about to take this "blow" and shut up. But my parents
suggested to me that I should ask for a copy of the graded exam to make sure 
the grade was justified - they said everyone does it. So I did it, and I saw
that (to the best of my understanding) I did not have any error! Every one
of the places the grader (probably some tired TA) took off points was (in
my opinion) because I had used an unconventional (meaning differing from the
"recipies" they learned in the class) but correct solution. So I appealed,
the professor himself graded it, and my grade was changed to a 98 (!).

This tired-TA (or whatever explains grading errors) syndrom unfortunately
followed me to other big CS courses I took. In the "Automata and Formal
Languages" course we had exercises which were "tsiun magen". I got grades
around 60-70, for petty "errors" (e.g., the way I drew the automata). I
decided to give up on getting a good grade on the exercises. In the final test
I got (if I remember correctly) a 100.
In all the Math courses I took, by the way, the TAs gave fair grades, without
taking shortcuts for themselves. It probably has to do with the small classes
we had in Math courses...

-- 
Nadav Har'El                        |      Tuesday, Sep 18 2001, 2 Tishri 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Hindsight is always 20:20
http://nadav.harel.org.il           |

---

From: "Nadav Har'El" <[email-masked]>
Date: Tue, 18 Sep 2001 23:08:37 +0300

> exercize one's brain cells. let me share a (life) story with you, to try

This is a good point, and a very interesting story.
But there's also an important difference of whether you're teaching
curious people (like me and you), or bored I-want-to-make-a-billion-in-a-
startup-and-I-had-to-take-this-boring-subject-for-it kind of people.

When talking about curious people, the first language is only a start,
and sometimes after several years you stop using it completely after finding
better alternatives. Curious people are always looking into alternatives,
and checking them out. For example, after programming for two years on Unix
and C, on textual terminals, I got fascinated with the world of DOS and
graphics, and Turbo Pascal in particular (this was around 1989 - MS Windows
wasn't a monopoly yet, and VGA displays started to appear in Israel).
So I learned Turbo Pascal, and had a little fun with it, but then I decided
that C is still better, and Unix is still better. I didn't stick to C because
it was the first language I had learnt!
Other things which I learned first I left for (what I considered to be
better) alternatives, like I rarely use troff any more (I use TeX), I
don't use ksh anymore (I switched to zsh), and so on. In other things,
I continue to use both the original program I learned and newer alternatives:
e.g., I use both vi and xemacs, and both awk and perl.

But less curious people will take whatever language you teach them as some
sort of wow-this-was-hard-so-I'll-never-bother-to-learn-another-language
and then you see them, many years after leaving school, trying to apply
the same language to something that doesn't fit the problem. I saw people
write crappy shell scripts with csh, I saw people writing things that should
have been a 3-line shell script in Tcl filled with "exec" calls (because
they only learned tcl, not sh!), people writing horribly-inefficient Perl
(because they only studied some of the features and never bothered to read
the whole book to learn what other features exist). I've seen people
programming in Fortran because that is what they were taught 30 years ago
in the Technion - they even write string-processing programs in Fortran ;)

So while the first language you teach someone *shouldn't* really make a
difference, in reality many people (especially people who don't study CS,
or study CS without really liking it) will never learn a second or third
language - so the language you teach them should be good, general-purpose,
useful, and have a long projected lifespan.

-- 
Nadav Har'El                        |      Tuesday, Sep 18 2001, 2 Tishri 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Diplomat: A man who always remembers a
http://nadav.harel.org.il           |woman's birthday but never her age.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 20 Sep 2001 12:23:46 +0300

Shlomi Fish <[email-masked]> writes:

> However, I told him that it was like saying that English and French
> were the same, because both use the Latin Alphabet.

Wrong analogy. The similarity - and common origin, to the point that
for hundreds of years french was the official language of England - 
goes a long way beyond that. This is not a place to discuss this.

> Knowing English will not make it much easier for a non-French
> speaker to learn French, IMO. (I know it did not help me for the
> short time I studied French).

I strongly disagree (and I'll cite my own experiences to support my POV).

> My first programming language was GW-Basic, which is incredibly
> limited but very good for learning how to program, IMO.

This contradicts the widespread POV that a person who started learning
programming with BASIC is lost for programming forever. Attributions
of this statement are numerous, and I don't know which are correct.

Besides, it makes sense learning using a "live" language. BASIC was
one of the first languages I learned (together with Fortran). Fortran
is still in wide use, and BASIC is mentioned only in books on the
history of the microcomputer industry (like Gates and Allen creating
an implementation of BASIC for Altair).

> Visual Basic (or Visual Basic for Application) is much better, but
> still incredibly limited.

I don't know VB, but from what I saw of it it's incredibly
inconsistent.

> write code where something doesn't work and you have no idea why. ;)

Another reason is that C++ is closely linked with a couple of
important programming paradigms, such as OOP and Generic Programming.
They are important, but the story is not limited to those. Stroustroup
makes an effort to introduce different paradigms in his C++ book, but
does not succeed very well (at least a novice will be left in the dark
- it's too sketchy). Graham does a much better job implementing OOP
concepts such as inheritance in a few lines of code in "On Lisp".

> which I don't know as well, which may also prove useful.

LISP (with CLOS), or Python, but not Perl. Flame away.

> can get exposed to it somewhat later without any side-effects.

It's the paradigms that are important, and should be taught. If there
is a single language that can be used to illustrate all the important 
paradigms, use it. Scheme (SICP) comes to mind.

-- 
Oleg Goldshmidt | [email-masked] 
"If it ain't broken, it has not got enough features yet."

---

From: Omer Zak <[email-masked]>
Date: Thu, 20 Sep 2001 20:58:12 +0300 (EET DST)

> Shlomi Fish <[email-masked]> writes:
[... snipped ...]

> paradigms, use it. Scheme (SICP) comes to mind.

My first language was FORTRAN (FORTRAN IV, to be precise), but I learned
more languages over the years.  Now I am reading the SICP, after having
been exposed to the charms of Python and having decided to learn the most
powerful programming language for the "room for thinking" available.

My question - are there any programming langauges, which are even more
powerful than SCHEME, and which would help a pro (who is far from being
newbie needing to be taught material designed according to basic
pedagogical principles) to have more power in thinking about his
programming problems?
                                             --- Omer
There is no IGLU Cabal.  The former Cabalists have been swallowed by the
black hole of MPPL (Most Powerful Programming Language) and find the
mundane programming problems posed by Linux kernel and applications to be
incredibly elementary, trivial and boring.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Shlomi Fish <[email-masked]>
Date: Fri, 21 Sep 2001 08:20:57 +0300 (EEST)

> of this statement are numerous, and I don't know which are correct.

So, do _you_ agree with this widespread view or not. I believe that if a
person is open minded enough he could get over such BASIC origins. At
least in case he had been taught BASIC correctly.

> I don't know VB, but from what I saw of it it's incredibly

Well, my experiences with VB are mainly with Visual Basic for
Applications, which was the scripting language of Excel, and now I think
Word, Access, etc. too. I now like Perl much better than VBA, but for the
brief time I worked with VBA, I did not find it very inconsistent.

Then again, I only wrote Excel macros, and did not work with the Win32
API. So let's focus on Visual Basic for Applications alone.

> LISP (with CLOS), or Python, but not Perl. Flame away.

My point was that after a person has been taught programming in a language
which does not have very good support for OOP, he can be taught
programming in those languages.

I do not recommend Perl as a first programming language. But then again I
would not recommend LISP either, and I have very serious doubts regarding
Python. (note that I don't know the latter too well)

One of the advantages Perl (and perhaps also Scheme or LISP) has over
Python is that objects are phyisical references to hashes. In that way,
the students learn that objects are not something magical and have a
better idea how it is implemented.

> paradigms, use it. Scheme (SICP) comes to mind.

The question is whether you want to fit all the paradigms during the first
course the students take in programming? I think some of them can be
out-sourced to later on.

Regards,

	Shlomi Fish

---

From: Adi Stav <[email-masked]>
Date: Fri, 21 Sep 2001 13:36:01 +0300

> least in case he had been taught BASIC correctly.

Shlomi, there's no doubt a bright student with a good teacher will 
eventually be able to cope with Intercal as a first language. The
question is not whether a language can at all be used as such a 
first language -- any language can. But some languages suit this
purpose better than others.

[VB discussion snipped]

> Python. (note that I don't know the latter too well)

I don't know LISP. Why not Python?

> better idea how it is implemented.

First of all, since classes and types in Python ARE implemented using 
hash tables, this implementation detail is exposed in the language in 
a similar manner to Perl's -- every object has a member called 
__dir__, which is a hash table containing all the members according to 
their string names. 

But I doh't agree with this approach to start with. Every (good) 
language is based on certain key CS principles, in this case objects.
Once you choose principles to teach programming by, you should stick
to them. It is counter-productive to explain those principles by 
other, new principles and confuse the students.  I don't see why a 
hash table is any less magical than a plain object. What is less 
magical in foo["bar"] than in foo.bar? The two are almost completely 
equivalent semantically and are very similar syntactically. A student
had better first learn the normal way to do things -- the dynamic
nature of Perl and Python is very valuable to programmers who wish
to access members whose names are not known in advance, but I don't
think novices should learn this feature before mastering the proper
way to do things. This is the same reason why I don't think "goto"
should be taught before "for", even though the second is implemented
using the first.

(Another thing is that hash table is not necessarily the right
way to implement objects. For higher-performance, less-dynamic
languages such as C++, an object is implemented using memory offsets 
and the string name does not survive the compilation stage. So showing 
students that objects are really hash tables don't teach them much 
about the inherent nature of objects. But I agree this is still
an arguable point because one can always say that the compiler DOES
keep a hash table of all the members, and that the translation of this
hash table into offsets is just an implementation detail.)

> course the students take in programming? I think some of them can be

I fully agree here. Teach the most common / most generic ones first,
worry about the rest later.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 23 Sep 2001 09:50:01 +0300

Omer Zak <[email-masked]> writes:

> powerful than SCHEME, 

[Relative] "power" of programming languages, and the validity of the
very concept, was discussed on this list briefly a few months ago, in
connection with Paul Graham's article "Beating The Averages".

> and which would help a pro (who is far from being

I am biased by my own preferences, but I would strongly suggest Common
Lisp (supplemented by CLOS). Get Graham's "On Lisp" and "ANSI Common
Lisp" to have fun with important programming paradigms and ideas, and
for deeper understanding why "theoretical" buzzwords that Lispers
throw around are practically important. Gems like implementation of
inheritance in 6 lines of code (in a non-OO language) make for real
fun and instructive reading.

Having said that, and at the risk of repeating myself unnecessarily, I
maintain that "thinking about ... programming problems" is largely
language-independent.

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 23 Sep 2001 10:24:11 +0300

> maintain that "thinking about ... programming problems" is largely

I agree to that, though to understand certain concepts you usually need to
be familiar with at least one language that has them. For example, it's hard
to apply the concept of dynamic memory allocation when all you've used is
Fortran 77, it's hard to think in an OO way if you've never been introduced
to a language that allows OO programming, it's hard to think about using
small external utilities and pipelines to create a program if you've never
seen a shell, and so on.

I don't think it's needed, however, to have a single language that has
all these features in one place. Just as a person can be taught to think
in more than one natural language (do you really believe I'm thinking this
email in Hebrew and then translating it to English? Of course not! That
would be increadibly slow and inefficient), they can be taught to think using
concepts from a wide array of programming languages and paradigms. These
concepts could be so different that they can't logically be combined in one
coherent programming language - but they can be combined in one thought
process.

-- 
Nadav Har'El                        |       Sunday, Sep 23 2001, 6 Tishri 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |You do not need a parachute to skydive.
http://nadav.harel.org.il           |You only need one to skydive twice.

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 23 Sep 2001 16:17:15 +0300 (IDT)

> purpose better than others.

Agreed.

> I don't know LISP. Why not Python?

Well, I had (and still have) to write and maintain a python script, and
despite the fact that I know Perl, C, C++, Scheme, etc. very well, I had
quite a lot of problems with it. I admit that I did not read von Russom's
intro from the beginning to the end, but rather was looking for quick and
dirty solutions.

In any case, I found out that a lot of things did not behave as I expected
them. For instance, the fact that by default a print appends a newline to
its output. Or the fact that "shift" is "pop(0)". In any case, I assume a
newbie will encounter such mishaps too, if he is taught Python as a first
programming language.

Like I said earlier, I do not know Python well enough to testify for its
suitability as a first programming language. So let's drop this
discussion.

> __dir__, which is a hash table containing all the members according to

Cool. I did not not know that.

> should be taught before "for", even though the second is implemented

I do believe associative arrays (or dictionaries or maps or whatever you
wish to call them) are more basic perceptually than objects. A smart
student can create a non-optimal implementation of an associative array
himself. A teacher can take some time to ask the students how an
associative array may be implemented. He need delve to specific
details about hashes.

Object on the other hand is not exactly an Abstract Data Type but rather a
programming tool. It is important for students to realize that there's
nothing magical about its implementation, but rather that it is
implemented in some manner by the compiler or interpreter.

> hash table into offsets is just an implementation detail.)

I did not say that a hash table was the ideal way to implement an object.
I am aware of the offsets' implementation and realize both hashes and
offsets have their advantages and disadvantages.

Pardon a perl programmer for using hash where associative
array/dictionary/map would have been more in place.

Regards,

	Shlomi Fish

---

From: Adi Stav <[email-masked]>
Date: Mon, 24 Sep 2001 00:17:37 +0300

On Sun, Sep 23, 2001 at 04:17:15PM +0300, Shlomi Fish wrote:
[snip]
> newbie will encounter such mishaps too, if he is taught Python as a first

It sounds like both of these problems are related to being used to 
Perl already. The pop/shift problem is a purely syntactic issue 
regarding which a programming novice will have no biases. I consider 
both of the names equally unnatural. Regarding print, I *really* don't 
think the expectation of an unexperienced programmer would be for 
print to add no leading newline. This would only be expected by a
programmer who is familiar with basic I/O principles.

> suitability as a first programming language. So let's drop this

Okay.

[snip]
> wish to call them) are more basic perceptually than objects. 

The teacher chooses the basic perceptions. Some things might be 
simpler or easier, but what is basic depends on the fundamentals
initially chosen. If you teach objects, then later hash tables
can be "just like objects but dynamic", or implemented using
objects. The first is no more true than the second. 

> A smart

Implementation is irrelevant to understanding. You don't necessarily
need to know about vtables and garbage collection in order to 
understand the essentially simple basic nature and use of 
polymorphism or references. Their implementation is an advanced topic
that possibly belongs in a completely different subject.

> implemented in some manner by the compiler or interpreter.

You don't need to teach students about multiple inheritance right
from the start. In fact you don't need to teach inheritance at all
in order to teach the concepts of abstraction and encapsulation.
Advanced OOP topics require not only more abstract thinking about 
programming, but also the ability to handle the more complicated
programs in which they make sense. 

At the level of simply declaring objects, an object is not that 
different from a hash table at all. It is less dynamic -- which is 
good to study with. But it can also use to access methods very 
naturally, which you cannot do through hash tables without first
teaching the more advanced notion of function references. The fact
that a concept has a simple and integrated beauty does not 
necessarily mean it will make good material for the very first
lesson. Separation of code and data is important to understand
before learning how to blur the difference.

> array/dictionary/map would have been more in place.

I don't mind either. If at all, "hash" is short and simple.