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