>> Yay! I suck. :-}
> 
> I'm assuming you're just being silly.

Yeah, pretty much.

> I'm giving you an example of what 
> an editor would do for you. It's criticism along the lines that "this is 
> so well written it's worth my time helping you polish it so it doesn't 
> have any of the tiny flaws that stick out like splinters on an 
> impressively artistic wood carving."  If the paper wasn't already 
> excellent, I wouldn't be bothering to point out where you spelled a word 
> wrong.

Yeah, I got that part. ;-)

> When you're done, put it up somewhere and put the URL in your resume. 
> This is the sort of stuff you should be putting in your resume. You do 
> it very well, and as you say some of your actual paid work doesn't sound 
> very impressive on a resume and you can't point a URL at the impressive 
> paid work you do.

That's the plan, yes. It's part of the "portfolio" of (debatably) 
well-written documents I'm building. (You might remember the one a while 
ago on sorting/searching? I still have that.)

> The abstract should say "this is what I'll talk about and why you should 
> bother to buy/download/read the rest of the paper."  The conclusion 
> should say "this is what I covered and I expected you to get, and if you 
> didn't, you should read more carefully.

With most of the stuff I write, it's hard to think of a justification 
for anybody bothering to waste their time reading what I wrote. But the 
conclusion makes sense. ;-)

> Abstract:
> This paper describes a programming technique which is common in 
> functional languages like Haskell but not widely used in imperative and 
> object-oriented languages: the construction of combinator libraries. 
> This powerful technique is introduced by way of the concrete example of 
> a parser for text. Such parsers are common in all programming languages, 
> so the contrast between the mechanisms used in functional paradigms with 
> other paradigms will be easily recognized by programmers unused to 
> functional concepts. Targeting readers for whom combinator libraries are 
> a new concept, simple common syntax is used in the examples, leaving the 
> introduction of Haskell's syntax to the end. No knowledge of Haskell or 
> functional programming is required.

...damn, you're good. o_O

> Conclusion:
> This paper has introduced the reader to the concept from functional 
> programming called a combinator, as well as given an example of how 
> combinators can be collected into libraries to create sophisticated 
> tools from a collection of simple operations. A combinator library for 
> parsing strings is developed and explained. The result has a uniquely 
> functional flavor that is unlike the solutions other paradigms would 
> employ.

You've done this before. :-P

Hmm... clearly I'm going to have to devote some serious attention to my 
existing two documents. ;-)

Post a reply to this message