8 ms·

This is neat stuff, but it also shows how far behind some schools can be in technology. Yes, I did the hex-keypad-assembler-in-your-head thing, but, by 1985 th

This is neat stuff, but it also shows how far behind some schools can be in technology. Yes, I did the hex-keypad-assembler-in-your-head thing, but, by 1985 there were far better options. One word: Forth Funny enough, I built an eleven processor parallel-ish computer in 1985 to control a large (three feet high) walking robot. That's in the days when you couldn't buy kits for this stuff. You had to design all of the mechanical bits, machine the parts, design the electronics, build the boards and then program it yourself. The machine had eleven 6502's plus an additional one acting as the supervisor and comms link to a PC. The entire system was programmed in Forth, which I mostly rolled out from scratch. This included writing my own screen-based text editor. The PC ran APL. The project was a bit more elaborate than that. As a very --very-- green college student I ended up presenting a paper on this project at an international ACM conference. Once you bootstrap an embedded system with Forth the world changes. In '85 there were few reasons to slog it out using hand-coded assembler to automate a labeling machine. My guess is that he and/or his school did not have any exposure to the mounting Forth embedded community and so they ended-up doing it the hard way. That's still good. You learn a lot either way.

kragen 14y ago
My experience so far is that my Forth is shorter, but my assembly has fewer bugs. Maybe this means that Forth wins for larger projects, because it's harder to read but easier to write?
- robomartin 14y ago
  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.
- kragen 14y ago
  Oops, I meant "easier to read but harder to write".

kragen 14y ago

My experience so far is that my Forth is shorter, but my assembly has fewer bugs. Maybe this means that Forth wins for larger projects, because it's harder to read but easier to write?

robomartin 14y ago
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.
kragen 14y ago
Oops, I meant "easier to read but harder to write".