5 ms·

That list is probably inspired by Chuck Moore's article "1% the Code" https://web.archive.org/web/20060104084410/http://www.colorforth.com/1percent.html https:/

by delish 8y ago

That list is probably inspired by Chuck Moore's article "1% the Code" https://web.archive.org/web/20060104084410/http://www.colorforth.com/1percent.html https://web.archive.org/web/20060104084410/http://www.colorf... Relevant excerpt: >colorForth does it differently. There is no syntax, no redundancy, no typing. There are no errors that can be detected. Forth uses postfix, there are no parentheses. No indentation. Comments are deferred to the documentation. No hooks, no compatibility. Words are never hyphenated. There's no heirarchy (sic). No files. No operating system. He probably means "blocks" instead of files and "a condition system or exception system" instead of "stack underflow."

agumonkey 8y ago
has moore written books or articles ?
- dang 8y ago
  There's this classic, at least: https://colorforth.github.io/POL.htm https://colorforth.github.io/POL.htm https://hn.algolia.com/?sort=byDate&dateRange=all&type=story&storyText=false&prefix=false&page=0&query=problem%20oriented%20language%20points%3E3 https://hn.algolia.com/?sort=byDate&dateRange=all&type=story...
  - agumonkey 8y ago
    dank u
- 4thaccount 8y ago
  Safari online has a lengthy interview with him that is an excerpt from a book with lots of interviews on programming Titans. I read the one from Moore every year and I don't even write Forth. It is simply that good and thought provoking.
  - elisharobinson 8y ago
    yes I read it once and it genuinely is the stuff to start cults
    - 4thaccount 8y ago
      Haha, yes that is a good way to explain it. Moore isn't necessarily wrong, but I don't think he is 100% correct either. Not everybody is a software engineer who can spend all day writing code. There are a lot of folks who write shell scripts and the like who need to do talk to computers without getting into machine code and Forth. Does a lawyer need to know the machine? Sounds inefficient use of time.
  - fizfaz 8y ago
    this one: https://www.oreilly.com/library/view/masterminds-of-programming/9780596801670/ch04.html https://www.oreilly.com/library/view/masterminds-of-programm... ? Very interesting interview indeed.
astrobe_ 8y ago
ColorForth is actually pretty much an image-based system. Moore observes that PCs have a lot more memory than he needs (indeed 1Mb is huge for a Forth system), so the image is loaded into memory and the memory is saved to disk. It should be mentioned that Forth is one of those languages that do configuration by editing the source code. This is probably the recommendable practice, instead of INI files or worse, XML (why write another parser when you already have one?). For really big data, binary format would probably be preferred (I actually have no experience in the area), with blocks (as defined in an extension of the ANS Forth standard) acting like Linux' mmap. Strings are a little bit of a pain to deal with in Forth, so you'd rather avoid them where possible (in addition to the consideration that plain text data are inefficient). You'd rather use an hex editor or write visualization and manipulation tools for binary data rather than processing text strings. The fact that Colorforth uses a custom source format to be edited by a custom editor (the colors in the source code is not syntax highlighting, the colors are part of the "syntax") is symptomatic of this kind of approach. A condition/exception system would probably be in the category of "hooks" according to Moore. Stack underflow/overflow are not even an error condition in some of the chips he made that feature circular stacks. However, it is true that for casual Forth programmers like me, a stack underflow condition is usually the result of an error in the program. In a way, just like Haskell programs are "most certainly correct when they compile", Forth programs are most certainly correct if they don't stack-underflow (or just segfault because that's a typical result of messing up the return stack).

by delish 8y ago

agumonkey 8y ago

has moore written books or articles ?

dang 8y ago
There's this classic, at least: https://colorforth.github.io/POL.htm https://colorforth.github.io/POL.htm https://hn.algolia.com/?sort=byDate&dateRange=all&type=story&storyText=false&prefix=false&page=0&query=problem%20oriented%20language%20points%3E3 https://hn.algolia.com/?sort=byDate&dateRange=all&type=story...
- agumonkey 8y ago
  dank u
4thaccount 8y ago
Safari online has a lengthy interview with him that is an excerpt from a book with lots of interviews on programming Titans. I read the one from Moore every year and I don't even write Forth. It is simply that good and thought provoking.
- elisharobinson 8y ago
  yes I read it once and it genuinely is the stuff to start cults
  - 4thaccount 8y ago
    Haha, yes that is a good way to explain it. Moore isn't necessarily wrong, but I don't think he is 100% correct either. Not everybody is a software engineer who can spend all day writing code. There are a lot of folks who write shell scripts and the like who need to do talk to computers without getting into machine code and Forth. Does a lawyer need to know the machine? Sounds inefficient use of time.
- fizfaz 8y ago
  this one: https://www.oreilly.com/library/view/masterminds-of-programming/9780596801670/ch04.html https://www.oreilly.com/library/view/masterminds-of-programm... ? Very interesting interview indeed.

astrobe_ 8y ago

ColorForth is actually pretty much an image-based system. Moore observes that PCs have a lot more memory than he needs (indeed 1Mb is huge for a Forth system), so the image is loaded into memory and the memory is saved to disk. It should be mentioned that Forth is one of those languages that do configuration by editing the source code. This is probably the recommendable practice, instead of INI files or worse, XML (why write another parser when you already have one?). For really big data, binary format would probably be preferred (I actually have no experience in the area), with blocks (as defined in an extension of the ANS Forth standard) acting like Linux' mmap. Strings are a little bit of a pain to deal with in Forth, so you'd rather avoid them where possible (in addition to the consideration that plain text data are inefficient). You'd rather use an hex editor or write visualization and manipulation tools for binary data rather than processing text strings. The fact that Colorforth uses a custom source format to be edited by a custom editor (the colors in the source code is not syntax highlighting, the colors are part of the "syntax") is symptomatic of this kind of approach. A condition/exception system would probably be in the category of "hooks" according to Moore. Stack underflow/overflow are not even an error condition in some of the chips he made that feature circular stacks. However, it is true that for casual Forth programmers like me, a stack underflow condition is usually the result of an error in the program. In a way, just like Haskell programs are "most certainly correct when they compile", Forth programs are most certainly correct if they don't stack-underflow (or just segfault because that's a typical result of messing up the return stack).