I had missed this somehow, so in case I'm not alone: There is a new edition of "Programming Forth" (July 2016) by Stephen Pelc out: https://www.amazon.de/Programming-Forth ... 01JIWVB5S/ (Amazon Germany). It seems to be Kindle-only as far as I can tell, price is less than five euros. The second author listed is Jürgen Pintaske (https://www.forth-ev.de/article.php/20160829052423193), who has been busy reincarnating old books in digital form.

So far, I've just been able to skim the book. There is a longish section on embedded systems (including Harvard machines), and in contrast to the old books, we have sections on file I/O, multitasking, and Forth chips. CATCH and THROW are discussed, as are vocabularies and wordlists. There are some higher-level, philosophical discussions included, such as the value of factoring, but this is not intended to be a second version of "Thinking Forth". Most of all, it is based on ANS Forth.

Oh, and how can you really tell this is a modern Forth book? Berlin public transport will probably give me a chance to read more later.

I checked and it is also available in the US Kindle store as well.

I totally, totally disagree (although I suppose it would be like arguing over what favorite color is best). In prose, the lines on the page exist because a book is more manageable than a mile-long ribbon with a lump here and there for pictures. In programming however, the separation into lines becomes very significant for visual factoring, and having ascenders and descenders (as lower-case does) blurs those divisions. Similarly, numerals 0-9 are always "capitals." Do not mix lower-case a-f into them in hEx nUmBErS! Write for example $3EA9, not $3ea9. Here on the forum where the non-code sections are in proportional spacing, when someone writes for example 3fff, in whatever font is used here, it initially looks like 3111 to me because the f's are so narrow. It's no harder to type capitals with the caps lock on. (I do take it off for comments.) If you feel like the computer is yelling at you, then turn the font size down. Easy enough.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

But.. I always disable caps lock first thing on any computer I work on.. it's just too easy to accidentally hit it. So I reprogram it to shift.

I find Caps Lock works great as a Compose key, as I never use it otherwise.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

What is interesting is that Chromebooks do away with caps lock and have the search key there instead. Turns out that I have never missed the caps lock, but have also never used it as a search key either (I do most quick searching via voice commands, aka "Okay Google", via my phone anyway these days). Chromebooks also have lower case keys on their keyboard, which looks weird at first.

If anything, keyboards need a larger ESC key, as any vim user will tell you .

I'm going to agree on uppercase for NUMBERS, but for code-text, I'm just not so sure.

The first problem, for me, is outright practicality.

Like others, I disabled my CAPS LOCK key long ago. It's the CTRL key on my keyboard (and no, I didn't swap it, all of my CTRL keys are CTRL keys, sometimes one is just not enough, especially when you have a drink in one hand, and a cat in another). Mind, this leads to interesting times when using other folks keyboards…c'est la vie.

The problem with CAPS LOCK though, is that it's just a hard MODE. You're IN CAPS or you're not. And having to move in and out of that, not per se within your Forth work, but just interacting with everything else. Your command line, the internet, your documents. At least for me, I'm going to be in the wrong mode, somewhere, all the time, and having to switch back and forth (heh), just kind of yucky. As a whole, we live in a lowercase world.

Secondly, though, I had a recent experience doing some code that had an unexpected benefit.

I do a lot (LOT) of Java, where everything is camelCase, and then you have all of the other shifty keys for the symbols and what not. So, in Java, you're shifting a lot. You're not conscious of it, but you are.

But recently, I coded up a bunch of Common Lisp.

Now, CL is case sensitive, and basically all done in UPPERCASE, but accepts lowercase text -- it simply upshifts symbols it during parsing. There's all sorts of options for this, you can make it case sensitive, but out of the box, it's uppercase, and most folks leave it that way.

Consider:

It's not a straight conversion, it's contextual. The |..| are escape characters for the reader to turn off the conversion.

In Java, as I said, everything is camelCase. In C, historically, you use underscore_separators for identifiers. In CL, they use dash, so long-function-name.

What I found was how comfortable it was to code in Common Lisp. The elimination of the shift key from the bulk of the code was really relaxing.

