> Customers want holes.
So what? The customers of Forth are computer programmers, not carpenters.
And I, for one, go to Home Depot to buy drill bits (not holes).
If I wanted to buy holes, I'd hire a handyman.
So what? The customers of Forth are computer programmers, not carpenters.
And I, for one, go to Home Depot to buy drill bits (not holes).
If I wanted to buy holes, I'd hire a handyman.
You are missing the point, which, frankly, is exactly the reason business types don't want engineers anywhere near customers. It took me lots of professional coaching and years of experience to stop seeing our products as an engineer.
> The customers of Forth are computer programmers, not carpenters.
Unless the activity being conducted is an academic pursuit, the tools (languages, compilers, editors, etc.) are utterly irrelevant. The customer isn't the programmer. The customer is the one exchanging something of value (typically cash) for a solution to a problem, and usually something that delivers value beyond the mere cost of the thing. The customer is NOT the programmer creating the solution. Far from it. Any software engineer who honestly believes they are the customer ought to be fired as quickly as possible.
> And I, for one, go to Home Depot to buy drill bits (not holes).
The only way that would be true is if you purchase drill bits for display and never use them. If they are used, even once, their purpose is to make a hole.
In other words, the solution one is seeking isn't "I need to own a drill bit", but rather "I need a hole" or "I know I might need a hole in the future".
> If I wanted to buy holes, I'd hire a handyman.
Only if you'd hire a handyman to just come over, drill a hole and go away. Which, of course, would be a very rare and even bizarre use case.
Again, this is missing the point of my parent comment: The discussion of tools and languages often diverts into truly irrelevant minutiae that has absolutely nothing whatsoever to do with what a business exists to deliver: Solutions to customer's problems.
To get back to Forth, it would be like objecting to the use of the language on the grounds that traditional Forth isn't object oriented (in a traditional sense) when all you are trying to build is a simple irrigation controller (or whatever). This is getting lost in the weeds for no reason at all.
What would be a valid objection to using Forth? Oh, there are many, and this coming from someone who loves the language and used it professionally for about a decade. The simplest one I can offer with my business hat on is, the pool of qualified programmers isn't large. Another would be that the library ecosystem is dwarfed when compared with something like Python.
How are these different from objections like "it isn't typed"? Simple: These are real impediments to the delivery of solutions customers need. All the CS theory stuff is irrelevant. The proof is that the language enjoyed commercial application for a very long time, with everything from embedded systems to sophisticated industrial controls and more being developed using Forth. As I said in my parent post, I was involved in a company that sold for USD $20MM and the product was 100% done in Forth. BTW, the first thing the buyers did is convert the codebase to C. Because by that time finding Forth programmers was starting to become very hard.
So, yeah, I would not use Forth or APL today (both languages I love) because this would be a bad business decision. On a technical level you can do anything with these languages, despite whatever limitations they may have. From a business perspective, if you advocate for the customer rather than the engineers, when contrasted to other options, they are not the best idea.