software engineering;  was: Is this official blog article intended as a joke?

Actually, the 'blog makes a useful point:

Most computer science students get to learn high-level programming languages and application development but they don’t really understand computers.

JMO/YMMV:

Now, while interfacing to the real world is fun, RasPi doesn't really address the high-level application problem.  It's still a GNU/Linux box, running a mainframe operating system with dozens of processes.  It's darn cheap for a mainframe, but it's still a mainframe.

If you really want to learn what computers do IMO you really need to learn assembly language and run it on a real mini- or micro-computer with no operating system present to protect you from stomping all over your code and data so that your program goes off to la-la land.  That's when you really see that all that's in computer memory is bit-strings, and the computer will interpret them as instructions or data depending on where you told it to execute -- whether you meant to or not.  Once you've mastered the machine-language level, then you can understand why your C program is misbehaving in that extraordinary fashion.  IMO this mastery is necessary for someone to be called a computer scientist, just as you expect an EE to know how to use Kirchhoff's Laws and a mathematician to be able to do Epsilon-Delta proofs.

> IMO this mastery is necessary for someone to be called a computer scientist,

Of course, computer science is a big field, with many specialties, and many layers

of abstraction, and it's entirely possible for hardware specialists to know very little

about software, and vice versa.  And theoretical computer scientists often know very

little about either software or hardware, focusing their attention on topics like

algorithmic efficiencies that don't provide any benefit on realisitic sized data sets.

Dijkstra famously said "computer science is no more about computers than

astronomy is about telescopes."

Of course, it's still important to know how to read an abend dump when you have to.

coder27 wrote:

 

> IMO this mastery is necessary for someone to be called a computer scientist,

 

Of course, computer science is a big field, with many specialties, and many layers

of abstraction, and it's entirely possible for hardware specialists to know very little

about software, and vice versa.  And theoretical computer scientists often know very

little about either software or hardware, focusing their attention on topics like

algorithmic efficiencies that don't provide any benefit on realisitic sized data sets.

I would guess that someone who has mastered Universal Turing Machines understands the equivalence of instructions and data a whole lot deeper than I do

I'll go a bit out on a limb and say I don't think the equivalence of instructions

and data is necessarily fundamental to computer science.  I agree with you

that when debugging C, you will often see the machine fault when it tries to

mistakenly execute data.  But that's to some extent an artifact of C's broken

abstraction model.  You don't often see that happen say in Java.

C for example uses pointers in places where it's completely unnecessary,

such as passing a parameter by reference.  Pascal and similar languages

treat reference parameters at a higher level of abstraction, eliminating the

need for pointer syntax.  And stray pointers are probably the most frequent cause

of machine faults.  I think it's been said that pointers are to data what gotos

are to code. 

Computer scientists should understand the difference between value semantics

and reference semantics, but shouldn't fundamentally need to understand about

machine faults due to mistakenly trying to execute data.

coder27 wrote:

 

... I agree with you that when debugging C, you will often see the machine fault when it tries to

mistakenly execute data.  But that's to some extent an artifact of C's broken
abstraction model...

Nothing wrong with C's abstraction model.  IMO you just need to regard C as a portable assembly language that uses high-level notations.  When people think of it as a high-level language, that's when trouble begins.

C for example uses pointers in places where it's completely unnecessary,

such as passing a parameter by reference.  Pascal and similar languages

treat reference parameters at a higher level of abstraction, eliminating the

need for pointer syntax.  And stray pointers are probably the most frequent cause

of machine faults.  I think it's been said that pointers are to data what gotos

are to code. 

Well, when processors give me higher-abstraction instructions I'll think about dropping pointers and gotos.  As long as CPUs let me use registers as memory addresses and provide jump instructions I'll keep using them, because they work well if you use them properly.  You do want to master the basics before using them, but IMO it's silly to leave training wheels on a bicycle forever.  JMO/YMMV

> but IMO it's silly to leave training wheels on a bicycle forever.

It all depends on what the cost is.  If protecting yourself from

machine faults is nearly free, for example because your higher

level language enforces its abstraction model, then why not.

Parameter passing and array indexing are inherently high-level

abstractions that although they will be implemented with machine-level

code, they need not use machine-level pointer syntax.

The equivalence of code and data was a factor early in the history

of computer science, when it was believed that self-modifying code

was important, especially in AI where machine learning was thought

to require "rewiring" the brain. And LISP was ideal for self-modifying code. 

Since then, self-modifying code has fallen into disfavor, especially

with viruses taking advantage of executable stack pages in certain OS's. 

So I think the trend in CS is to as much as possible keep code and data

separate.  They can each have their own memory pages, with code pages

being read only, and data pages being non-executable. They can even have

their own separate caches in a harvard architecure.

> but IMO it's silly to leave training wheels on a bicycle forever.

It all depends on what the cost is.  If protecting yourself from

machine faults is nearly free, for example because your higher

level language enforces its abstraction model, then why not.

Parameter passing and array indexing are inherently high-level

abstractions that although they will be implemented with machine-level

code, they need not use machine-level pointer syntax.

The equivalence of code and data was a factor early in the history

of computer science, when it was believed that self-modifying code

was important, especially in AI where machine learning was thought

to require "rewiring" the brain. And LISP was ideal for self-modifying code. 

Since then, self-modifying code has fallen into disfavor, especially

with viruses taking advantage of executable stack pages in certain OS's. 

So I think the trend in CS is to as much as possible keep code and data

separate.  They can each have their own memory pages, with code pages

being read only, and data pages being non-executable. They can even have

their own separate caches in a harvard architecure.