Warp wrote:
>   I believe that the most usual reason for the negative attitude is
> that the "noobs" are getting the job "done" faster, but at the cost
> of software quality. The software made by a newbie usually lacks
> robustness and efficiency. However, because bosses usually cannot
> see past the GUI, they are fooled into thinking that the newbie is
> actually a better programmer than the experienced one because he got
> something visible done faster. Then they hire the newbie and kick out
> the experienced programmer.

This reminds me of a problem that I saw working in the math study center 
at my local college.

We were explicitly told not to help the Business Math students with 
their homework, because the requirements of what they wanted were so 
different from what students in the regular math courses needed. 
Specifically, they didn't need to know "how it worked", just "how to 
press buttons on a calculator to get the correct result".  As a result, 
it was felt that our teaching them correct mathematical principles would 
be a waste of time, both theirs and ours.

This drove me nuts.  In fact, on several occasions (when there weren't 
other students needing help), I explicitly ignored the instructions and 
helped the business math students.  But I wouldn't do it the way their 
instructors wanted (press this button, get this result).  Instead, I 
would teach them the theory behind what they were doing, to the point 
that if they forgot the correct button press, they could still work out 
the answer (or at least, figure out what buttons to press on their own). 
  Usually, they expressed gratitude for my helping them to finally 
understand what they were doing.

I think software is the same way.  While I never coded with 1s and 0s, 
relatively soon after learning BASIC I learned x86 assembly, in real 
(not protected) mode.  Things like pointers aren't a problem to me, 
because they're an inherent part of computer architecture (virtually 
everything uses pointers), and I understand the underlying architecture 
fairly well.  I'm not against using VB, C# or LISP, per se.  But I *do* 
think that my understanding of the underlying architecture is important 
even in those languages.

The disdain that "real" programmers feel for newbies who crank out quick 
code using "toy" languages is, I think, more akin to the disdain "real" 
mathematicians feel towards business math majors.  Sure, they can "press 
the buttons", but they don't really know what they're doing.  It's not 
about jealousy - after all, many programmers who started out writing 
assembly code are now using higher level languages and cranking out code 
just as quickly.  It's about perceived understanding of what your code 
actually does.

Personally, I think this understanding is so important that I would say 
*all* programmers should, at one point or another, learn to write 
complete programs in assembly language, by hand.  Not that they should 
use machine language for their jobs, but because knowing how computers 
*really* work will help them write better programs in the long run.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> Personally, I think this understanding is so important that I would say 
> *all* programmers should, at one point or another, learn to write 
> complete programs in assembly language, by hand.  Not that they should 
> use machine language for their jobs, but because knowing how computers 
> *really* work will help them write better programs in the long run.

I never went lower level than C. (well, I have looked at the 
assembly-like code for LEGO RCX, but I doubt that counts; there aren't 
even pointers there) I think some day I should learn asm...

Post a reply to this message

Chambers wrote:

> Personally, I think this understanding is so important that I would say 
> *all* programmers should, at one point or another, learn to write 
> complete programs in assembly language, by hand.  Not that they should 
> use machine language for their jobs, but because knowing how computers 
> *really* work will help them write better programs in the long run.

This, presumably, is why my course included a module on microprocessors, 
machine code, binary representation, etc. It probably didn't help in the 
slightest that this module was taught by Mr Apothetic. Seriously, I have 
*no idea* WTF this guy's problem was, but damn...!

"Well this stuff is in the exam so I *suppose* I'd better teach it to 
you. But it's pointless really. You'll never actually *need* to know 
this stuff." Way to motivate your students, man! [Yes, these are the 
actual words he used. His emphasis.]

But then, his views on BP were quite similar. "Oh yes, I understand 
they're trying to 'rebuild Colossus'. Pointless really. The actual 
machine was destroyed, so it'll never really be exactly like the 
original. And what will they *do* with it anyway?" Jesus, dude, take a 
pill or something!!

It really made me sad. This _would_ have been one of the most 
interesting parts of the course... much more fun than learning Java or 
how to balance accounts...

Post a reply to this message

Nicolas Alvarez wrote:

> I never went lower level than C. (well, I have looked at the 
> assembly-like code for LEGO RCX, but I doubt that counts; there aren't 
> even pointers there) I think some day I should learn asm...

The concept of assembly without pointers bemuses me.