Yes, you need the shift key for the (), but those these to come in groups (setf int-var (+ other-var (thing-value my-thing))) vs intVar = otherVar + myThing.getValue(). The first is 5 shift events, the latter is 7. Also, with the (), the shift key (done with my left hand) is not shared with the typing of the (), so no contortions, or stretching, etc. Old school Lispers map the () down to not use shift, there were dedicated keys on the original Lisp Machines.

Anyway, In the end, all of those shifts add up.

Now, CL has a lot of indentation, more so than idiomatic Forth. I can see your point about CAPS for code in Forth, but then I look at other code in CAPS, whether its CL, or looking at old UCSD Pascal.

(No, I can't explain the last IF statement with the empty THEN…, yes this is actual UCSD code...)

Frankly, that looks more impenetrable to me than

My eyes get lost in the CAPITALS, it's just a big run on of letters. It's not SHOUTING, it's just all run together. I can barely see the ( after BLOCKREAD.

This, I find a bit more accessible (but I do a lot of Java, again, so…)

But you have the camel case to catch the eye, and break things up. Even with just lowercase, the ascenders and descender break the text up -- make it more manageable (for me)

or:

But, those are all shifted. It costs more than you think.

But this:

is similar, but it's far easier to type. It's surprising, it's only one less shift event. But, it is more comfortable. For me. And it also looks a bit better to my eye, because the dashes lighten it up, while still having a presence. The underscores actually get washed out and sometimes it's hard to tell if there's a '_' or just a ' ', depends on the what surrounds it.

Finally, there's:

That's as bad as the original Pascal, I think.

Anyway, it was just surprising to find out much more comfortable for me typing in identifiers that look-like-this is.

And, please, no tired cracks about Lisp and parens -- that's completely unrelated to what this post is about.

Very good analysis, whartung. I also find lowercase faster and easier to read, in general. I don't think programming code is different in that respect, as your examples show so well. Granted, there are potential problems with lowercase L sometimes, as I think Garth mentioned. But that's a particular bug in a set of Latin fonts, lowercase was invented to make reading easier and faster, and the occasional capital letter (at start of sentences and elsewhere) breaks that up nicely. Not much point in overdoing it though, which is why the old Method of writing all Nouns etc in Capital went Away. But, there's a flaw everywhere.. that lowercase L.
Henry Spencer and others argued that code should be written the way we're used to read text in general, because it's faster and more readable. And we practice reading that way all the time we're not actually programming. Thus, he specified a space before a parenthesis, not after: if (a > b), not if( a > b ), and use a space after a comma, and so on. Exactly as normal writing is done, for readability.

> In programming however, the separation into lines becomes very significant for visual factoring, and having ascenders and descenders (as lower-case does) blurs those divisions

Indeed, it's about readability. If you have terrible fonts, like on an early dot-matrix, then lower case looks ugly. If you have line-spacing which is too tight, as is very often the case, that's a problem too. But with good typography, lower case is much more comfortable and quick to read.

According to lore, way back when 5- and 6-bit encodings were being designed and only 1 case of letter would fit in the encoding, studies were commissioned by corporations like IBM to see which of uppercase or lowercase was more readable and generally ergonomically suitable for communication. Lowercase absolutely won in those studies. However, it was deemed too scandalous to have proper names, titles, and religious terms displayed without proper case, so upper case was standardized in spite of the results.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

very interesting!

Well, again, it's a matter of opinion, and Forth lets us free-thinkers be stubborn and do things our own way. I kind of drove my math and physics teachers nuts because I always came up with the right answers using methods that were different from what was prescribed.

Some preferences in programming may depend on context too. For example, when I'm writing HTML in a text editor for my website, I find the colors helpful for making sure I complete the tags right; but in normal programming languages, I don't want color, and it's not helpful anyway, because vertical alignment makes any incomplete structures glare.

The 6502 Forth I initially started with made the internals the lower-case equivalent of the words that compiled them; so for example, part of what DO did was to compile do; part of what LOOP did was to compile loop; and 0branch was lower-case because it was not something you would normally use when writing Forth after the compiling words are in place, since it was compiled by things like UNTIL. If you type in dup, it will say it's not defined. Same if you use lower-case hex numerals in a hex number. Sure, since I've modified this Forth kernel so it's hardly recognizable anyway, I could also set bit 5 of characters between a and z inclusive so it wouldn't be case-sensitive, but that would just slow down compilation, and would take away certain advantages, IMO.

I don't speak Pascal, but to me, the above code is ugly, in both cases. What's between BEGIN and END should be indented three or four spaces, not two, so it really looks indented and not like someone just got sloppy about vertical alignment. I am absolutely OCD (not ocd) about vertical alignment. I find much of the code posted here on the forum to be absolutely atrocious, and sometimes I have to copy it into my text editor and massage it to make sense of it before replying. Often I also put two spaces between words, because with just one it looks too much like multi-word names with something like underscores in them. And of course proportional spacing is absolutely out for programming, even though it's more readable for prose. I have the book "Scientific Forth" which uses proportional spacing in the programming, and it is extremely hard to see what's going on. I also put at least two spaces between assembly-language mnemonics and their operands.

I believe these and other things should also be in caps so they don't change the meaning, like BASIC versus basic, TAX versus tax, BRA versus bra, ROT versus rot, FLOPS versus flops, FAT versus fat, WE versus we. You wouldn't write pal for PAL, fbi for FBI, cia for CIA, nor isa, or a lot of others. Sometimes the meaning undergoes an absolutely huge change, like MHz versus mHz, a billion-to-one ratio. My comments went to lower case in the early 90's when I finally got enough characters across the screen that I didn't have to do them in cryptic acronyms and abbreviations.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Color can have more uses. Take this snippet: You'll note that in the second line, ldy.di cp is not bold. That's because there is no instruction LDY (CP) (more's the pity) and I've set up vim to bold valid mnemonics as I type. This eliminates a whole class of errors, because after a while, your subconscious goes "uh, wait a sec" if an instruction doesn't turn bold. It's like a minature "confirm" for every instruction. The blue for jumps/branches and red for halts is nice, but in retrospect not really necessary.

(I've been trying to figure out a similar system where the editor will recognize Forth words that are in the Dictionary (or have been just defined), but the effort would seem to be in no relationship to the gain. It's easy here because Typist's' mnemonics are 1:1 for the opcodes, there is a fixed set of 256 of them, and vim is awesome.)

I'm curious what you think of Python's whitespace? Personally, I find Python code very easy to read, but annoying to rewrite, because something always seems to slip, and have come around to Google's way of thinking with Go: Get some program to automatically format everything the exactly same way so the stupid humans don't mess it up (see https://golang.org/cmd/gofmt/). What this means is that pretty much every serious Go program on the planet has the exact same formatting.

I loathe Python's whitespace.

I'm much more fond of automated (or at least assisted) formatting. I'm much happier cutting and pasting a block of code, or, literally, "typing wherever I want", and then hitting Ctrl-Shift-F and, shazam, all of the code is reformatted. Putting the burden on formatting on the user, as Python does, is just putting it in the wrong place. Maybe it was attractive back in the day, when auto formatting was not as popular but at the same time it also forces an idiom on the developer. Any benefit forced indention offers is to only the most junior of developers. In time, "everyone" pretty much adopts some indention idiom. So, the short term gain of forced indention has costs long after it offers any real benefit.

I put brackets around single if statements for a reason:

vs

Simply because it makes moving code around easier, and removes fiddly bits. Adding a line, then having to add brackets, then removing it, and then having to remove the brackets to maintain consistency, just too fiddly for me. I'd rather hack and slash more coarsely and hit the magic button.

As for Go, the fact that they have not just the standard formatting, but they provided the entire build and packaging environment, I find all of that attractive from a "out of the box" experience point of view. Contrast that to the modern Javascript world and it's plethora of packaging options, among other things -- the mind just reels. Other than that, though, I have not done much Go.

Similarly, along with syntax coloring, auto-formatting can show mistakes. You run auto-format and you block suddenly jumps out of where you thought it should be, tells you that you might be missing something somewhere.

Does it just overwrite your comments?


My personal preference is to not have those "helps". The Forth compiler will tell me right away anyway if an instruction or addressing mode is not defined.


From what I see at https://en.wikipedia.org/wiki/Python_sy ... ndentation, the Python version is much more palatable than the C version. I don't want the language to force you to do the formatting some pre-conceived way though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?