Now we are beyond nuances and talking about significant differences. Yes, Forth's interactivity is the key to the programmers productivity.
No, that's fast, particularly compared to the compile assemble EPROM half hour jaunts of the past. Forth really stood out as an almost instantaneous feedback then.
Now the update cycles are fast. But when it comes to a quick question, you still can't touch Forth. If I want to know what is on a parallel port, I just look. If I want to see a string in memory, I just dump it. You get all the advantages of ICE with Forth, and the ability to write one-liner programs to test ideas. Conventional systems still just can't emulate that interactivity.
I mostly work in an editor, and a serial downloader / terminal emulator. If I get carried away with an interactive session, I can go back and capture the buffer, edit out the false steps, and drop that into my developing source code. So no. I have few problems with loosing efforts.
If most think Forth is unreadable at a source code level, taking off the names makes the compiled code about as obscure as you care to imagine. Security by obscurity, for certain. All my Forth's can compile headerless code. It cuts code size by about another half (depending on programmer style).
Unfortunately, there aren't many opportunities to do direct comparisons between the use of two languages. All the data points I have personal knowlege of, came out strongly in Forth's favor, so this previously mentioned situation is not unusual.
The most convincing case for my personal experience base (at least to my thinking) came when I was a consultant to Eagle Signal, who made traffic lights. This was back in '83. Originally, they had a 1MHz 6801 that ran their lights, programmed in Forth by a single programmer. As modules were added, the program grew. Eventually they had to go to a 2MHz 6801. They were concerned because their traffic program was 7K and the total program size with the communications modules was over 32K and rising, and they were having to go faster and faster. They'd either gone to a
2MHz 6809, or were thinking about it.When I came in as their consultant, I looked at the code and concluded it desparately needed some factoring, because 60 times a second, they were checking everything. They even check to see if it was midnight, Feb
28th, on a on a leap year, every 60th of a second. (Once a day should have been enough!) So I told them how to get their program back in order by doing a real time executive.They accepted my proposals, and so asked me to head a team to rewrite the program, but do it in C, because they couldn't find Forth programmers. Well, the C version of my "improved" traffic module in Whitesmith C turned out to be 13K, up from 7 in Forth. So, I looked bad. I checked myself by writting my traffic module in Forth on my own time. It came down from the 7K Forth they had to 4.5K, about 1/3 the size of the C program. I wasn't wrong about the methods used being smaller, faster and more efficient.
So, anyway, they eventually turned the project over to someone else, and I left. Last I heard, about a year later, they had expanded the team to something like a dozen programmers, and had to go to a 10MHz 68008, and were over 108K of compiled code and climbing, to get the same traffic light they had when in Forth. And they'd spent more man years doing this behemoth, than they'd spent on the original Forth programmer to write, and then maintaining it, for years to begin with.
I am. I found C object to be 3 to 4x bigger, and needed a much faster, more powerful processor to run on, and took many more man years to get done. Again, actual experience, a1:1 comparison, not hypothetical paraboley.
So I have my personal experience, and many other second hand observations from those in the Forth community I trust to represent situations honestly, who have similar experiences. Now I want to repeat something I said early on; "some Forth programmer knock... out a solution in days, when a team of programmers struggles to do anything near the scope in months. Now, whether you can blame it on the programmer, or on the language, gets less likely when you see the same pattern repeated across many programmers and many situations."