[Haifux] My "Stop Using (and Teaching) C-Shell and Tcsh" Page

[Shlomi Fish]

On Friday 19 October 2007, Orr Dunkelman wrote:
> On 10/19/07, Shlomi Fish <shlomif at iglu.org.il> wrote:
> > Hi Orr!
> >
> > For some reason, I'm receiving the emails that you send to me, but not
> > the emails you send to the mailing list. It's a bit annoying. And I do
> > receive emails that get sent to the mailing list.
>
> I don't know what is the cause of the problem.
>

As it turned out the problem was that I had the "no duplicates" option turned 
on for my account in the mailing list.

> I can only conjecture that you procmail me...
>

I don't filter you. I filter the Haifux mailing list based on the List-Id: 
header, but that's all. I should note that I'm not using procmail to filter 
my messages, but rather the KMail built-in filtering system. It's kind-of 
lame, but it has very good integration with KMail, so if I move a mailbox, it 
will also be moved in the filters.

> > Exactly. The point is not to teach the beauty of shell scripting.
> >
> >
> > Then what is the point? To teach a crippled programming language, not
> > unlike
> > many others?
>
> Actually - yes.
> The idealized version of the world where you teach only the useful staff is
> far from being right for education due to many reasons. For example, the CS
> dept. of the Technion still uses the assembler of PDP11 to teach assembler.
> Now, if I had to "change" anything in CS in second semester, I would start
> with PDP11 and not with CSH. 

I don't care particularly which Assembly[1] language students learn, as long 
as they do learn Assembly, and this Assemebly allows them to learn anything 
they need, and it is taught right. I was told there are reasons for teaching 
PDP-11 Assembly (or in EE's case - VAX Assembly).

However, teaching C-shell is Evil from the reasons I gave, and should be 
corrected.

{{{{{{{{{
[1] - Assembly is the language, while Assembler is the program that translates 
it to machine code.
}}}}}}}}}

> The reason for that is (hopefully obvious). On 
> the other hand, the students will not gain much from this transition (in
> the overall). On one hand, now they'll know assembler of i386 (which is
> certainly more useful). On the other hand, now they'll have to spend lots
> and lots of time on addressing the long jump vs. the short jump (and we are
> not getting into the problems of 64-bit addresses!). So all in all, they
> still teach PDP11 because they have a good reason (because they want to
> teach the idea behind assembler, and not how to write assembly code for
> i386. Once you get the general idea of assembly, switching from PDP11 to
> i386 is only small details).
>

Right.

> So I guess teaching TCSH had its merits in the past. You will need to ask
> the teachers why they teach this.
>

Perhaps they wanted Tcsh because it had better interactive features than 
Bourne Shell (/bin/sh) had.

> > I suggest you'll approach the lecturers in charge to get a better
> >
> > > understanding why they teach this shell rather than that shell (like
> >
> > Eyal
> >
> > > did).
> >
> > Maybe I will. But I still think my Anti-csh page was a good idea for
> > concentrating all the arguments in one place.
>
> An Anti-XXXX page is always the wrong place to start any of these things.
>

Why?

> > > As for the "beauty" thing - beauty is in the eye of the beholder.
> >
> > True, but I think we all can agree that shell scripting without sed, awk,
> > find, and much less Perl or whatever, is much less beautiful than shell
> > scripting with them. And I don't see a point in teaching it this way.
>
> No. We do not agree on that.
>
> I used to do shell scripting in DOS (batch files), where sed, awk, and
> other cool stuff were not available.

DOS has a poor excuse for a shell. Someone told me that 100-lines of DOS Batch 
files he wrote ended up as 50 lines of C. The Windows NT shell (CMD.EXE) is 
much better, but still very bad in comparison to what Bash offers.

Windows is going to have the so-called Windows PowerShell - 
http://en.wikipedia.org/wiki/Windows_PowerShell , which is based on .NET, 
more high-level, and Windows-specific. And naturally, you can install bash or 
zsh on Windows using cygwin or a different Windows emulation.

>
> And we are talking about concepts. I find the concept of using a smaller
> instruction set to be actually more elegant then using many commands (think
> of interoperability of a DOS batch file between various windows
> distributions without any real support for stuff).

Well, as much as a smaller instruction set has its merits, tools like find, 
sed (or its equivalents), etc. are an integral part of shell scripting and 
good shell programmers are expected to put them into good use.

Like it or not a small amount of primitives, can and usually is too limiting. 
Consider for example what Bjarne Stroustrup writes in 
http://public.research.att.com/~bs/bs_faq.html#Java :