I don't "get" what's so hard about pointers. All data is stored in the 
computer's memory. The memory is a vast grid of numbered cells. Each 
cell's number is called an "address". A "pointer" is simply something 
that holds the address of something else - it "points to" something. The 
End.

Now, pointers and typecasting... scary stuff!

Post a reply to this message

Darren New wrote:
> The part others seem to think you lack is the knowledge of how to 
> structure a document that's bigger.  You need to be able to say (a) why 
> would the reader want to read this document, and (b) present it in an 
> order and form that makes it easiest to understand.

The following structure from public speaking applies to pretty much any 
technical document or report, as well.

a) Tell the audience what you're going to say.
b) Say it.
c) Tell them what you said

:)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Orchid XP v8 wrote:
> Heh. I've still failed to convert even one single person to Haskell yet. 
>  >:-)

Consider that I'd never even *heard* of Haskell before I read your posts 
here.  In fact, I *still* haven't gotten around to learning LISP, Ruby, 
Perl, Python, Smalltalk, Lua, or any of a number of languages, although 
I *have* looked at them and considered learning them.

In fact, C# is the first time in about 10 years now that I'm learning a 
*new* language, and its only a derivative of the ones I already know.

Getting people to invest time into something like learning a new 
language is difficult, at least, and close to impossible, in many 
situations.  Just keep plugging, and don't lose hope :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:

> The following structure from public speaking applies to pretty much any 
> technical document or report, as well.
> 
> a) Tell the audience what you're going to say.
> b) Say it.
> c) Tell them what you said
> 
> :)

Ah yes, the "tell them thrice" structure.

I pretty much suck at that. It's true... :-{

Post a reply to this message

> Nicolas Alvarez wrote:
> 
>> I never went lower level than C. (well, I have looked at the 
>> assembly-like code for LEGO RCX, but I doubt that counts; there aren't 
>> even pointers there) I think some day I should learn asm...
> 
> The concept of assembly without pointers bemuses me.

The RCX has numbered variables (16-bit signed integers). There is no 
real access to "memory". Although the 2.0 firmware supports indirect 
access (indirect(3) reads get_variable(get_variable(3)) ) so things like 
indexing an "array" in a loop is possible.

Post a reply to this message

Chambers wrote:

> Consider that I'd never even *heard* of Haskell before I read your posts 
> here.  In fact, I *still* haven't gotten around to learning LISP, Ruby, 
> Perl, Python, Smalltalk, Lua, or any of a number of languages, although 
> I *have* looked at them and considered learning them.

I looked at Clean. It isn't.

I also looked at F#. And didn't like it much. Ditto for Erlang. And 
Lisp. And Prolog. (But that was a very long time ago...)

> In fact, C# is the first time in about 10 years now that I'm learning a 
> *new* language, and its only a derivative of the ones I already know.

You're talking to somebody who learned PostScript in their lunch break 
one day. Just for the fun of it. BECAUSE I WAS BORED!!

Holy crap, I need a different job! o_O

> Getting people to invest time into something like learning a new 
> language is difficult, at least, and close to impossible, in many 
> situations.  Just keep plugging, and don't lose hope :)

Woah... and here I am trying to get people to learn something that's so 
fundamentally weird it freaks Pixar employees out... o_O

Post a reply to this message

andrel a écrit :
> Orchid XP v8 wrote:
>>>> I'm pretty sure that Andy is perfectly able to write a decent report. 
>>>
>>> He said he isn't. So who am I going to believe.
>>
>> I'm good at writing short, unstructured things. When trying to explain 
>> big concepts, I have trouble figuring out where to start and what 
>> order to say things in. 
> 
> My way of looking at a text or presentation: Look at it as if it is a 
> program. The conclusions are the main routine. The lines in the 
> conclusions call various subroutines (aka the previous sections and 
> slides) that can in turn call other subroutines (paragraphs). You should 
> therefore be able to draw a flowchart of the concepts in your text. A 
> text is good if 1) no external subroutines are called (i.e. everything 
> is defined within the text or common knowledge to the audience) 2) there 
> are no dead branches. 3) all subroutines are define before use or 
> explicitly declared as something to fill in later.
> When I said that a programmer should be able to write a decent report 
> (or give a good presentation for that matter) because the skills 
> required are the same, the above is what I meant.

I wonder how the (very good, by the way) analogy applies to the 
functional programing so dear to Andrew :-)

If he starts writing reports that resemble Haskell programs, there will 
be recursive sections all over the place :-D

-- 
Vincent

Post a reply to this message