A very good editor, at any rate. Thanks, Jasper!
Jasper, thanks for all of your work on Wiki.
Thanks for the refactoring, nice job. -- DougMerritt
JustaProgrammer, but with experience as a mechanical engineer and as a manufacturing engineer.
Current Employer: Puget Sound Energy (http://www.pse.com)
Email: mailto:jasper@folds.net
Topics I'm involved with or interested in:
Good StartingPoints for using wiki:
JP, why do you amend certain spellings to American English even though the original author is not American? Shouldn't we let British authors use British English spelling?
I make these changes for consistency. The C2 Wiki is an American web site, and its standard is to use American spellings. (For example, the spelling checker uses American spellings.) I generally change text written in the voice of wiki (that is, anonymous). I try not to make these changes in signed contributions from Britons, Canadians, Australians, et cetera.
On documents that are consistently in British English spelling, I do not make these changes -- indeed, I choose to use the British English spelling myself. For example, I edited Marcel Tolkowsky's Diamond Design. (http://www.folds.net/diamond). Diamond Design was published in London and New York. Tolkowsky chose to use British English. I consistently kept his British English spelling in the main body of the work, and used British English spelling in all of my editor's notes. Whereas, in my follow up article on diamond girdles, I consistently used American English spelling.
I do not make these changes on wikis that are hosted in Britain, Canada, Australia, et cetera. I assume that the standard on such web sites is to use British English spelling.
You can think of the spelling checker as a kind of Unit Test.
You said: "Because this wiki does not support hyperlinks within a page, it is far easier to cross-link text on multiple pages. This reduces duplication, makes it easier to check whether an idea has already been discussed, and makes it easier to add useful contributions. -- JasperPaulsen"
I'm withdrawing my opposition, but that's in spite of your argument, not because of it. I disagree with your logic; that leads to the notion that all non-trivial pages should be split into many pages. Obviously pages are rarely split simply to allow cross-links, so your argument begs the question: why the Tql pages in particular? -- DougMerritt
I would like to see the TQL pages developed further. They represent either a promising alternative to SQL, or an example of how difficult it is to replace a flawed standard. Either way, the TQL pages have two benefits:
Each of the TQL pages is a logical chunk of the material, with enough document-mode content to spend a few minutes reading and thinking about, and a convenient place for people to suggest new ideas to the topic's de facto moderator (Top), and receive his replies. When the TQL pages were in a single page, it was very difficult to suggest new ideas or examples. Partly, the page got to be too long; but also, it was hard to show how the new idea was different from related material already on the page. -- JasperPaulsen
Hmm. Ok, I'll digest (ponder) that. Thanks for your reply. P.S. Re: "promising alternative to SQL" -- is there a comparison to QUEL, TutorialDee, and the RelationalCalculus in there somewhere that I should look at? If the answer is "no", I submit that there should be, since those are three famous SQL alternatives. -- DougMerritt
You might want to mention these languages on QueryLanguage. On the other hand, most of them are already mentioned on RelationalLanguage. -- JasperPaulsen
After working in other languages for several years, I am starting to write C++ programs again. Here are some patterns that I am finding useful.
Why use C++?
My development environment
.++++ Critical (e.g., crashes or won't compile)
.+++ Makes program unsuitable for public release.
.++
.+ A nice touch, but low priority.
.
-. A slightly questionable idea.
--.
---.
----. A questionable idea that would take a lot of work.
If a .+ item is easy to implement, I will often deal with the LowHangingFruit before tackling a higher priority (but more time-consuming) item. The log has three sections: unsolved items (sorted by priority, then by item number), solved items (sorted by build number in which they were fixed, then by item number), and items I have decided not to fix (sorted by item number). As the project progresses, I can see a trend of the items being solved tending to have lower priorities.