4 ms·

Here is a gem from this gem of a book - surely one of the best descriptions ever of what are now called DSLs: Forth programming consists of extending the root

by gruseom 15y ago

Here is a gem from this gem of a book - surely one of the best descriptions ever of what are now called DSLs: Forth programming consists of extending the root language toward the application, providing new commands that can be used to describe the problem at hand. Programming languages designed especially for particular applications such as robotics, inventory control, statistics, etc., are known as “application-oriented languages.” Forth is a programming environment for creating application-oriented languages. (That last sentence may be the most succinct description of Forth that you’ll find.) In fact, you shouldn’t write any serious application in Forth; as a language it’s simply not powerful enough. What you should do is write your own language in Forth (lexicons) to model your understanding of the problem, in which you can elegantly describe its solution.

jdpage 15y ago
I've heard similar descriptions of LISP, actually.
- RodgerTheGreat 15y ago
  They are actually very much alike. Personally I prefer Forth for having less "magic"- a basic Forth kernel is much smaller and simpler than a bare-bones Lisp system. Postfix notation also seems a more elegant (if initially less familiar) solution to a homoiconic language than Lisp's nested parentheses.
  - gruseom 15y ago
    Not entirely on-topic, but since you're our local Forth enthusiast: can you tell us anything about Moore's recent (say, last 10 years) chip and language designs? I look at the GreenArrays and ColorForth stuff and feel like Bob Dylan's Mr. Jones: there's something happening here and I don't know what it is. My spidey sense tells me that it's disruptive enough to represent a major opportunity of some kind. But Spidey could be wrong.
    - RodgerTheGreat 15y ago
      Well, I can do my best to summarize what I understand. Moore has always intended Forth as sort of a stone-soup language- a collection of ideas and techniques that can be taken from and recombined to suit different purposes and programmers. There were several efforts to standardize Forth and build it out into a language with formalized, extensive libraries (ANS-Forth, mainly), but they are largely antithetical to Moore's attitude of continual experimentation and refinement. The current state of the art with ColorForth is pretty alien in comparison with ANS-Forth. It's an exercise in subtractive design. The most obvious change is that the ColorForth environment tokenizes input as it is typed. Tokens can have some metadata associated with them which is reflected in their color. ColorForth generally uses colors to eliminate the need for the "mode switching" words in a normal Forth- comments, [] "compile-time blocks" and colon definitions, for example. By pre-tokenizing source code, virtually all the string manipulation required in the compiler is removed and getting rid of mode-switching words makes source code more compact visually. The F18 core and the GA4/GA144 chips based around it are incredible machines. In a nutshell, an F18 is a tiny Forth machine with 64 18-bit words of RAM which can be packed with up to four instructions apiece. The GA144 has 144 F18 cores which communicate with their neighbors via a blocking handshake mechanism. Thanks to both to Chuck's novel approach to chip layout and simulation and the fact that there is no global clock, the GA144 uses very little power compared to other CPUs and microcontrollers with comparable compute capacity, despite the fact that the GA144 uses essentially antique fab technology. With no changes to the design and the latest fabrication techniques you could (theoretically) get an order of magnitude more cores on the same sized die and drive power consumption down further. Programming the beasts is another matter. Since each core has very limited space for code, programs tend to have the character of functional pipelines in which each core takes a few arguments from neighbors, possibly stores a small amount of local state and computes simple functions to pass down the chain. I think that if any language other than Forth could be compiled for the machines it might be an array processing language like APL. Even if the resource constraints weren't difficult, simply getting your program deployed onto the grid is tricky, since you can only directly talk to cores on the edges- you have to write code that "walks" through the grid of F18s, pushing code into neighbors and triggering them to do the same, establishing communication channels and then tearing them down as they are replaced by the final application code. So where does this put us? GreenArrays has extremely energy-efficient, highly scalable supercomputers-on-a-chip, but programming them is very difficult and requires incredible attention to detail. There are a number of PhDs in the making solving the new problems in compiler technology this type of architecture raises. If GreenArrays was open to the idea (and they seem to be), a more portable software simulator of the GA144 and more accessible development tools (ie, tools that do not require booting a Windows VM and learning a new keyboard layout on top of the ColorForth language) could be a huge shot in the arm. If a killer-app emerges that can take advantage of the power consumption and the particular style of parallelism the chips are capable of, these designs could change everything, but the jury's still out. ...Does that help at all?
