 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 01 Feb 2011 11:56:57 -0800, Darren New wrote:
> Jim Henderson wrote:
>> That's actually a really good strategy for learning, as well - if you
>> have to explain what you learned to someone, that helps focus your
>> attention on what you're learning.
>
> That's why I like arguing with Warp. He's smart and technical enough to
> make me have to think up really good arguments to support my gut
> feelings. :-)
LOL, same here for me when I'm discussing something with Patrick.
>> The trick is not to identify "Haskell" as the subject you're writing
>> about, but to break it down into smaller pieces. Then break those
>> smaller pieces down, and so on.
>
> And another part of the trick is that the broken down sections might not
> have the same cleaves as you would expect. You might have to break down
> lazy evaluation into three or four different parts before you can find
> an order to present them in, because it gives you an opportunity to
> explain something else between part two and part three that part three
> relies on.
Yes, absolutely. The class I developed and taught when I first started
at Novell is actually somewhat like that - it was an advanced class that
there were some circular bits of knowledge, so you have to start with
what's more foundational and explain the things it depends on in clear
enough terms, but not in great detail, because that'll come later after
the foundation is built.
Very often, students would ask questions about that foundational
knowledge, and I'd have to tell them "we'll get to that later in the
class, and it'll all make sense then" - and of course, I'd have to make
sure it did, then. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Oh, the *library* doesn't contain any technical books. Trying to find
>> anything there beyond GCSE level is a waste of time. You couldn't even
>> find a book on integral calculus, much less something advanced like
>> digital filter design.
>
> It isn't always about the content the library has on hand so much as
> getting to know the librarians. I don't know if in the UK libraries
> borrow from each other (but I suspect they do), so sometimes the material
> you are looking for is available to them even if it's not on-site.
Well, they *do* move books from library to library on request. But I've
looked at the library's catalogue, and there's almost nothing
interesting in it.
(I especially love the 1960s-era dumb terminal connected to a
telex-style user interface that they use for allowing you to access the
catalogue. Nice to know they're up with modern times...)
> But if you get to know the staff at the library, they're often full of
> useful information.
From what I've seen, they're over-worked, under-paid, and very unmotivated.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/02/2011 07:42 PM, Darren New wrote:
> Invisible wrote:
>> Oh, the *library* doesn't contain any technical books.
>
> You don't live near a university?
Not unless you count the OU, no.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Let's face it, usually the reason I write something is that somebody
>> else has written it, badly, and I want to do better.
>
> That's not a bad reason to do something like this. It often helps one
> understand something if one has to learn it well enough to teach it - and
> when you write something, you're teaching.
>
> That's actually a really good strategy for learning, as well - if you
> have to explain what you learned to someone, that helps focus your
> attention on what you're learning.
Well, that's true enough. I quite often walk around the place telling my
imaginary friend about the finer points of logic design, or chaos
theory, or data compression algorithms. Quite often you discover a new
way of looking at something just be *pretending* to explain it to somebody.
I like to pretend that this is the reason that I do this. Obviously, the
real reason is that until very recently, I was a sad pathetic loser with
no *real* humans to talk to...
> The trick is not to identify "Haskell" as the subject you're writing
> about, but to break it down into smaller pieces. Then break those
> smaller pieces down, and so on.
>
> Then you get to something manageable.
>
> After that, then build a structure.
Chopping the subject up into pieces is not difficult. It's stringing
them into a logical structure that's difficult. I think I do this quite
well for smaller documents. For large documents, it ends up all going wrong.
> When I worked on the books I co-authored, that's what we did; Peter (my
> co-author) and I sat down together (or sent lots of e-mails, since we did
> a couple books together and he's in Toronto and I'm not) and worked out
> an outline for our troubleshooting book.
>
> We started with what topics we needed to cover, then organized them.
>
> Then pitched the idea to a couple publishers, and one came back and said
> they'd like to publish it. We asked for feedback on the proposed outline
> (since they know the technical book market), and they liked it, so then
> we split the sections up and wrote them.
>
> Not necessarily in order (but mostly so), but we wrote them. Made sure
> we knew which of us was writing what and what each of us was writing (so
> we could refer to it if necessary), and the publisher's editorial staff
> and technical review staff helped ensure the consistency of style,
> format, and information.
I should imagine having professional people review your work helps a
lot. I did write a short piece for Internet "publication", and the
editor's comments were helpful. (Not that I suppose he's a professional
editor; this is only a small hobby publication, after all...)
>> Didn't Mozart write Twinkle Twinkle Little Star at the age of 6?
>
> Yes, but that doesn't really matter. My point is that you don't start
> out with something complex, you start out with something simple and work
> up to complex.
Fair enough. Although, like I say, I've written plenty of smaller
documents, and they've worked out well. It's large documents that end up
not working.
> When I learned to play the violin, Twinkle Twinkle Little
> Star was one of the first actual pieces of music I learned to play. So
> was Three Blind Mice. I didn't tackle things like Lalo's Symphonie
> Espagnole, Bach's Sonatas& Partidas (only some of which I tried to learn
> on my own), or Howard Hanson's 2nd Symphony (which I actually did get to
> perform in concert in the USSR with the youth orchestra I was in) until
> I'd mastered simpler stuff.
I think Ode to Joy was about the summit of my violin skills. Actually,
one of the girls at work got given a violin for her birthday (she has no
idea why), and I was still able to play this. (She brought the violin in
to work because she couldn't actually get a note out of it. I managed to
just about fix that too.)
>> When searching with Google, I never know whether I'm just using the
>> wrong search term, or whether the document I'm searching for actually
>> doesn't exist. I rather suspect it's almost always the latter. (Except
>> that every now and then, Darren will pop up and write an almost
>> identical search term and it comes back with useful data...)
>
> The thing is to try different search terms - work out synonyms - a good
> thesaurus can be helpful for that. Also I find that with Google, the
> fewer words used, the better, unless you're looking for a quote (in which
> case, put part of the quote in quotation marks).
>
> But if you search and come up with nothing and Darren writes an "almost
> identical search term" and comes up with useful data, compare your search
> to Darren's. Don't say "they're almost the same", but note the
> differences.
I guess mainly it just comes down to extreme pessimism about whether
there's any useful documents to be found in the first place. (E.g., what
are the chances of somebody having written a document about wavelets
that isn't either a vague summary that tells you nothing, or a dense
technical report which is incomprehensible?)
>>> So I guess the other part is learning how to break a complex topic down
>>> into manageable pieces.
>>
>> Oh, I think I've got that down. It's putting the pieces back together
>> into a coherent whole that I don't do well.
>
> Then that's something that you can work on - that's also a learnable
> skill. But to do so, it will help those trying to help you to share not
> only the final product, but some of the process used along the way.
> Since that process is what needs refinement, it needs to be examined.
> Again, offer's on the table.
OK, fair enough...
>> Each individual concept isn't too difficult to explain. Trying to figure
>> out the best order in which to explain all of them is maddeningly
>> difficult.
>
> So let's use that as an exercise and see what we come up with. :-)
Heh, OK.
Perhaps not this week though, as (inexplicably) I actually have some
work to do. Yeah, I know, imagine that...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/02/2011 07:56 PM, Darren New wrote:
> That's why I like arguing with Warp. He's smart and technical enough to
> make me have to think up really good arguments to support my gut
> feelings. :-)
And here I was thinking you just like pissing people off. ;-)
>> Again, offer's on the table.
>
> Same here.
Really? Interesting...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/02/2011 9:02 PM, Jim Henderson wrote:
>> Not unless he lives in Edinburgh. O_O
> It's funny you should say that, because he actually does.;-)
>
Unlike some people I could mention. I often remember what I read.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> On 01/02/2011 07:56 PM, Darren New wrote:
>
>> That's why I like arguing with Warp. He's smart and technical enough to
>> make me have to think up really good arguments to support my gut
>> feelings. :-)
>
> And here I was thinking you just like pissing people off. ;-)
I like discussing technical details of design decisions and their
implication. I can't help it that Wrp takes comments about C personally.
Quite honestly, it boggles my mind that anyone would get upset at someone
else talking about the problems with design choices in a language designed
almost before they were born. It's not like I'm criticizing *his* choices.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> way of looking at something just be *pretending* to explain it to somebody.
You *are* actually explaining it to someone else. That model in your head
really isn't any less "real" than the model you have in your head of me.
Just like thinking about throwing a basketball helps you actually practice
real basketball throwing.
> Chopping the subject up into pieces is not difficult. It's stringing
> them into a logical structure that's difficult. I think I do this quite
> well for smaller documents. For large documents, it ends up all going
> wrong.
It's practice. Exactly the same with computer programs. The little one you
can fit all in your head at once. The big one you have to do differently.
> Fair enough. Although, like I say, I've written plenty of smaller
> documents, and they've worked out well. It's large documents that end up
> not working.
Practice practice. It also helps to practice speed on the small documents.
Give yourself 15 minutes to write a 2-page document on a topic you never
thought about before. (OK, start with 30 minutes, and cut off five minutes
each day.) Then you start getting some of the same cognitive load as a
larger paper imposes.
> I guess mainly it just comes down to extreme pessimism about whether
> there's any useful documents to be found in the first place. (E.g., what
> are the chances of somebody having written a document about wavelets
> that isn't either a vague summary that tells you nothing, or a dense
> technical report which is incomprehensible?)
Hey, you've got a topic to write about! Two, even!
Your first assignment: Speculate on why there are few intermediate documents
of the type you talk about, and analyze what that implies for learning in
this day of ongoing adult self-education. I want to see your outline
tomorrow, and a two-page explanation by the end of the weekend. :-)
> Perhaps not this week though, as (inexplicably) I actually have some
> work to do. Yeah, I know, imagine that...
When you get home is fine. It's f'ing homework - what do you expect?
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Feb 2011 15:53:54 +0000, Stephen wrote:
> On 01/02/2011 9:02 PM, Jim Henderson wrote:
>>> Not unless he lives in Edinburgh. O_O
>> It's funny you should say that, because he actually does.;-)
>>
>>
> Unlike some people I could mention. I often remember what I read.
LOL
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Feb 2011 10:00:04 +0000, Invisible wrote:
>> That's actually a really good strategy for learning, as well - if you
>> have to explain what you learned to someone, that helps focus your
>> attention on what you're learning.
>
> Well, that's true enough. I quite often walk around the place telling my
> imaginary friend about the finer points of logic design, or chaos
> theory, or data compression algorithms. Quite often you discover a new
> way of looking at something just be *pretending* to explain it to
> somebody.
When I was working in IT on a daily basis, I would call my wife and try
to explain a problem I was seeing to her - not that she could help with
technical advice, but because if I framed it so she could understand it,
the answer would frequently appear before me.
> I like to pretend that this is the reason that I do this. Obviously, the
> real reason is that until very recently, I was a sad pathetic loser with
> no *real* humans to talk to...
Well, I know plenty of people who do just that when they're preparing for
a presentation as well. I know several instructors who practice in front
of a mirror, too.
>> The trick is not to identify "Haskell" as the subject you're writing
>> about, but to break it down into smaller pieces. Then break those
>> smaller pieces down, and so on.
>>
>> Then you get to something manageable.
>>
>> After that, then build a structure.
>
> Chopping the subject up into pieces is not difficult. It's stringing
> them into a logical structure that's difficult. I think I do this quite
> well for smaller documents. For large documents, it ends up all going
> wrong.
Large documents are just a collection of small documents. So start by
doing the "chopping up" and then we'll talk about how to structure it.
>> When I worked on the books I co-authored, that's what we did; Peter (my
>> co-author) and I sat down together (or sent lots of e-mails, since we
>> did a couple books together and he's in Toronto and I'm not) and worked
>> out an outline for our troubleshooting book.
[...]
>
> I should imagine having professional people review your work helps a
> lot. I did write a short piece for Internet "publication", and the
> editor's comments were helpful. (Not that I suppose he's a professional
> editor; this is only a small hobby publication, after all...)
Having competent people helps a lot. I worked with some editors who
weren't very good, and I worked with some who were. On the language
review edits, though, I rejected about 90% of the suggestions because it
changed the meaning of what I was trying to say.
>>> Didn't Mozart write Twinkle Twinkle Little Star at the age of 6?
>>
>> Yes, but that doesn't really matter. My point is that you don't start
>> out with something complex, you start out with something simple and
>> work up to complex.
>
> Fair enough. Although, like I say, I've written plenty of smaller
> documents, and they've worked out well. It's large documents that end up
> not working.
So it's time to move from small documents to slightly larger documents,
rather than to a 300 page book. So, how do you define a "smaller
document"?
>> When I learned to play the violin, Twinkle Twinkle Little Star was one
>> of the first actual pieces of music I learned to play. So was Three
>> Blind Mice. I didn't tackle things like Lalo's Symphonie Espagnole,
>> Bach's Sonatas& Partidas (only some of which I tried to learn on my
>> own), or Howard Hanson's 2nd Symphony (which I actually did get to
>> perform in concert in the USSR with the youth orchestra I was in) until
>> I'd mastered simpler stuff.
>
> I think Ode to Joy was about the summit of my violin skills. Actually,
> one of the girls at work got given a violin for her birthday (she has no
> idea why), and I was still able to play this. (She brought the violin in
> to work because she couldn't actually get a note out of it. I managed to
> just about fix that too.)
Well, that's included in the 9th Symphony (as I'm sure you know). :)
>> But if you search and come up with nothing and Darren writes an "almost
>> identical search term" and comes up with useful data, compare your
>> search to Darren's. Don't say "they're almost the same", but note the
>> differences.
>
> I guess mainly it just comes down to extreme pessimism about whether
> there's any useful documents to be found in the first place. (E.g., what
> are the chances of somebody having written a document about wavelets
> that isn't either a vague summary that tells you nothing, or a dense
> technical report which is incomprehensible?)
Then you need to address that as well - instead of starting out with
despair and the expectation that there's nothing available on the topic
(after all, if there were nothing useful available on the topic, then
nobody would get involved in whatever field it is, but as people are
involved, they must've learned from somewhere, right?), start out with no
feeling one way or the other.
In other words, don't go from "nothing exists so why bother" to "of
course it exists if I just search hard enough", but rather "I'm looking
for something on 'x', and if I can't find it, someone can perhaps help me
find it."
>>> Each individual concept isn't too difficult to explain. Trying to
>>> figure out the best order in which to explain all of them is
>>> maddeningly difficult.
>>
>> So let's use that as an exercise and see what we come up with. :-)
>
> Heh, OK.
>
> Perhaps not this week though, as (inexplicably) I actually have some
> work to do. Yeah, I know, imagine that...
I know the feeling, I do as well, but I'm willing to make some time to
help you with this. You've got the basic skills, you just need some
practice and some guidance.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
