| > Well, your opinion about it has changed quite a bit. I'm not aware that I have held any other opinion about NewLisp at any time in the past. The language described by ANS Forth not only doesn't have arity checking, it has no type checking. That is to say, the items on the data stack have no type: not run-time, not static. Two addresses could be pushed onto the stack, and then operated on as a double integer. There is nothing wrong with that, just like there is nothing wrong with machine language instruction sets. We can write a compiler for a higher level language which compiles to ANS Forth, one that is considerably safe. There is value in that because we still have the benefit of portability, small run-time footprint and low resource use, depending on our application size. Type, arity and other checking is not analogous to training wheels for beginners. Nobody believes nonsense like this once they are out of their programming puberty. I suspect you wouldn't say that in an interview, if you actually wanted the job. > Most often the program just segfaults right away If you're getting a "segfault" it's because you're running on a virtual memory system (likely written for you in a considerable amount of C). Things don't always segfault right away. The problem can be in a conditional code that depends on particular kinds of inputs. If you're having to trivial function arity mismatches with segfaults (when you have the luxury segfaults) is ridiculous, you can't simultaneously believe that you're working in a higher level language on par with Common Lisp or Scheme, or even ANSI C. > Anyway, there's still dozens of scripting languages that won't move an eyebrow about bad arity. And they are all garbage; so what? Many of these languages, however, will at least behave somewhat safely in the face of bad arity. That is to say, if there are insufficient arguments, those parameters get some default values, and excess arguments are ignored, without lingering around to cause a problem elsewhere. |
You are better off targeting some bytecode VM rather than targeting the Forth language itself. You can target for instance Lua Bytecode and still have all of the benefits.
> Type, arity and other checking is not analogous to training wheels for beginners. Nobody believes nonsense like this once they are out of their programming puberty. I suspect you wouldn't say that in an interview, if you actually wanted the job.
Well I used to believe it was nonsense too. Maybe I'm older that you. Or maybe I was more curious.
I would definitely mention the fact I can program in a point-free, type-less language. That's an additional skill, not a hindrance. I didn't have the chance to test this because I already have a programming job (where I use Forth for personal supporting tools that help dealing with the peculiarities of embedded systems or with the shortcomings of our official software - but don't tell anyone). What I wouldn't do is trying to sell something like Forth to an unknown team for an unknown project.
> If you're getting a "segfault" it's because you're running on a virtual memory system (likely written for you in a considerable amount of C).
Actually yes, it assumes the processor has at least a MMU (virtual memory technically is an additional feature that's often built on MMU). If the CPU doesn't have a MMU, the virtual machine can perform some checks on the pointers (e.g. memory alignment if the CPU requires it). At my current level of sloppiness that's something that could be helpful if really I can't fix my bad habits.
> If you're having [segfaults because of] trivial function arity mismatch, you can't simultaneously believe that you're working in a higher level language on par with Common Lisp or Scheme, or even ANSI C.
I think I did say that Forth is indeed a low-level language. I have no problem with that, because "low-level language" doesn't mean "lesser language" to me.