- WalterGR 15y ago
  I've heard similar descriptions of LISP, actually. Actually, Paul Graham said something similar about Lisp. "...In Lisp, you don't just write your program down toward the language, you also build the language up toward your program..." http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html

by gruseom 15y ago

jdpage 15y ago

I've heard similar descriptions of LISP, actually.

RodgerTheGreat 15y ago
They are actually very much alike. Personally I prefer Forth for having less "magic"- a basic Forth kernel is much smaller and simpler than a bare-bones Lisp system. Postfix notation also seems a more elegant (if initially less familiar) solution to a homoiconic language than Lisp's nested parentheses.
- gruseom 15y ago
  Not entirely on-topic, but since you're our local Forth enthusiast: can you tell us anything about Moore's recent (say, last 10 years) chip and language designs? I look at the GreenArrays and ColorForth stuff and feel like Bob Dylan's Mr. Jones: there's something happening here and I don't know what it is. My spidey sense tells me that it's disruptive enough to represent a major opportunity of some kind. But Spidey could be wrong.
  - RodgerTheGreat 15y ago
    Well, I can do my best to summarize what I understand. Moore has always intended Forth as sort of a stone-soup language- a collection of ideas and techniques that can be taken from and recombined to suit different purposes and programmers. There were several efforts to standardize Forth and build it out into a language with formalized, extensive libraries (ANS-Forth, mainly), but they are largely antithetical to Moore's attitude of continual experimentation and refinement. The current state of the art with ColorForth is pretty alien in comparison with ANS-Forth. It's an exercise in subtractive design. The most obvious change is that the ColorForth environment tokenizes input as it is typed. Tokens can have some metadata associated with them which is reflected in their color. ColorForth generally uses colors to eliminate the need for the "mode switching" words in a normal Forth- comments, [] "compile-time blocks" and colon definitions, for example. By pre-tokenizing source code, virtually all the string manipulation required in the compiler is removed and getting rid of mode-switching words makes source code more compact visually. The F18 core and the GA4/GA144 chips based around it are incredible machines. In a nutshell, an F18 is a tiny Forth machine with 64 18-bit words of RAM which can be packed with up to four instructions apiece. The GA144 has 144 F18 cores which communicate with their neighbors via a blocking handshake mechanism. Thanks to both to Chuck's novel approach to chip layout and simulation and the fact that there is no global clock, the GA144 uses very little power compared to other CPUs and microcontrollers with comparable compute capacity, despite the fact that the GA144 uses essentially antique fab technology. With no changes to the design and the latest fabrication techniques you could (theoretically) get an order of magnitude more cores on the same sized die and drive power consumption down further. Programming the beasts is another matter. Since each core has very limited space for code, programs tend to have the character of functional pipelines in which each core takes a few arguments from neighbors, possibly stores a small amount of local state and computes simple functions to pass down the chain. I think that if any language other than Forth could be compiled for the machines it might be an array processing language like APL. Even if the resource constraints weren't difficult, simply getting your program deployed onto the grid is tricky, since you can only directly talk to cores on the edges- you have to write code that "walks" through the grid of F18s, pushing code into neighbors and triggering them to do the same, establishing communication channels and then tearing them down as they are replaced by the final application code. So where does this put us? GreenArrays has extremely energy-efficient, highly scalable supercomputers-on-a-chip, but programming them is very difficult and requires incredible attention to detail. There are a number of PhDs in the making solving the new problems in compiler technology this type of architecture raises. If GreenArrays was open to the idea (and they seem to be), a more portable software simulator of the GA144 and more accessible development tools (ie, tools that do not require booting a Windows VM and learning a new keyboard layout on top of the ColorForth language) could be a huge shot in the arm. If a killer-app emerges that can take advantage of the power consumption and the particular style of parallelism the chips are capable of, these designs could change everything, but the jury's still out. ...Does that help at all?
WalterGR 15y ago
I've heard similar descriptions of LISP, actually. Actually, Paul Graham said something similar about Lisp. "...In Lisp, you don't just write your program down toward the language, you also build the language up toward your program..." http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html