3 ms·

Sometimes I feel discussions on HN always go into the weeds with people going back and forth while losing sight of reality. I used Forth professionally for wel

Sometimes I feel discussions on HN always go into the weeds with people going back and forth while losing sight of reality. I used Forth professionally for well over a decade. I made truckloads of money with the end products. One of the companies I was involved with, which was 100% Forth, sold for just south of $20 million USD. Customers don’t go to Home Depot to buy drill bits. They go there to buy holes. The world could not care less if solution A was coded in C, solution B in Forth and solution C using a keypad to enter machine code. All they care about is the best solution at the best price. I have always felt that the distinction between experienced and less experienced engineers is that those with experience focus on what matters —delivering value to customers— while the less experienced folk needlessly burn time on theory, languages, code editors and other stuff. 25 years ago I made over $500K with a small 6502 embedded system used to help control lab equipment during cancer research lab tests. I made this box with a 6502, a couple of UARTS, a 2x16 LCD display and four pushbuttons. The box sold for $2,000 each. Sold piles of them. The code was written in Forth. The buyers could not care less. Neither did I frankly. I love Forth, but, at the end of the day, it’s just another tool. Customers want holes.

ggm 7y ago
Customers want holes. At one level I entirely agree. But at another, when it comes to the holes they drill in the bathroom to hold the toilet roll, and the holes they believe were drilled in the pickle fork holding the wing onto the 737-max, they feel very differently about the holes. The first one, They don't much WANT The toilet paper falling off, but its kinda meh. The second one, being told uncle fester was given a hand drill from the barn and told to ream 'em good and deep doesn't fill anyone with joy. Customers want the right kind of holes.
- robomartin 7y ago
  These kinds of analogies are not intended as precise engineering or business definitions. They are simple thinking tools used to deliver a point. If you are in the business of delivering holes for aerospace customers your focus should be on delivering the kinds of holes they need. At the end of the day, they still only care about holes. That’s what they are buying. Most customers using a software-based product could not care less if it was created using vim and python or toggle switches and machine language. They are after the solution to a problem; that’s all they care about. Our customers don’t buy language features, compiler flags, stacks, lists, dictionaries, classes, variables or functions.
  - ggm 7y ago
    Aphorisms have to be tested. "Did you drill these holes to required tolerances and was the material tested for overheating and delamination" is not that far off "did you use llvm or gcc and what compile time options did you use"
    - robomartin 7y ago
      You missed the point. Forget about holes and think about what customers are looking for. The answer is a solution to a problem. Nobody buys a car because they are after one with body panels made with hydro-forming rather than a sequential press. They are after a vehicle that addresses the transportation needs they might have. They could not care less if it was designed using SolidWorks, Fusion 360 or Siemens NX. They are looking for a hole.
untangle 7y ago
> 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.
- robomartin 7y ago
  Every single one of your statements is wrong. 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.

ggm 7y ago

Customers want holes. At one level I entirely agree. But at another, when it comes to the holes they drill in the bathroom to hold the toilet roll, and the holes they believe were drilled in the pickle fork holding the wing onto the 737-max, they feel very differently about the holes. The first one, They don't much WANT The toilet paper falling off, but its kinda meh. The second one, being told uncle fester was given a hand drill from the barn and told to ream 'em good and deep doesn't fill anyone with joy. Customers want the right kind of holes.

robomartin 7y ago
These kinds of analogies are not intended as precise engineering or business definitions. They are simple thinking tools used to deliver a point. If you are in the business of delivering holes for aerospace customers your focus should be on delivering the kinds of holes they need. At the end of the day, they still only care about holes. That’s what they are buying. Most customers using a software-based product could not care less if it was created using vim and python or toggle switches and machine language. They are after the solution to a problem; that’s all they care about. Our customers don’t buy language features, compiler flags, stacks, lists, dictionaries, classes, variables or functions.
- ggm 7y ago
  Aphorisms have to be tested. "Did you drill these holes to required tolerances and was the material tested for overheating and delamination" is not that far off "did you use llvm or gcc and what compile time options did you use"
  - robomartin 7y ago
    You missed the point. Forget about holes and think about what customers are looking for. The answer is a solution to a problem. Nobody buys a car because they are after one with body panels made with hydro-forming rather than a sequential press. They are after a vehicle that addresses the transportation needs they might have. They could not care less if it was designed using SolidWorks, Fusion 360 or Siemens NX. They are looking for a hole.

untangle 7y ago

> 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.

robomartin 7y ago
Every single one of your statements is wrong. 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.