FwarkALark

Why is this exposed to the user? If it isn't exposed to the user, what on earth are you talking about?

Again, I don't see how a private industry per se could even possibly be worse given the demand for a profit margin. Your beef is with some other aspect of this process.

I mean, all industries? The profit margin guarantees this. Anyone who has worked in private industry will verify its utter incompetence in the long term.

Again, this can't be worse than private industry—that profit margin will guarantee this. I guarantee there is some other disease to blame for the waste—probably politicians of some sort invested in industry.

Of course, this does demand citizens give a shit, which seems hopeless at this point.

Is this something where a public competitor might help? It surely can't be worse than private industry.

> At what point should an acquisition be allowed on the sake of something being able to continue to exist and possibly save jobs?

Never? The entire point of private companies is that they take risk on themselves. If we have to bail them out we might as well just nationalize them. See: the entire american airline industry.

...for the client tooling, or for the service? The service is understandable but the tooling makes no sense whatsoever.

> If would likely take significant research effort to even figure out a way to incorporate the new discoveries into these engines.

What? Have you ever used a solver before? The actual APIs exposed to the user are very simple interfaces that should allow swapping out the backend regardless of the complexity. The idea a new algorithm—short of something like "updating the solution to adjust to a change in data"—would not require any sort of research to slot in as an implementation for the existing interface.

> By "variable" I mean a name with a value attached.

I'd just use "symbol" then. Symbols don't have much utility without a referent.

> Forth doesn't let you define these within procedures.

"within" vs "not within" seems like a distraction. Forth certainly allows defining your own symbols.

> Values are communicated implicitly on the stack in Forth, where other languages give them names and then use the names to say where the value goes.

Forth uses names, too. Other languages have unnamed expressions too. I just don't see the distinction you're drawing as meaningful.

I don't think anyone uses a stackless fortran.

> In ‘stack-based languages’ the stack is, most usually, an explicit semantic construct which acts as the only available value for procedures to act on.

To the extent this is true, this is also true of all languages that anyone uses these days—C, JVM, Rust, Chez Scheme, GHC, python, ruby, ocaml, blah blah blah. The only difference is the syntax used to manipulate the stack. Acknowledging that syntax is the main difference from other languages seems key to evangelization. The idea of "implicit/explicit" doesn't really make sense. how do you refer to the stack in forth? You don't. How do you refer to the stack in C? You don't. Both operate with respect to the stack without ever referring to it via syntax. In both languages, the stack is invoked by referring to procedures/words.

Look if you want to keep up this fantasy that forth or factor is somehow more stack-oriented than any other languages, go right ahead. But you're going to fundamentally misunderstand why people use the language. It's the syntax! It was always about syntax. The stack is just a necessary implementation detail to deliver this syntax, same as in every other language that people actually use.