<<<<<<<<<<<<<<<<<<<
Much of the relative simplicity of Java is - like for most new languages -
partly an illusion and partly a function of its incompleteness. As time
passes, Java will grow significantly in size and complexity. It will double
or triple in size and grow implementation-dependent extensions or libraries.
That is the way every commercially successful language has developed. Just
look at any language you consider successful on a large scale. I know of no
exceptions, and there are good reasons for this phenomenon. [I wrote this
before 2000; now see a preview of Java 1.5 - http://xrl.us/kb3a ]
>>>>>>>>>>>>>>>>>>>

Also as Paul Graham notes here - http://www.paulgraham.com/power.html - 
succinctenss is power. If you reduce the number of primitives a language 
provides, then you'll probably need to write more code, and as a result your 
language will be very unpowerful.

As for writing portable DOS Batch files - don't go there. Seriously, it smells 
badly there. Even C is better. There are other FOSS alternatives that can 
write on DOS with DPMI, and it would be a better idea to use them. 

> > > For us it is very easy to say "yeah, this can be solved by find". But
> >
> > these
> >
> > > students need to learn how to implement find in a crippled scripting
> > > language, because when they'll leave the academy and go to the dark
> >
> > side,
> >
> > > a.k.a., industry, they will have to work on machines which are not even
> > > POSIX complaint!
> >
> > And I expect these machines to have an equivalent to a find command. Or
> > you
> > can compile GNU find there.
>
> Shlomi, I think you lack some experience in real life companies. In many
> companies, you are not the owner of your machine (even in the CS dept., as
> Eyal can attest). You are the user of the machine the company supplied you.
> You cannot install whatever you like (due to legal issues, security
> reasons, or personal vendettas (e.g., a system administrator who despises
> RMS personally)). So you cannot do that.
> Sorry.

OK, so these machines don't have find? Does it mean that you shouldn't teach 
find as part of shell scripting? If you want people to learn shell scripting, 
you should show them the find command. If they are bright enough they'll know 
how to implement the command using them.

If you want to show them how to implement a find-like command recursively, 
then you don't really teach them shell scripting. Find is part of the POSIX 
standard. 

>
> What people who work on machines which do not even have a C compiler do?
> (and btw, there are many such machines in the world, or more precisely, the
> majority of them do not have C compiler). There is a whole set of embedded
> systems, low-end devices, sensor networks, with very limited capability
> even to store the binaries they really need, so talking about even an extra
> 1 KB of a binary so Mr. Fish could use find in his shell script (rather
> than implement it using what he has) is so out of the question.

I don't expect my knowledge of shell scripting to be used in such extreme 
conditions. We don't teach shell to be able to cope with programming 
micro-embedded devices.

>
> Please note that it is easier for a person to learn to solve a problem with
> limited tools, and then add more tools, rather than teaching him how to
> solve a problem with all the tools, and then start to take them away.
>

I'm not sure. If you start teaching Assembly and then C, and then more 
high-level languages, then you'll most likely end up with people who'll write 
Assembly in Perl or Common Lisp. As someone once said "A good Fortran 
programmer can write good Fortran in any programming language".

I suggest starting from the very high level showing people powerful 
abstractions, and then introducing them to more and more low-level stuff, 
while showing them how the high-level abstractions can be implemented or 
replaced. 

> Or in other words - The world is not made out of the standard IT you
> usually see around yourself. It has way more than that!
>

We were talking about whether find should be taught as a part of shell 
scripting. You said that people may have to work on something that doesn't 
have find. Well, people can work on many things. I suggest teaching people 
about "find", but also making sure they'll know how it works and how to 
implement something basic that works like that.


> > But back to our point - yes, students should know how to implement
> > something
>
> > like find. But it's not a good practice to use it in one's shell script,
> > not
> > the right way to do it, and that's what find (which will take some time
> > to implement properly by hand) is meant for.
>
> According to your view.
>
> According to my view, a programmer who cannot write for a restricted
> environment is not mature enough. And if you think this is only a problem
> of low end devices, I can assure you that driver developers also have to
> squeeze their code, squeeze their memory usage, and use only a limited set
> of instructions (as they work in kernel space rather than user space). Your
> vision about teaching the students will lead to students who need to work
> very hard to be able to work in kernel space.

See what I said above. I don't see how teaching shell scripting in Matam/Mamat 
is supposed to prepare the students for developing kernel drivers. That's not 
the point of why shell is taught in Matam/Mamat.

> > People, please remember we are talking on a degree in computer science
> > (or
> >
> > > EE), i.e., you do not learn JAVA, you learn OOP methodology (for
> >
> > example,
> >
> > > by using JAVA). These two things are completely different.
> >
> > First of all, it's not "JAVA" it's "Java". Secondly, I agree, but if you
> > learn
> > shell scripting, then find is part of shell scripting.
>
> Only in UNIX. Not in Windows (yeah, I know there is find for DOS, but,
> let's be realistic, you cannot even compare the two, and as I said you
> cannot install GNU tools whenever you go).

If Matam wishes to show people how to survive in god-forsaken environments 
like that, then it should show a people how to implement a shell from bare 
bones, relying on nothing except a C compiler. But that's not the point of 
the exercise. The point is to show people how to use the UNIX shell, which is 
a more high-level environment than C. How to manipulate files, directories 
and other resources using it. And the philosohpy of shell scripting.

>
> > oh, these kids who never worked on COBOL... ;)
> >
> > Let me know when you'll be ready to have COBOL as your shell. ;-)
>
> I can tell you that there are systems with even more horrible shells. And
> unlike people who live in the internet between CPUs of two cores with 2 GB
> RAM, and 120 GB hard drive, there are people who live on ARM, 6805, or
> slightly advanced FPGAs. These people have to make it with much less than
> the first set of people have at their disposals.
>

Shell scripting makes no sense for an embedded ARM device, and when it does, 
you'll know that, and you can use it, and if you need find you can just add 
it to BusyBox or whatever (because likely a pure-shell solution would be more 
memory hungry). And the people who "live on" ARM actually use a different 
machine for developing the code, on which they build it, compile it and 
upload it to the embedded test environment. So they have more luxuries at 
least for development. 

Regards,

	Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif at iglu.org.il
Homepage:        http://www.shlomifish.org/

If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
    -- An Israeli Linuxer