Smug Forth Weenies

As a recovering SmugForthWeenie, I think I'm qualified to comment. A SmugForthWeenie is someone who:

• Points out that FORTH was 20 years ahead of its time when it was invented - 37 years ago.
• Loves assembly language programming, but doesn't think it's confusing enough.
• Thinks exception handling should consist of aborting with either no error message at all, or a cryptic, generic error message.
• Knows on an intuitive level that God created the integers, and everything else is the work of Satan.
• Doesn't program on a system where FORTH can't become the OS.

But, on the plus side, it has made me a better programmer; if your first indication that something is wrong with your code is your computer starts doing a convincing impersonation of a doorstop, you get to be pretty good at finding bugs.

---

As a recovering SmugForthWeenie, I think I'm qualified to comment.

Actually, you are not. Your comments clearly belie that you never were a serious user of ForthLanguage. Allow me to elucidate:

• Points out that FORTH was 20 years ahead of its time when it was invented - 37 years ago.
  • And Forth continues to be every bit as expressive and productive as ever. Just recently, I rewrote a critical piece of Python code for our ContinuousBuild? system here at work. I pseudo-coded it in Forth during a single Scrum session. When I coded it for real in Python, the result was a 24KiB source file, most of that being syntactic noise. Lots of defs, ()s, :s, etc. Then there's the lack of HyperStaticGlobalEnvironment, which means I had to rename many symbols, just to prevent bogus naming conflicts -- conflicts trivially resolved by a human reader, but which would utterly decimate a compiler's understanding of the program.
• Loves assembly language programming, but doesn't think it's confusing enough.
  • With all due respect to your and the reader's sensibilities, this statement is is Pure, unsubstantiated bullshit. If you want confusion in your coding, try working with AspectOrientedProgramming, particularly when things break and you need to debug. Try working with SpringFramework, what with its 52 kilobyte long error dumps that are worthless. Try getting Maven integrated with Eclipse seamlessly across an entire organization. ChuckMoore had said that the biggest problem with ForthLanguage developers is that they love to play games with the tools -- always writing new development tools, but never actually developing. I do not agree with this; in my own experience, I've spent over 80% of my work time dealing with Maven, Ant, Eclipse, and Spring-related bullshit issues that have served only to impede my understanding of the project I'm trying to maintain.
• Thinks exception handling should consist of aborting with either no error message at all, or a cryptic, generic error message.
  • More intentional falsehood. Error handling is handled in a context-sensitive way. You confuse the Forth compiler itself with all possible Forth-written applications. For the record, my Forth compilers are very explicit: upon finding a word which isn't known in the dictionary or as a number, it states this as such, in plain English. My Forth unit testing package makes explicit when a unit test fails because of a failed expectation versus a stack imbalance bug. And so on. As a user of GForth as well, I can also attest to its ability to not only clearly indicate a failure, but it also gives a return stack trace.
• Knows on an intuitive level that God created the integers, and everything else is the work of Satan.
  • False, and obviously flamebait.
• Doesn't program on a system where FORTH can't become the OS.
  • Technically, this statement doesn't even make sense. Every computer ever designed by man can support Forth as an operating system. But, an overwhelming majority use a Forth system hosted under either Windows or Linux. I code my Forth applications on Linux using GForth.