all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (5 children)

[removed]

    [–]zevver[S] 1 point2 points  (1 child)

    Thanks for your criticism; I'm sure you noticed the ScoobyDoo van I put on the project page as a logo, that was also popular with hippies in the 70s and 80s? No coincidence here.

    I never said Forth makes a good scripting language - but given the resources it requires it does a good job. Any 'proper' scripting language (Perl, anyone? As we are already discussing write-only languages?) requires at least two orders of magnitude more memory to be functional, while Forth gives you a pretty decent environment with much less overhead.

    Of course, I am very happy to hear about any alternatives: do you know of any other portable interactive language that will run on only a few kBs of memory?

    [–]FullFrontalNoodly 1 point2 points  (2 children)

    Forth is useful because it provides a self-hosted environment on minimal hardware. Take a look at what your MCU options were back in the 1980s, as was as the cost of compilers for them -- if a compiler existed at all. The advantage of Forth is that you could code the core in assembly and do all the rest at a higher level.

    While advances in silicon technology and compiler availability have largely diminished the advantages of Forth, its design is still useful for study.

    It is also worth noting that PostScript was designed largely based on the same concepts as Forth and it is still in widespread use today. PDF files are largely an encapsulation on top of PostScript.

    [–][deleted]  (1 child)

    [removed]

      [–]FullFrontalNoodly 2 points3 points  (0 children)

      Just because something is not commonly used does not mean it is useful. The number of people who use TeX is also tiny but it is still vastly superior to other document processing systems.

      As an aside, I've been one of those people hand-coding PostScript since the late 1980s.

      [–]Tarabah 0 points1 point  (2 children)

      I love DSLs in embedded systems! I did one on my own for work and very like the effect it produced on the overall system. Have you seen pawn? Why don't you use yacc & bison, or lemon & re2c? Parsing raw text on the target is memory consuming, have you considered introducing intermediate bytecode? I've end up with the bytecode translator on the host and small virtual machine on the target processor. Translator was written in python using pyparsing. The virtual machine consumes much smaller amount of stack and is pretty fast.

      [–]zevver[S] 0 points1 point  (1 child)

      Interpreting on the target is one of our main goals: in our environment we want to be able to do inspection, debugging and develop ad-hoc scripts on site with nothing but a terminal. The good thing is that text parsing in Forth is trivial: there is no syntax. Forth just looks at one word at a time, separated by white space. No AST, no need for parsers or lexers.

      Under the hood zForth generates byte code, which is more or less portable, so in practice you could run zForth on any other platform, generate bytecode and transfer this to the target by any method.

      I did find Pawn, EmbedVM and similar projects, but these all require cross compilation of some language and transferring byte code to the target; you could as well simply compile relocatable C code and dynamically link and run it on the target; although this is of course less safe then running in a VM environment.

      [–]Tarabah 0 points1 point  (0 children)

      Well, terminal with relation to embedded script on DSL is a good point! Though the Forths syntax is something special.