Vincent Le Chevalier wrote:

> 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

If it was Haskell, you could define constructs in arbitrary order and it 
would still work! ;-)

Actually, hell, see my logic programming source code post. It's valid, 
parsable, runnably Haskell source code...

Post a reply to this message

Orchid XP v8 wrote:
>>> 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.
> 
> My God... this is genius. Genius, I say! 0_0

Oh come on, pull the other one.

> I have never, ever thought about writing stuff that way... 

I am not really surprised :( IMHO it should have been a recurring theme 
in your CS education. The fact that it wasn't confirms any prejudice 
that they still mainly teach technical subjects but fail to teach what 
*programming* is about.

> Damn, so *this* is what being intelligent must feel like? 

I think it has more to do with finding the right metaphor for a specific 
  person than with intelligence. But if it helps you to look at texts in 
a new way and helps you to write even*) better structured texts I will 
be a very happy man indeed.

> Heh. I gotta try writing something now...
Yes, do so.


*) 'even', because you knew it instinctively at a certain level and were 
writing good stuff already **)

**) footnote aka an inline function.

Post a reply to this message

>> My God... this is genius. Genius, I say! 0_0
> 
> Oh come on, pull the other one.

Who said ideas have to be complex to be revolutionary? E = mc^2

> I am not really surprised :( IMHO it should have been a recurring theme 
> in your CS education. The fact that it wasn't confirms any prejudice 
> that they still mainly teach technical subjects but fail to teach what 
> *programming* is about.

Oh, sure, he had lessons about how to write reports. It just didn't make 
a lot of sense to me. (Why would you tell somebody something thrice? 
That makes no sense.) Well OK, some of it made sense. (Like, write it 
for the correct target audience.)

I guess the problem fundamentally boils down to me being a very messy 
thinker who's easily distracted.

>> Damn, so *this* is what being intelligent must feel like? 
> 
> I think it has more to do with finding the right metaphor for a specific 
> person than with intelligence.

I meant, being *able* to think up the correct metaphore is really 
intelligent. Reports are like code. It seems so *obvious* in retrospect...

>> Heh. I gotta try writing something now...
> Yes, do so.

Wait - how do I make people read it?

Oh yeah - don't write about Haskell. That'll do it... :-/

> *) 'even', because you knew it instinctively at a certain level and were 
> writing good stuff already **)
> 
> **) footnote aka an inline function.

Surely that's an out-of-line function? :-.

Post a reply to this message

Orchid XP v8 wrote:
>>> My God... this is genius. Genius, I say! 0_0
>>
>> Oh come on, pull the other one.
> 
> Who said ideas have to be complex to be revolutionary? E = mc^2
> 
>> I am not really surprised :( IMHO it should have been a recurring 
>> theme in your CS education. The fact that it wasn't confirms any 
>> prejudice that they still mainly teach technical subjects but fail to 
>> teach what *programming* is about.
> 
> Oh, sure, he had lessons about how to write reports. It just didn't make 
> a lot of sense to me. (Why would you tell somebody something thrice? 
That is the second time you mention that. I don't think I ever did that. 
Besides we are often required to tell about our research within 10 
minutes. Telling the audience once is already difficult enough.
> That makes no sense.) Well OK, some of it made sense. (Like, write it 
> for the correct target audience.)
My guess would be that this teacher couldn't write a decent report 
himself. And boy did he miss all those opportunities to discuss 'divide 
and conquer' in the context of writing reports, and all those strategies 
to start writing something like 'bottom up', 'top down' etc, etc. Not 
even being able to use a flowchart to analyse why a report was good or 
not. Pity.

Post a reply to this message

Orchid XP v8 wrote:
> I find I tend to sit down, start writing, generate loads of ideas, run 
> off at tangents, and end up with a bunch of stuff that makes sense, but 
> misses out lots of interesting details that I couldn't fit into the flow 
> of the text.

Generally, you should cut about 2/3 of your first draft, no matter how 
good it is.  Whatever fluff you come up with on the first write, you 
have better stuff inside your head waiting for the second draft.

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

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> 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.

  OTOH, starting too low can lead to what I call the C-hacker syndrome.
(It doesn't have to necessarily be a C coder per se, but the vast majority
of these people are.)

  The "C-hacker" wants to control every single clock cycle his code
requires. He only sees low-level inefficiencies everywhere (and will
often completely overlook the big picture, ie. the *real* bottlenecks).
Often they will fill their code with obfuscated "cool tricks" they have
learned from other C-hacker friends and websites.

  The C-hacker will have a very strong prejudice against higher-level
programming paradigms and languages. Especially object-oriented
programming is the most prominent red flag for the C-hacker. He'll ramble
all day long about how OOP sucks big time. None of his arguments will make
the least amount of sense, though (all of the arguments will be irrelevant,
exaggerated, or in the vast majority of cases, just plain false).

  The C-hacker will have a very strong prejudice against any features
and libraries which work like a "black box", ie. doing things inside
that the C-hacker has no control over. He wants everything to be open
and controlled by him. He prefers writing 5000 lines of code to create
his own (often inefficient and unsafe) implementation of something rather
than using an existing library.

  The C-hacker emphasizes the so-called "hacker optimization", even to
the point where it becomes completely counter-productive. His "hacker
optimized" code will usually be an obfuscated and unmaintainable mess
which nobody can read (not even himself after a year). He has the false
notion that low-level programming, "close to the hardware", somehow
automatically makes the code faster. Quite ironically, in many cases his
"hacker optimized" code will actually be quite inefficient because he's
using the wrong algorithms and data containers for the job.

  The worst trait of the C-hacker is his inability to learn proper
programming principles and techniques. He *fights* against them instead
of wanting to learn them. Resistance to change is deeply ingrained.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> 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.
> 
>   OTOH, starting too low can lead to what I call the C-hacker syndrome.

I didn't say it should be the *first* thing they learn :)  I would guess 
that starting out in a higher level language would prepare someone to 
deal with most of the problems you point out.

Although, I'll readily admit a lack of empirical data...

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

Post a reply to this message

Warp wrote:
>   The C-hacker will have a very strong prejudice against higher-level
> programming paradigms and languages. 

I would add "they tend to call things 'bondage and discipline 
languages'", even if they're relatively low level. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Chambers wrote:
> but because knowing how computers 
> *really* work will help them write better programs in the long run.

I taught my boss how semiconductors work last week. Why blue LEDs aren't 
just "red LEDs with a different color". And why TTL takes more current 
than CMOS. :-)  If you don't know why computers work in binary, and you 
can't prove that 2's compliment math works, you still haven't gotten all 
the way to the bottom. :-)

What's all this "assembly language" high-level stuff?  ;-)

I remember coming into the lab at Bellcore, seeing one of the guys 
writing some C code, saying "Oh, getting down to some low-level stuff, 
eh?"  He said "I'm writing a device driver for this joystick I just 
built."  I said "Oh, getting down to some high-level stuff, eh?"

But yah, that's why I thought the article was interesting. It had a 
combination of opinions that wasn't black-and-white.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

andrel wrote:
> Look at it as if it is a program. The conclusions are the main routine.

That's what always killed me about mathematical proofs. They always 
start with all the details, and finally tell you why you care. :-)

I would clarify by saying the document should also *start* with the 
conclusion, because people are going to be trying to recreate the 
structure in their head as they read.

That's what is killing me about reading the Erlang documentation: there 
are all sorts of cross-references, and no obvious place to start 
reading.  I wouldn't be surprised if there are circular references 
throughout, either.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message