I have addressed that point twice already. This is tiring.
I discovered Forth a long time ago and thought, there's no way this language is viable, and yet it was used in prestigious projects. It made me curious so I tried it, dropped it, picked it again and tried harder. I was young and open minded. A couple decades later Forth is my go-to language.
I have no interest in convincing people with immutable opinions who cannot listen.
But the topic is readability not viability. Pretty much all programming languages have some readability issues, dealing with them via coding conventions.
Nowadays we want our text editors to handle those conventions automatically, and be able to recover them even if we delete extra white space or line breaks.
I also discovered Forth 40 years ago. It looked viable to me. I recognized then that while it's interactive like BASIC, it's way faster. Also cleaner, because Forth functions are reentrant, usually not relying on global variables.
> But the topic is readability not viability. Pretty much all programming languages have some readability issues, dealing with them via coding conventions.
Thank you, that's part of what I was saying.
> Nowadays we want our text editors to handle those conventions automatically
But you can't always have what you want. The other guy I was talking to apparently has no idea what it means to deal with an embedded system, hopefully you do.
> I also discovered Forth 40 years ago
And did you write Forth during these 40 decades? I'm apparently a bit younger than you but I did picked and dropped Forth a couple of times for other "nicer" interpreted languages. All in all I think I have a solid 2 decades of practice in Forth. During this time I have constantly changed my idioms, so it's not just doing the same thing for decades and getting used to it.
And I'm saying that readability became less and less of an issue as your writing skills improve. That's also something the other guy refuses to understand.
The arity issue that is often pointed out is not a bigger deal than stumbling on some unknown Javascript, Lua, Lisp or whatever function call and figuring out what each parameter does, especially when it's just a boolean (a bad practice, yet a common practice). I have programs that are made of hundreds of Forth definitions. Arity and expression structure are sometimes an issue, true. When it happens, I just use the search function of my editor.
But why do you specifically forbid yourself to mfk*g split your editor window and go look to the definition of a function when it's Forth, when you do that every day in any other language?
I don't want to look up the semantic definition of an identifier just to understand which chunks in the syntax are its arguments and which are not.
The tide is flowing the other way now. Kids are using editors that integrate deeply with compilers (via Microsoft's Language Server Protocol). The editors are providing code formatting and completion based on communicating with a compiler. That seems like it could work with Forth.
> The other guy I was talking to apparently has no idea what it means to deal with an embedded system
I would love to see you justify this. Sadly you will not, because I understand it quite well. It's a pretty basic principal that if a system is capable of handling user input interactively, you can instead connect a more powerful computer and have it receive input from that device. Hence all devices with REPLs can benefit from editors hosted on my own computer. In an embedded system, it is much more likely for you to have to hook your own computer up to something than it is for that thing to be able to accept user input independently. Most embedded devices do not have a USB slot for you to plug your keyboard in.
> That's also something the other guy refuses to understand.
It is a point which I addressed in my other post.
This manner of response is stupid and infantile. I hope you can talk to me directly next time.
> This manner of response is stupid and infantile. I hope you can talk to me directly next time.
I made it pretty clear I didn't wish to continue that conversation, so I wasn't responding to you. There will probably be no next time, as there's a clear gap in practical experience - on that particular topic - between you and me; it would take far too much energy for me to explain things step by step and I'd gain nothing from it.
Then why did you continue the conversation? I'm not forcing you to make snide jabs at me in a public space, and you can hardly blame me for responding to them.
> it would take far too much energy for me to explain things step by step and I'd gain nothing from it
If you cannot explain it simply, you don't understand it well enough.
> I'm not forcing you to make snide jabs at me in a public space,
Ok, sorry. That was a poor way to invite that person to read the parallel thread. It's a bit frustrating to deal with claims based on nothing but theory when I have at least two decades of practical experience on these topics.
> If you cannot explain it simply, you don't understand it well enough.
First, that answers something I didn't write (of course I can explain those things simply, the problem is that it would easily make a whole article) and secondly, what you wrote ignore the fact that teaching is a skill, so not all experts are good teachers.
Okay, that's well and good, but you are sat there saying that you can manually input data into an embedded device, but for some reason can't connect a computer to it. Unless it has a built-in keyboard, that simply isn't true. If it was true, it would be trivial to prove. You could just name the device and situation.
I discovered Forth a long time ago and thought, there's no way this language is viable, and yet it was used in prestigious projects. It made me curious so I tried it, dropped it, picked it again and tried harder. I was young and open minded. A couple decades later Forth is my go-to language.
I have no interest in convincing people with immutable opinions who cannot listen.