4 ms·

Perhaps your last few words reveal the reason for the bugs? Forth --or any other language-- is hard to read only when someone doesn't know it or does not use i

Perhaps your last few words reveal the reason for the bugs? Forth --or any other language-- is hard to read only when someone doesn't know it or does not use it frequently enough. For example, I programmed in Lisp nearly every day for a couple of years. I could read Lisp without even thinking about it. That was fifteen years ago. Today I would struggle to make sense out of a non-trivial Lisp program for a couple of weeks. If you use Forth as intended I can't see how you would introduce more bugs when compared to anything. Few languages are inherently buggy. Bugs can nearly always be traced to the programmer, not the language.

kragen 14y ago
All bugs can be traced to the programmer, of course. I find Forth error-prone because it's untyped (not even dynamically typed) and you have parameter-passing errors, where you pass a parameter or get a return value from the wrong place. Traditionally, too, you don't have local variables, but I think that's not actually nearly as big a problem as it sounds. That said, my last few words were exactly backward from what I meant to say. Harder to write than assembly, because you have to take more care to avoid stack-effect bugs and you don't have local variables; but easier to read, because your Forth isn't full of arbitrary noise about which register you're using for what.
- robomartin 14y ago
  You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with. Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the scale). I did years of Forth. Not one thing you are saying rings true. If you know a language you speak it. It's as simple as that.
  - jacquesm 14y ago
    The difference between 'grok' and 'use'.
  - kragen 14y ago
    Oh, I know that about the EDSL nature of Forth, and it's entirely possible that if I really knew Forth, my experience would be different. On the other hand, if you were right that Forth is many orders of magnitude faster to develop with than assembler, we'd see people writing HTML5-compliant web browsers in Forth in a few hours. (I'm figuring: 100 person-years for e.g. Chromium, multiplied by ten for assembly, divided by six orders of magnitude (because five isn't "many") gives you about 8 hours.) So I suspect you're living in some kind of a fantasy world.
    - robomartin 14y ago
      Nope. Wrong again. Writing a browser isn't the right fit for Forth. Could you? Sure. Should you? Nope. Forth is great to develop with but comes with liabilities if used on the wrong project. I remember a product a friend of mine did using Forth. High end embedded system with custom hardware all selling for tens of thousands of dollars per unit. When he started to look into selling the business Forth became a liability. Nothing wrong with it. Te code worked well and was mostly bug-free. The company bidding to acquire his business did not do Forth and saw it as an impediment. They, like a million others, did C. Ultimately he sold the company for $16 million with a requirement to translate the code base to C under contract. Today I use C for any time I need to do embedded work. Having a foundation in a diverse range of languages means that you tend to use a language like C as a toolset to create an efficient development environment through domain specific libraries, data structures and data representation. I rarely find the need to get down to Forth these days. It made a lot of sense with 8 bit resource-restricted microprocessors. Today you can have a 16 or 32 bit embedded processor for a few bucks and have it run at 25, 50 or 100MHz. Different game.
      - kragen 14y ago
        I'm still skeptical about this "many orders of magnitude" nonsense. Even on an 8-bit resource-restricted microprocessor, what could you write with Forth in a day that would take half a century with a team of 60 people in assembly? Or what could you write with Forth in ten minutes that would take you 60 years in assembly? I think you're talking nonsense and being condescending to try to cover it up. And if almost all projects are "the wrong project" for Forth (which seems to be what you're saying, although I don't agree with it) then does it make sense to compare it to a general-purpose language like assembly? You make it sound like a DSL like SQL, not like a framework for all DSLs.

kragen 14y ago

All bugs can be traced to the programmer, of course. I find Forth error-prone because it's untyped (not even dynamically typed) and you have parameter-passing errors, where you pass a parameter or get a return value from the wrong place. Traditionally, too, you don't have local variables, but I think that's not actually nearly as big a problem as it sounds. That said, my last few words were exactly backward from what I meant to say. Harder to write than assembly, because you have to take more care to avoid stack-effect bugs and you don't have local variables; but easier to read, because your Forth isn't full of arbitrary noise about which register you're using for what.

robomartin 14y ago
You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with. Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the scale). I did years of Forth. Not one thing you are saying rings true. If you know a language you speak it. It's as simple as that.
- jacquesm 14y ago
  The difference between 'grok' and 'use'.
- kragen 14y ago
  Oh, I know that about the EDSL nature of Forth, and it's entirely possible that if I really knew Forth, my experience would be different. On the other hand, if you were right that Forth is many orders of magnitude faster to develop with than assembler, we'd see people writing HTML5-compliant web browsers in Forth in a few hours. (I'm figuring: 100 person-years for e.g. Chromium, multiplied by ten for assembly, divided by six orders of magnitude (because five isn't "many") gives you about 8 hours.) So I suspect you're living in some kind of a fantasy world.
  - robomartin 14y ago
    Nope. Wrong again. Writing a browser isn't the right fit for Forth. Could you? Sure. Should you? Nope. Forth is great to develop with but comes with liabilities if used on the wrong project. I remember a product a friend of mine did using Forth. High end embedded system with custom hardware all selling for tens of thousands of dollars per unit. When he started to look into selling the business Forth became a liability. Nothing wrong with it. Te code worked well and was mostly bug-free. The company bidding to acquire his business did not do Forth and saw it as an impediment. They, like a million others, did C. Ultimately he sold the company for $16 million with a requirement to translate the code base to C under contract. Today I use C for any time I need to do embedded work. Having a foundation in a diverse range of languages means that you tend to use a language like C as a toolset to create an efficient development environment through domain specific libraries, data structures and data representation. I rarely find the need to get down to Forth these days. It made a lot of sense with 8 bit resource-restricted microprocessors. Today you can have a 16 or 32 bit embedded processor for a few bucks and have it run at 25, 50 or 100MHz. Different game.
    - kragen 14y ago
      I'm still skeptical about this "many orders of magnitude" nonsense. Even on an 8-bit resource-restricted microprocessor, what could you write with Forth in a day that would take half a century with a team of 60 people in assembly? Or what could you write with Forth in ten minutes that would take you 60 years in assembly? I think you're talking nonsense and being condescending to try to cover it up. And if almost all projects are "the wrong project" for Forth (which seems to be what you're saying, although I don't agree with it) then does it make sense to compare it to a general-purpose language like assembly? You make it sound like a DSL like SQL, not like a framework for all DSLs.