 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] pacificwebguy com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
