![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 01/02/2011 11:49 AM, Invisible wrote:
> 10 years of being told to "sit still and be quiet" later, and walking to
> the shops is somewhat demanding...
Sorry, you lost me.
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 01/02/2011 2:22 AM, Jim Henderson wrote:
> So perhaps instead I should have said "It's an English word and usage,
> defined by what is arguably referred to as the definitive English
> dictionary these days".;-)
And I would say that your usage is definitely American.
No offence, old chap.
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 01 Feb 2011 09:48:48 +0000, Invisible wrote:
>>> I spent quite a long time doing that with digital filter design.
>>> Eventually I gave up due to the sheer intractability of finding
>>> anything remotely useful. (Fortunately, many years later I finally
>>> stumbled upon a very good resource by accident...)
>>
>> The trick is to train yourself to do so intentionally so finding the
>> right resource isn't accidental. Do you have a local library?
>
> 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.
But if you get to know the staff at the library, they're often full of
useful information.
Besides, one really good tactic/technique when preparing a presentation
is to use quotations - librarians (and libraries) tend to be very good at
finding relevant information/quotes.
>>>> You need to learn to do this iteration rather than giving up after
>>>> round 1 so frequently. You did it with your dancing classes, so
>>>> apply that to other areas in your life. :)
>>>
>>> Uh, I went to *one* dance school, and I'm still there. Not a great
>>> analogy. :-P
>>
>> Actually, it's an excellent analogy, because you determined:
>>
>> 1. You wanted to learn to dance
>> 2. You identified someplace that could help you do so 3. You
>> identified the class(es) that you were most interested in 4. You went
>> to class and learned
>> 5. YOU KEPT AT IT
>> 6. You are continuing to refine your skills by still going to class
>>
>> It's a perfect example of the iterative process of learning, because
>> you've gone through many iterations.
>
> I asked my sister which school I should go to and what class to take.
> After that, I kept going because I was addicted. There wasn't a whole
> lot of effort involved. (Other than the effort of remaining upright.
> Have *you* tried dancing the Waltz? It's way harder than you'd think...)
That's exactly my point - in my list of steps above, step 2 was you
asking your sister for advice on where to learn more.
Finding the right resource here wasn't an accident - it was purposeful,
because you asked someone who knew how to help you move forward.
You need to apply the same strategy to other things you're researching.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 01 Feb 2011 11:58:44 +0000, Stephen wrote:
> On 01/02/2011 2:22 AM, Jim Henderson wrote:
>> So perhaps instead I should have said "It's an English word and usage,
>> defined by what is arguably referred to as the definitive English
>> dictionary these days".;-)
>
> And I would say that your usage is definitely American. No offence, old
> chap.
Oh, I don't think so, but no offense taken, of course. ;-)
Actually, I've thought of two folks in Britain I could ask for
confirmation - and one's a Scot, so you wouldn't be able to get out of
that one. ;-)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 01 Feb 2011 09:57:20 +0000, Invisible wrote:
>>> Perhaps I'm just too much of a perfectionist then.
>>
>> That is common for people in technical fields - so you're not alone.
>
> Let's face it, usually the reason I write something is that somebody
> else has written it, badly, and I want to do better. (Anyone here read
> Real World Haskell? For such a hyped book, written by well-known experts
> of the field... it's not actually that good!)
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.
>> That's a start. Problem is that nobody really teaches how to use them
>> effectively, certainly not in the US schools. I would've done much
>> better in school if I'd been taught how to use that as a way of taking
>> effective notes, for example.
>
> Or maybe it's just that "Haskell" is a really *huge* subject...
I've done presentations on troubleshooting and on giving remote lab-based
exams (ie, computer-based practical exams). Those topics are quite large
as well, yet I've managed to present on them multiple times.
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. Determine your audience's knowledge
level (or identify it, depending on the situation - some cases you choose
the audience, and some times the audience chooses you) and identify
prerequisites they need to know. That gives you structure.
Then write the sections.
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.
>>> OK. Well maybe I'll try again with something slightly less insane...
>>
>> That's the way to do it, start with something simple, and work up to
>> the larger projects. You wouldn't try to play Beethoven's 9th Symphony
>> on the violin without first working through Twinkle Twinkle Little
>> Star, so don't try to do a symphony your first time out writing.
>
> 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. 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 still remember the "research training" we did at university. This
>>> consisted of knowing where the library keep the various documents they
>>> hold. No indication of how you figure out what documents exist or
>>> which ones might be useful or...
>>
>> That sounds about as useful as a class my stepson has just audited -
>> he's in his 4th year (of 4) at Uni here, and one course he hadn't taken
>> because his schedule didn't fit it was "how to use the library" (I'm
>> not kidding about this).
>
> Well, that's really all that our research training was. It's not about
> how to research, it's about how to use the library. It was even given by
> one of the library staff. No indication of what is *in* these documents
> or anything, just "they're on shelf 5B".
Well, yes, and I'd agree that that's not really research education, it's
"how to use a library", which is something different. So you need to
learn how to do actual research.
>> For me, though, it comes down to the word association game
>
> 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.
>> So I guess the other part is learning how to break a complex topic down
>> into manageable pieces. That's also a learnable skill, and not
>> something that anyone innately knows how to do.
>
> 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.
> Ask me "how does pattern matching work in Haskell?" and I can write
> about that. Ask me "how do you optimise performance?" and I can write
> about that too. Ask me "how does type unification work?" and I can do
> that too. Ask me "how do I write a program in Haskell?" and I go into a
> redraft spiral from which there is no escape...
That's because writing a program requires a lot more than one of those
individual topics (which you already know).
So, let's start with that question:
"How do I write a program in Haskell?"
Start by breaking it down - what are the things one needs to know to
write a program in Haskell? Just list them in no particular order.
Assume the person who's asked the question knows nothing about Haskell
(as I know nearly nothing about it, consider me the target audience).
> 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. :-)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Oh, the *library* doesn't contain any technical books.
You don't live near a university?
> Have *you* tried dancing the Waltz? It's way harder than you'd think...)
Yes it is.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Or maybe it's just that "Haskell" is a really *huge* subject...
You know the other thing you're probably doing? You're probably trying to
present everything about a particular part of the information before moving
on. You're (say) trying to describe all about laziness before delving into
I/O, or vice versa, when they're really completely interrelated.
Ask yourself "how would the person who designed this system have figured
this out?" Then tell the story.
In other words, you can start out saying "laziness lets you talk about what
will be evaluated in the future without evaluating it yet." Then you skip
all the details beyond that, describe I/O as if that description of laziness
is enough to understand the I/O, then go in and say "Given that I/O works
that way, what features do we need laziness to have?" And then you discuss
the rest of lazy evaluation. Something like that.
Next time you go to a movie or something, watch how they at the beginning
make references to things that happen near the end.
So your outline for things with circular references has to have at the start
enough about the stuff at the end that you can understand the stuff in the
middle without understanding all the stuff at the start.
> 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...)
You have to remember that google indexes mostly answers, not questions. On
the other hand, the magic of google is that it also indexes to a large
extent the questions (because it takes into account the text on pages
containing links to the results it gives - see "googlebombing").
> 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.
You have to break it down.
> 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.
Lies to children. Explain each bit only enough to understand the *next* bit,
not the bit you're explaining now.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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. :-)
> 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.
> Again, offer's on the table.
Same here.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 01/02/2011 5:26 PM, Jim Henderson wrote:
> On Tue, 01 Feb 2011 11:58:44 +0000, Stephen wrote:
>
>> On 01/02/2011 2:22 AM, Jim Henderson wrote:
>>> So perhaps instead I should have said "It's an English word and usage,
>>> defined by what is arguably referred to as the definitive English
>>> dictionary these days".;-)
>>
>> And I would say that your usage is definitely American. No offence, old
>> chap.
>
> Oh, I don't think so, but no offense taken, of course. ;-)
>
That is your right but please don’t visit with your B52’s ;-)
> Actually, I've thought of two folks in Britain I could ask for
> confirmation - and one's a Scot, so you wouldn't be able to get out of
> that one. ;-)
>
Not unless he lives in Edinburgh. O_O
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 01 Feb 2011 19:57:52 +0000, Stephen wrote:
> On 01/02/2011 5:26 PM, Jim Henderson wrote:
>> On Tue, 01 Feb 2011 11:58:44 +0000, Stephen wrote:
>>
>>> On 01/02/2011 2:22 AM, Jim Henderson wrote:
>>>> So perhaps instead I should have said "It's an English word and
>>>> usage, defined by what is arguably referred to as the definitive
>>>> English dictionary these days".;-)
>>>
>>> And I would say that your usage is definitely American. No offence,
>>> old chap.
>>
>> Oh, I don't think so, but no offense taken, of course. ;-)
>>
>>
> That is your right but please don’t visit with your B52’s ;-)
Now they really couldn't sing either. ;-)
>> Actually, I've thought of two folks in Britain I could ask for
>> confirmation - and one's a Scot, so you wouldn't be able to get out of
>> that one. ;-)
>>
> Not unless he lives in Edinburgh. O_O
It's funny you should say that, because he actually does. ;-)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |