> In Forth there is only memory - word and byte-sized cells of storage
in memory, and stacks. You step down on the level of assembly language
which may sound daunting, yet gives you full control over every aspect
of memory layout.
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?
You define words which are like functions which you could use to operate on multibyte data. Most forth code uses large dictionaries of words. So it will look like 'dosomething decode bytes' where bytes is your utf8 and decode is some utf8 decoder and so on.
Looking at this Forth code as a programmer who has never written any Forth code, I can understand how "ordinary" code looks to non-programmers. That whole RPN business means I cannot even figure out where to start reading.
>Other than in niche or pet projects, can this even work?
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.
On a new OS, forth often has a "first mover" advantage. E.g. some of the first apps for MacOS were developed in forth. It's also useful when limited resources are available. OO forth is quite pleasant to work in, if you really want to.
That said, I wish somebody would have created a statically typed forth.
This can work, but it's incredibly tedious and not worth the trouble. Writing in Forth is like writing in pure CIL or JVM bytecode (they're both stack machines like Forth). Sure, you can do it, but if it was so rewarding, people wouldn't be using Java or C#.
That's not true at all. I know multiple people who are incredibly productive in Forth environments, though I don't use it myself. Pretending that it's like writing in JVM bytecode (despite some overlap between the two) is completely unfounded.
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 couple of really good FORTH programmers over the years. They were humble about it, were also happy to use other tools in their work, and they just happened to be working on projects that were really good fits for FORTH's strengths.
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 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?
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 think some of it may come from being forced to use X language, and then finding Y language, and realizing that it fits your mindset perfectly, and deciding that everyone using X must be idiots. Ie, these partisans were exposed to other languages, but never particularly liked them, until this new thing came along that seemed like a revelation. The zeal of a convert, sort of thing.
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).
I don't think it is major corporate backing -- for example, neither Perl nor PHP had one, and they still are (and always were) vastly more popular than Forth.
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.
You can't attack another user like that on HN, no matter how strongly you feel or disagree. Please make your substantive points thoughtfully in the future.
At a guess you've never actually done any significant programming in Forth.
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.
It's not like pure CIL or JVM bytecode when the language can be extended. The process is to make what you need and only then write the program. It's remarkable how fast you can move up language levels once you grok it.
This is hard to believe, as in this thread and everywhere, the only software used to tout Forth is low-level stuff. Even if Forth was able to be squeezed into a high-level language, it doesn't seem to have any advantage, or, in fact any differences from existing ones. What would a high-level Forth bring to the table that Java or e.g. Clojure don't have?
Because Forth isn't really an application development language as much as it is a very flexible toolbox for programmers who are toolmakers themselves. You can write full applications in it but that is not where Forth shines. If I had to bring up a new machine though that would be one of the first things I would port. (And it would take a couple of hours at most once the hardware was up and running)
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?