Other than in niche or pet projects, can this even work?
If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder?
Or do you just punt and use ascii code pages?
Other than in niche or pet projects, can this even work?
If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder?
Or do you just punt and use ascii code pages?
edit: see https://rosettacode.org/wiki/UTF-8_encode_and_decode#Forth for a forth word for decoding utf-8
All kinds of projects have been written in Forth, so yes.
Also, regarding "You step down on the level of assembly language which may sound daunting, yet gives you full control over every aspect of memory layout.", until around the 80s, tons of software, commercial or not, including full blown games like "Prince of Persia", was written in assembly, so again, yes....
You're assuming that there's even ASCII. colorForth doesn't use it. It's all memory, but what happens is that you write a set of words that operate on the memory to form the abstraction you need, such as Unicode.
That said, I wish somebody would have created a statically typed forth.
Your claim that C# and Java won based on merits is similarly unfounded: they won because they have major corporate backing. There are countless languages before and after that did what they did, better. Limbo beats Java at almost everything Java aims to do, for example.
I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and have you seen the light, brother? Okay, most of them weren't that bad, but a few were (one guy I worked with got fired because (a) he told his boss that FORTH was all he was going to use, (b) the FORTH runtime was over half of his code budget and he had kinda been keeping that secret, and (c) none of that fantastically <insert some adjectives here> FORTH code was compatible with the ROM it needed to run on . . . so you can imagine that fun little tete a tete).
Whatever the languages's wins or faults, it's still a great idea to write your own FORTH at some point. It's a ton of fun, and quite instructive when you've gotten a fully functional programming environment that fits in a few tens of kilobytes.
I've seen exactly one Forth programmer like that, they are simply too rare. But the stereotype language fanatic is easily recognized in other language eco-systems, Perl and Rust have a disproportionately high share of this and I'm sure there are others. Typically this stems from either insecurity or a lack of exposure to other eco-systems or the drive to create camps of in and out groups to attempt to gain mindshare.
Very tiring and counterproductive in the long run, I think to some extent this is what killed Perl, simply that no matter how good the language was/is regular people simply don't want to be associated with fanatics and recognize that no tool will ever be perfect.
I haven't spent enough time with Forth or Rust to say, but I can see why both of them could seem like that to people. Forth, especially, has a sort of philosophical/hacker bent that is inherently appealing to a certain kind of person (including me!). Whereas I can't imagine Java ever winning someone over like that (though I'm sure it has).
It seems to me that Forth only works for certain people, and those people are quite rare. For the majority of programmers, almost every other language will make them much more productive.
The 777 wouldn't fly if you took out all the Forth code and there are plenty of other examples. Forth is at a much higher level than JVM byte code, byte code would be comparable to the output of a Forth compiler in roughly the same way that a .S file could be the output of a C compiler. Clearly C is at a (somewhat) higher level than Assembly.
Forth is definitely an acquired taste, but it is an interesting shift in perspective and as such a language that is worth learning, not because it will have a lot of commercial potential but because it makes you look at problems in a different way.
The same goes for LISP, Erlang/Elixir and Clojure.