3 ms·

I also believe that this commercial bent Forth has is contributing to it's decline

smackeyacky 4y ago
I would disagree with this statement. The (earlier) history of Forth was that the original inventor would be contracted to implement it on new machines. That it took forever to spawn any kind of interest outside of his commercial activity speaks to Forths practical limitations i.e. every installation becomes a new, extremely opinionated language and we all know the aphorism about opinions.
- golem14 4y ago
  I think this is also true, but authors could have open sourced application code. Some of it has, esp with Forth standardization . However, even so, there is just very little Forth application code available as open source.
  - shagie 4y ago
    Why would a company open source (or publish) the controller for... http://www.forth.org/svfig/kk/11-2017-LWagner.pdf http://www.forth.org/svfig/kk/11-2017-LWagner.pdf ... industrial refrigeration controls, wireless spinal cord nerve stimulation, satellite communication dish positioning? This isn't software that you're going to be sharing. It is in nearly every situation bespoke software for that specific industrial or medical application.
    - golem14 4y ago
      Why is there _any_ open source? There are enough areas, libraries, whatnot, where it would be perfectly fine to share forth code. I mean, look at device drivers for linux. Doing this would really have helped the ecosystem, I suspect, because people would have tried to clean up their code a bit before throwing it on github, for instance. Not that examples that are on github today are all stellar.
      - shagie 4y ago
        Because those examples are medical and industrial devices. The insurance issues that a manufacturer gets when people are provided the software to modify it becomes much more complicated. It becomes much more difficult to insure a facility that has an industrial refrigeration unit where it is possible for people to change how it runs. Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse. From an insurance perspective, that includes keeping the source code closed. This is a very different issue from consumer devices. An open source device driver tinkering causes the computer to overheat? "No warranty" is enough to disclaim that for consumer systems - not so with industrial devices where the tinkering person can kill someone and the company making the device is liable because this was a precaution they could have taken.
        skissane 4y ago
        > Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse. Is that an accurate statement of the legal liability? If the vendor clearly states in the sales contract that it disapproves of unauthorised customer modifications, that such modifications will invalidate product safety and regulatory compliance testing, and that it excludes all liability for customers who ignore those warnings – and the customer does it anyway – why should they be liable? > This is a very different issue from consumer devices. I think it is indeed different, but in a different way than you think. Products sold directly to ordinary consumers, courts accept that most consumers won't read or won't understand the sale contract, and so are more likely to invalidate exclusions of liability contained therein. Industrial and medical devices are not sold directly to individual consumers; their purchasers are usually corporate entities (whether a business or a not-for-profit enterprise such as a hospital), which can be assumed to have ready access to legal counsel; and the staff of the entity involved in the purchase can be expected to have a professional level of understanding of the technology, safety/regulatory/compliance risks involved, etc. Given that, courts are far more likely to uphold exclusions of liability (including exclusions of liability for unauthorised customer modifications), than for a contract of sale to individual consumers. Furthermore, the vendor can put in the sale contract that the customer indemnifies the vendor for any liability caused by the customer's unauthorised modifications. Such an indemnity is far more likely to be upheld in a B2B contract than a B2C one. And unlike the B2C case, the customer is likely to have significant financial resources, and its own liability insurance, making such an indemnity much more meaningful in practice. The vendor can also do customer due diligence, such as asking customers to provide evidence of their own liability insurance – something which is rarely practical in the B2C space.

I would disagree with this statement. The (earlier) history of Forth was that the original inventor would be contracted to implement it on new machines. That it took forever to spawn any kind of interest outside of his commercial activity speaks to Forths practical limitations i.e. every installation becomes a new, extremely opinionated language and we all know the aphorism about opinions.

golem14 4y ago
I think this is also true, but authors could have open sourced application code. Some of it has, esp with Forth standardization . However, even so, there is just very little Forth application code available as open source.
- shagie 4y ago
  Why would a company open source (or publish) the controller for... http://www.forth.org/svfig/kk/11-2017-LWagner.pdf http://www.forth.org/svfig/kk/11-2017-LWagner.pdf ... industrial refrigeration controls, wireless spinal cord nerve stimulation, satellite communication dish positioning? This isn't software that you're going to be sharing. It is in nearly every situation bespoke software for that specific industrial or medical application.
  - golem14 4y ago
    Why is there _any_ open source? There are enough areas, libraries, whatnot, where it would be perfectly fine to share forth code. I mean, look at device drivers for linux. Doing this would really have helped the ecosystem, I suspect, because people would have tried to clean up their code a bit before throwing it on github, for instance. Not that examples that are on github today are all stellar.
    - shagie 4y ago
      Because those examples are medical and industrial devices. The insurance issues that a manufacturer gets when people are provided the software to modify it becomes much more complicated. It becomes much more difficult to insure a facility that has an industrial refrigeration unit where it is possible for people to change how it runs. Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse. From an insurance perspective, that includes keeping the source code closed. This is a very different issue from consumer devices. An open source device driver tinkering causes the computer to overheat? "No warranty" is enough to disclaim that for consumer systems - not so with industrial devices where the tinkering person can kill someone and the company making the device is liable because this was a precaution they could have taken.
      - skissane 4y ago
        > Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse. Is that an accurate statement of the legal liability? If the vendor clearly states in the sales contract that it disapproves of unauthorised customer modifications, that such modifications will invalidate product safety and regulatory compliance testing, and that it excludes all liability for customers who ignore those warnings – and the customer does it anyway – why should they be liable? > This is a very different issue from consumer devices. I think it is indeed different, but in a different way than you think. Products sold directly to ordinary consumers, courts accept that most consumers won't read or won't understand the sale contract, and so are more likely to invalidate exclusions of liability contained therein. Industrial and medical devices are not sold directly to individual consumers; their purchasers are usually corporate entities (whether a business or a not-for-profit enterprise such as a hospital), which can be assumed to have ready access to legal counsel; and the staff of the entity involved in the purchase can be expected to have a professional level of understanding of the technology, safety/regulatory/compliance risks involved, etc. Given that, courts are far more likely to uphold exclusions of liability (including exclusions of liability for unauthorised customer modifications), than for a contract of sale to individual consumers. Furthermore, the vendor can put in the sale contract that the customer indemnifies the vendor for any liability caused by the customer's unauthorised modifications. Such an indemnity is far more likely to be upheld in a B2B contract than a B2C one. And unlike the B2C case, the customer is likely to have significant financial resources, and its own liability insurance, making such an indemnity much more meaningful in practice. The vendor can also do customer due diligence, such as asking customers to provide evidence of their own liability insurance – something which is rarely practical in the B2C space.