My first summer job while at University was with a small company in the west of England, Micross (http://www.microssautomation.com/index.php), writing industrial laundry control software, in Forth, targeting Windows NT. We used the MPE Forth system (http://www.mpeforth.com/), which was highly extensible - when you needed to add more of the Win32 API, you'd edit various files that shipped with the package and recompile the entire thing :)
The company had standardized on Forth throughout their operation, so regardless of the hardware you were using, anything from a PIC-based counting system to the Windows servers, you only needed to know one language to understand the code. Clever stuff.
I have never used Forth but it seems like a really language. It combines very high level constructs with the ability to be embedded in systems that barely have an operating system.
Now, if they could solve the problem that every Forth system is customized by the Forth programmer and so the entire language lacks standards, it would be amazing. Also, if you could add enough syntactic sugar to make it look sort-of like C or perl, you would have "the next big thing".
Take a look at http://factorcode.org/ - it's very Forth-like, but has a lot of modern constructs. It's very active and the (core) libraries are quite stable.
I've been toying with Factor for about a week. It's been an enjoyable experience, as both the language itself and the included development environment are extremely well designed.
Having never played with Forth-like languages before, I'm finding writing even the simplest algorithms strains my mind -- in a good way, though. It's mind expanding in the same way Lisp was the first time.
I doubt that Factor is the next big thing, but I think that for smart people it's one of the most fascinating things around right now. Zed Shaw, for example, is a big fan:
Yeah - Forth and Forth-likes encourage an extremely modular, concise, expressive form of coding... When you add macros it gets some of that meta-programming feel that comes with Lisp.
All that said - I've never found it 100% natural, but (perhaps paradoxically) on the other hand I'm usually pleased with the results.
It is shown compared to the analogous code in C++ and Lisp.
My Factor version could probably be improved. In fact, I just now realized that I could have factored out the two final calls to <node> into a single call.
The sequel, _Thinking Forth_ (http://thinking-forth.sourceforge.net/) is available free online, in PDF form. (After going out of print, it was scanned and OCR'd with the author's blessing...quite a compliment.) It's less about how to program with Forth, and more about things Forth taught Leo Brodie about designing programs for maintainability, (re)factoring, and the like.
7 comments
[ 3.1 ms ] story [ 26.8 ms ] threadThe company had standardized on Forth throughout their operation, so regardless of the hardware you were using, anything from a PIC-based counting system to the Windows servers, you only needed to know one language to understand the code. Clever stuff.
Now, if they could solve the problem that every Forth system is customized by the Forth programmer and so the entire language lacks standards, it would be amazing. Also, if you could add enough syntactic sugar to make it look sort-of like C or perl, you would have "the next big thing".
Having never played with Forth-like languages before, I'm finding writing even the simplest algorithms strains my mind -- in a good way, though. It's mind expanding in the same way Lisp was the first time.
I doubt that Factor is the next big thing, but I think that for smart people it's one of the most fascinating things around right now. Zed Shaw, for example, is a big fan:
http://blog.cusec.net/2009/01/16/zed-shaw-on-factor/
All that said - I've never found it 100% natural, but (perhaps paradoxically) on the other hand I'm usually pleased with the results.
http://img301.imageshack.us/my.php?image=addtobinarytreescre...
It is shown compared to the analogous code in C++ and Lisp.
My Factor version could probably be improved. In fact, I just now realized that I could have factored out the two final calls to <node> into a single call.