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

Aparently it was extracted from a whole magazine full of similar stuff:

I don't think it's meant as a joke which makes the technical content even more worrying.

MK

There seems to be a meme going around that PC's are devices primarily

intended for media consumption, and therefore aren't suitable for creative uses

such as content creation or software development, because the only programming

language supposedly available on PC is Visual Basic.  See this stunning claim:

"With a PC, one has to use software such as Visual Basic to do any programming. This not easy for a newcomer. The Pi in Raspberry Pi refers to Python which is an easy to learn programming language."

http://www.element14.com/community/people/mistertee/blog/2013/04/01/some-basic-presentations-on-getting-started#comment-22438

I've programmed in VB before and now am trying out Python.  I can definitely say I prefer VB, Python seems odd, like the way they force blocks based on indentation, not declaring variable types like a standard language.

Colecago,

   Every language takes some getting used to at first.

There is no such thing as intuitively obvious programming language syntax,

and each language feature has both advantages and disadvantages. 

Python is pretty unique in regard to the significance of indenting.

It has the advantage of looking simpler without all the curly braces,

and has the advantage that the indenting can't be misleading,

but can make subtle mistakes hard to notice.

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.

Hey Coder27, I'll refer this over to the blog author to weigh in.  Thanks members for the feedback and the conversation that is following. 

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