Orchid XP v8 wrote:
> Yay! I suck. :-}

I'm assuming you're just being silly. 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.

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.

>> Add a concluding section, and explain in the abstract why someone 
>> might want to read the paper. These are two parts of any paper that 
>> are difficult to get right.
> 
> You're telling me...!

Let me give an example of an abstract and conclusion *I* would write for 
your paper, just to offer a perspective.

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.

Again, take this as constructive suggestions from someone who spent years 
learning to write this sort of paper, submitting them to panels of editors, 
and getting rejected. ;-)

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.


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.




-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message