[prog] Theoretical vs practical: was Sample implementations of UNIX utilities.

Jenn Vesperman jenn at anthill.echidna.id.au
Mon Dec 30 02:43:24 EST 2002


On Sun, 2002-12-29 at 22:22, Meredydd Luff wrote:
> OK, ante upping somewhat here - once again, the opinions expressed within are 
> my own, and not necessarily those of my employ-oops, wrong disclaimer. But 
> you get the idea.

> Yep, I'm a case in point. I don't even know what a register *is*

Temporary storage in the CPU, usually one word long. But that may be
because (IIRC) a word is defined as 'the length of the register'. or
some such.

The bank of registers is the computer's equivalent of our
ultra-short-term memory - the stuff we can 'hold in our head' for a
short time.

> What most people mean by "a computer" 
> is the hunk of hardware sitting on your desk, and you learn far more about 
> how *it* works by learning a low-level language than by studying lamda 
> calculus.

That depends on your definition of 'how it works'.

Meredydd: you seem to be interested in 'how can I make it do what I
want'.

Robert: you seem to be interested in 'how can I make it run instructions
most efficiently'.

So you're both right - for your own definitions.

At a certain level, programmer-time is more valuable than CPU time, so
Meredydd's definition is the most appropriate working definition. How
can I get the computer to do what I want, using tools such as languages
and compilers?

However, even in commercial programming, there are applications where
CPU time is more valuable than programmer time. Dancer tends to
specialise in those, so I know of several real-program examples. 

Filtering software for schools is one - you need to go through thousands
or even millions of rules and cases, doing string comparisons, without
impacting on the apparent performance of the browser, using the cheapest
hardware you can manage to do it with.

When this occurs, you need to know how the CPU works, and which
comparison tools are fastest, and whether the 'if-then-else' syntax is
faster for this purpose than the '?:'. Or you need to be able to find
out.

That's when Robert is right.


So, as with almost everything to do with programming, the answer to
'which is better, A or B?' is 'Both'.

(Ok, ok, that's an overly sweeping generalisation. But I can't think of
a counterexample offhand.)

> I rather liked that quotation Jenn (I think it was) gave about how concepts 
> of the One True Language would be called a childhood disease of programmers 
> if so many adults didn't do it too <g>

That was Robert's, but I agree with it. (Actually it was Stroustrop)
(sp?).
 
> > who think that they know C and
> > Perl, and thus they know Everything Worth Knowing about programming.  We
> > need to open our eyes to other ways of thinking about computation, other
> > ways of solving problems.
> See Jenn's point about how that happens all the time, in all languages and 
> indeed all walks of life, but computing especially. 

I disagree with 'computing especially'. Most of us see it most in
computing because that's what we do, but my father and brother are
driving instructors.
Know It All Already disease literally kills in that field. And they get
it SOOO much of the time. :(

> True. I imagine the area of programming as a field that any one language is 
> good at as a coloured blob, which gets fainter around the edges. I often do 
> even the faint edges in C for pleasure's sake, but I still think that the 
> nice bold area where it's definitely practical is larger than you do.

Nice description. I agree with the theory - each language is useful in
its field.

> > Sure, the skills are valuable.  I'm not suggesting anyone should say
> > "bah, why learn C, it's useless".  But a skill that's just as important
> > is being able to choose the right tool for the job, and being able to
> > use that tool effectively.
> Agreed. But you started off suggesting that the students on this computing 
> course should learn something more high-level _instead of_ C, which shrinks 
> the toolbox as much as doing C at the expense of all higher-level languages.

My preference for this is what they did at my university, which was
teaching all the students a range of languages. 

In first-year, we were required to learn a representative of each major
language family, informed that this was the case, and given an overview
of the purposes of each family.

For the curious, they were:
Procedural: Modula-2 (C in 2nd and 3rd year Comp Sci and Software Eng.)
Functional: Miranda
Declarative: Prolog (AI students later also studied Lisp)
Relational Database: SQL, with the note that it did not conform to the
pure definition of a relational database. We also had an experimental
language, whose name I have forgotten, which did conform.

> But you still don't acknowledge that it's ever a reasonable language for 
> ordinary systems programming. You still shoebox it into "times when 
> performance is important", and then go on, in the face of quite a bit of 
> evidence, to say that realtime computing, low-level drivers, virtual machines 
> and the like are the only times where the performance advantage is even worth 
> looking at.

Robert's opinion is as valid as your own, Meredydd. If he doesn't want
to acknowledge that, then fine. IMO, you should each state your point
and your reasons, then if that is not convincing to the other, agree to
disagree.

> > Read Chapter 24 of Stroustrup's "The C++ Programming Language".  He
> > makes a very good point, one which I wish more of my managers
> > understood, that programmers and programming languages aren't identical,
> > and that by forcing everyone in a department into the same
> > lowest-common-denominator you wind up wasting (a) the best talent in
> > your office and (b) the best tools in your toolbox.

Utterly agreed, Robert! People do need to use common tools to an extent,
but not to that extent.

> Was this in reference to the last paragraph still? If so, I take your point, 
> but once you're taking the time to use a very powerful tool properly, you're 
> comparing apples and oranges when you put that next to other languages.

People are different, and comparing people is also comparing apples and
oranges. :(



Jenn V.
-- 
    "Do you ever wonder if there's a whole section of geek culture 
        	you miss out on by being a geek?" - Dancer.
 My book 'Essential CVS' will be published by O'Reilly in 2003.
jenn at anthill.echidna.id.au     http://anthill.echidna.id.au/~jenn/





More information about the Programming mailing list