That tells you how to do graphics hacks and so on. I had fun with that on my OLPC. I optimized the Forth console to scroll using hardware BLIT (much faster than CPU copy of the framebuffer) and I ported Squeak Smalltalk to run directly on OFW using hardware graphics primitives e.g. for the mouse pointer.
I tried reading "Thinking Forth", but never got why it is praised so much. Looks like a bunch of war stories from 80s from veterans who discovered some basics of encapsulation in need to handle Forth programs complexity.
It's really cool to see all of this interest in Forth. I think when I learned Forth, it made me a significantly better developer over all; it's also an awesome base for DSLs and really a fascinating paradigm.
Honest question, wouldn't you just write a lexer with yacc/bison for a DSL? How does a full programming language act as a base for a DSL, which is usually more limited than a programming language?
Well for a lot of devices I've worked with, you can shoehorn Forth places that most (if not all) other languages short of assembler can not go (Forth is _really_ lightweight). Forth was designed with DSL's in mind (Forth has "vocabulary" which is targeted specifically at this); the language usually comes with a basic syntax and some core primitives built in, but features a really profound ability to define new primitives, even things like "if" that most languages have built-in and have no facilities for constructing variants. You might liken it to macros in Lisp.
I guess the other huge nice thing abort Forth for DSLs is that it is (unlike assembler or C), an interactive language, even on the most stripped down platforms (like bare bones $0.50 8-bit MCU stripped down), and still encourages the sort of REPL experimentation typically only seen in much much higher level languages. All of this comes at a big price though, in that the caliber of developer required to wield Forth in a sane manner tends to be very high.
A typical use case for Forth to launch from bare metal (more like bare silicon) into the application on embedded systems or as the bootstrap mechanism/BIOS for a more advanced OS on a larger, perhaps desktop, system. A Forth console over a serial port can provide a user with tons of low and high level access to a system. I built a 12 processor "parallel" robotics controller back in the '80's using a bunch of Rockwell R65F11 Forth processors (6502's with Forth in ROM).
> Honest question, wouldn't you just write a lexer with yacc/bison for a DSL?
Perhaps this article[1] can help answer the question (BTW, the title of the page belies its applicability). Check out Figure-1 specifically.
> How does a full programming language act as a base for a DSL, which is usually more limited than a programming language?
IMHO, this is what makes Forth both beautiful and mind bending, as Forth is a "full programming language" in which programs/systems written in it are expressed as a DSL defining the system itself. If that sounded recursive, then you're well on your way to grokking Forth :-).
The kernel for FORTH is crazy small. IIRC it's not unusual to shoe horn it into 2K. When people talk about writing DSLs in FORTH, I think what they are really saying is writing an API based on the FORTH kernel. So the DSL is really FORTH, but just with your API. Granted changing how words are compiled and executed is pretty much standard fare for a FORTH programmer, so you can make it work however you want.
FORTH is a bit like smalltalk in that you usually work in an interactive environment and save images. FORTH code compiles down to essentially a jump table and so it is also really, really efficient, space wise. You can decompile code easily and modify it in your image.
If you were trying to write a control language for some small embedded device, it would be ideal. If you were trying to write a DSL for configuring a build system (or something like that) it would be less nice ;-)
My first few paying jobs (when I was in university) was writing FORTH code, but that's a very long time ago ;-) I'm still quite nostalgic about it even though I've forgotten almost everythng I once knew.
the avantage of using a full programming language as a base for your DSL is that you don't have to deal with some of the "simpler" things.
Your base language already has variable assignment, loops, recursion? Great, you don't have to deal with that. Type checking? Wonderful, don't have to go read up on type inference
Yup, me too. I'd recommend that anyone with a serious interest in programming should learn Forth (and write a Forth system from scratch): I'll probably never use it in anger, but it made me think about programming in a very different way.
(Also, curiously, gave me an increased respect for K&R C, which allows minimalist programming in a way that ANSI C doesn't.)
I liked programming in PostScript more than Forth because of all the additional non-graphic things it had. Look at the Blue Book ("The PostScript® Language Tutorial and Cookbook") http://partners.adobe.com/public/developer/ps/sdk/sample/ind... for some examples.
Many years ago I did a project with a lisp back-end, a front end in PostScript (NeWS/HyperNeWS) and C code gluing the two together - it made me appreciate than an interactive PostScript environment is surprisingly lisp-like.
Edit: This has made me wonder about a NeWS-like server sitting on top of OpenGL and using an interactive PostScript like language.....
I started my career with a Turbo C complier, a PostScript printer, and a government database written in FoxBase. I learned a lot of PostScript programming in order to generate the report we needed. I later got NeXTSTEP 3.3 which made interacting with PostScript a true joy.
I have often thought a NeWS-like server would be a fine replacement for a lot of web stuff.
I'll echo one of the other comments. I've also done robotics with Forth and used it extensively for about ten years. I do enjoy the language. That said, I don't see much justification for it today for general usage.
As early as 15 years ago a number of our embedded products using 8 bit processors were programmed in assembler and/or Forth. This quickly became challenging in terms of product maintenance (assembler) and finding qualified experienced developers (assembler and Forth). I found myself in the difficult position, as CEO, of not being able to remove these responsibilities from my desk. And so we ported all of our code from assembler/Forth to C. In that process we improved nearly every technical and business metric. The port took months but it was well worth it.
I still think every programmer needs to start with assembler wrangling processor architecture internals "by hand", move on to Forth (or a TIL), then Lisp and C. I am sometimes in horror to come across programmers for whom every solution requires bloated, inefficient object oriented code.
Not much. Forth is from an era when it was hard to program small microcontrollers and the tools for doing so were expensive. Today, everybody cross-compiles to microcontrollers.
I've done robotics programming in Forth. I do not expect to use it again.
My understanding is that the link between Arduino and Processing is solely in the IDE. I don't think the two share any common ground beyond just the fact that Java (which Processing is a very thin layer on top of) is similar to C (which Arduino is a very thin layer on top of.)
I wouldn't go as far as saying Postscript is a dialect of Forth, influenced by or perhaps "Forth-like" (i.e. stack-based), but certainly not a dialect.
Yes, IIRC Intel's Itanium (IA64) architecture used firmware and drivers in Forth (instead of machine code) so you could use the hardware on any CPU architecture.
No, Itanium specifically eschewed OpenFirmware (IEEE1275-1994, which is ANS Forth based) in favor of inventing EFI, which would develop into UEFI later.
Among the reasons: no interest in bytecode (UEFI now has EBC), no ACPI support (IEEE1275 predates ACPI by a decade, Intel didn't bother), protecting Intel's "Independent" BIOS Vendors from having to compete in an existing market (there were several OpenFirmware vendors).
Most OF implementations are now open source, we collected them at www.openfirmware.info.
You used to be able to boot up with Command+O+F and get a Forth prompt. (Although I have a hazy recollection that on some models they didn't include a screen terminal, so you couldn't interact with it...)
Is there any resource for learning how to implement Forth? It would be really cool to have a book that showed you how to determine your machine's capabilities and gave example of how you could implement it from scratch starting on Windows, Mac, Linux and onto other systems like Raspberry Pi, TI calculators and than how it is implemented on more esoteric systems like satellites.
it doesn't go into specifically exploiting your machine but the infamous Jones Forth is ~1000 lines of assembly and ~a billion lines of comment explaining the assembly and this gets you into a functioning Forth, then it starts writing everything else in forth, including IF, WHILE, DO UNTIL... which shows how you can use the parsing words to write new language features.
Jupiter Ace (a 8-bit microcomputer from the 80's) used its own dialect of Forth instead of BASIC, and there's lots of files and documents at http://www.jupiter-ace.co.uk
There was a Forth debug/service terminal included in an electronic typewriter / typing tutor device from the 80's with an integrated CRT display. So an educated guess is that its software was also written in Forth. It was made between 1981 and 1987 and I think it was a golf ball-style printer, so if anyone have an idea as to the make and model, that would be great.
Question for the Forth folks in this thread. Does Forth support loadable code modules?
Here's the problem I'm trying to solve (still in the tinkering stage). I have an embedded processor with small on-board SRAM but huge external address space and a NAND flash. Can't add external RAM.
http://www.atmel.com/tools/ATSAM4S-XPRO.aspx
The traditional FORTH "overlay" is to use FORGET. You create a dummy word to serve as a marker, like ": OVERLAY ;" or something, then later, you can "FORGET OVERLAY" and load in new code to replace it. This only affects the dictionary -- the stack and heap (if any) aren't touched.
I can imagine implementing a direct threaded Forth, but instead of code addresses being memory locations, code addresses are a virtual address; DOCOL and NEXT swap in the appropriate segment of code into memory where necessary.
This could possibly be optimised in a subroutine threaded Forth so code within each "page" wouldn't have to verify loaded segments.
Implementing a dictionary insertion/optimization routine that packs related routines together to minimise swapping would be an interesting problem, and would probably most easily not be done live but ahead-of-time instead.
In short: Yes, Forth can support the paging you desire if implemented that way.
Jim the minimal Tcl dialect that your link points to is a pretty interesting animal, notable in its own right. I believe its one of the few Tcls to have lambda and tail call elimination. Its author would be a familiar figure to HN readers but perhaps associated with a different tool he wrote, redis. I for one knew about Jim and knew about Redis but made the connection that they were written by the same person much later.
Forth will might attract a different pool of candidates. That might be a good thing if the idea of programming in Forth excites more people than programing in TCL does. And my unsupported by data gut suggests that Forth is more likely to excite people than TCL.
Forth seems to have one thing in common with Lisp: a small dedicated following that believe it's the way forward and considerably easier to learn, despite never really having taken off.
I suspect this is something to do with different ways of conceptualising programs.
I haven't written a Forth program that I didn't write better and faster than the equivalent in C. But writing it in Forth was so much more fun. I think that's where part of the followers dedication comes from. Forth is like making jewelery, C is like laying bricks.
Jewelers don't build skyscrapers.
A friend of mine who programmed solely in Forth (and who taught me just about everything I know about the language) quipped that 'C is such a great language'. That was his way of saying he considered C to be bloated compared to Forth.
They're different branches of computing history. There are few that consider it the 'way forward' as far as the mainstream is concerned, but the fans tend to consider it an underexplored model for one reason or another.
See also oberon, smalltalk, eiffel for more language communities of that kind (the jury is still undecided where haskell ends up); os/2, plan9, l4 when it comes to operating systems/kernels; 6502, m68k, mill for Instruction Set Architectures; (and so on)
Every now and then, us non-mainstreamers tend to sound a bit preachy when we get an audience, I grant that :-)
Forth have, literally, "taken off" far further than pretty much anything else. Many spacecraft in our Solar system are run by forth, the most notable recent example being Philae: https://en.wikipedia.org/wiki/RTX2010
Not at all. I have developed in both languages. Forth is almost bare metal, between Assembler and C. Lisp is a high level language. Its abstraction level can be pushed way beyond any other language. DSL creation is much easier in Lisp than in Forth.
1 - http://www.openfirmware.info/Forth/FCode
2 - http://www.ebay.com/sch/items/?_nkw=olpc+laptop&_sacat=&_ex_...