▲ 225 points
back
41 comments
One thing Forth is great at is signal processing. This was kind of a revelation to me when I tried Paul Batchlor's Sporth, a Forth-style language specialized in audio processing.
Nowadays audio synths and effects are most commonly represented as interactive spaghetti diagrams connecting basic DSP blocks together into directed graphs determining the signal flow. To make a good audio programming language, the question then becomes: is there a nice textual representation for this kind of graph? And Forth is a great answer to that question.
I had so much fun with Sporth that I ported it to the browser and made an online playground for it: https://audiomasher.org/ with some examples: https://audiomasher.org/browse and a tutorial: https://audiomasher.org/learn
Creator of Sporth here. AudioMasher is a really cool project! Projects like this make me really glad I open sourced Sporth. It's really cool to see what sorts of things people will use it for. In addition to learning the API and porting it to the web (with no assistance from me), Pierre has also composed some very beautiful patches in Sporth using his AudioMasher tool. It is always easier to leave things as a "technical demo", so I appreciate the extra effort.
You kind learn more about Sporth here: https://pbat.ch/proj/sporth.html and the code can be downloaded here: https://www.github.com/paulbatchelor/sporth.git
Why not link AudioMasher from the Sport project page too?
I should, but I haven't gotten around to updating the page yet. I've been busy with other projects.
Very, very cool!
Little bit of feedback: it only plays when the tab has focus - is that a browser thing, or something could theoretically be overridden?
EDIT: Opening the tab in a separate window keeps the sound running even when alt-tabbing away
EDIT2: The interactive cook book environment are missing a previous and next link at the top/end of each chapter, clicking back and finding which chapter is next is a little bit tedious.
Thanks for the feedback! I roughly added some previous and next links as you suggested.
As for playing audio from a background tab, I believe browsers actually allow it, but for some reason, audio played though emscripten's APIs seems to stutter or stop when the tab is backgrounded. It might not be hard to fix, but I haven't really looked into it.
" is that a browser thing"
Unfortunately and thanks to many misusing auto-playing ads - it is. Sounds can only start playing if the tab is the active one.
As you point out, sounds can only start in foreground tabs, but the glitch here is that already-running audio is getting stopped when the user switches to another tab. So it's a bug in my code!
Ah yes, that does sound like a very valid reason to turn that off. At least the open-in-separate-window trick works around it.
This seems primarily about program design with Forth being the example language. And looking at it, it seems like between this view of design versus object-oriented design books versus, I-don't-know, functional design ideas, the main difference is what things are language-implemented versus what things exist conceptually but aren't directly supported/implemented by the language.
The thing about all this that I find interesting in describing these situations, design-theories are leveraging human language skills. The big thing is taking a customer's narrative of what they want to have accomplished and turning this into the exact, machine-implemented series of instruction. You are talking about a human-being using the language-facility to construct something exact. And well, I don't know if the structure of human-generated language for problem solving has been investigated that much by linguists but it would be interesting to see an investigation of this in relation to program design.
Let's also add a link to Loeliger's Threaded Interpretive Languages... https://archive.org/details/R.G.LoeligerThreadedInterpretive...
Yes! In 1981 my wife gave me Loeliger's book as a birthday gift, which led to Forth being the first language I implemented and worked with for pay! Excellent book (though the book's pseudocode has a couple of bugs .. I forget just where.)
The local water board paid me to write a records-management program, for which Forth was a good way to access machine-level stuff. The biggest obstacle came from British Telecom, where we wanted to push voice data from the water flow meters over phone lines, and BT took a very long bureaucratic time to decide whether that should be permitted as speech or data.
Oh wow! Thank you for linking that. I didn't know that it was on archive.org. That book was one of the ones that I left in Canada when I moved to Japan. I really regretted it! For anyone interested in the topic, I highly recommend reading it.
not a book, but a processor array by Chuck Moore:
GA144
https://www.youtube.com/watch?v=tb0_V7Tc5MU
more here https://www.youtube.com/results?search_query=greenarray
For those wanting an off-line copy: do yourself a favor and get the .djvu file. It's the smallest and ironically it has better quality images than the PDF.
Cannot thank you enough. Have been looking for an affordable copy for a long time.
Keep your eyes open, I paid less than $10 USD plus book rate shipping for my used, very good condition copy from a random seller on Amazon several years ago.
I have no idea why sellers are asking the prices they are.
Forth is the language that taught me (among other things) that its possible to break problems into pieces that are too small to understand the whole.
I'm not sure really what to call this other than something along the lines of can't see the forest for the trees. Its the opposite of having functions so large it takes hours to figure out what they do. In this case you have words that you can't figure out what they do for days because the call graphs step across 300 different modules and 10k other words all of which are like "update-pie-with-apples" and comprise two other words "dup pie, apple-pie-update" or something.
My experience with FORTH was similar, although you've put into words the problems I found with FORTH better than I could.
The original article is by Leo Brodie. I bought his book Starting FORTH (which is now available online[1]) shortly after reading a 1980 Byte Magazine article on FORTH.
It's not hard to implement FORTH. I found that R. G. Loeliger's book[2] Threaded Interpretive Languages: Their Design and Implementation allowed me to easily build my own FORTH inspired system.
[1] https://www.forth.com/starting-forth/
[2] https://www.amazon.com/Threaded-Interpretive-Languages-Desig...
That problem seems common in Smalltalk too. It's best described by this Adele Goldberg's quote: "In Smalltalk, everything happens somewhere else."
My HP 28s calcultor from 1988 (still got it, still works excellently) is programmed in a stack based, Forth + Lisp inspired hybrid language, that was lightyears ahead of all the concepts, programming languages that I had seen back then (Basic, Pascal, C). It was stack based. I could put data onto the stack and get it from there if needed. It had an excellent REPL. It was working with all kinds of data structures: complex numbers, lists, arrays, matrices. Also, everything was an object. And code could generate code, just like in Lisp.
Only when I learned about Mathematica I found something more powerful in 1988.
What makes me sad is that the latest and most capable calculator from HP (the HP Prime) seems to use something like Pascal. After 30 years they come up with something like Pascal? Instead of what they had in 1988?
Back then they used a variant of Lisp: RPL (Reverse Polish Lisp)
I'm too young for those calculators, unfortunately. But I did pick up a SwissMicros DM42 a while ago. I love it, but I haven't had enough time to properly play with it.
I loved Forth and Chuck Moore's 10x philosophy.
I went from Forth to Ruby, from a notorious write-only language to a language that's a joy to read & write.
I occasionally wonder about the possibility of a forth/ruby hybrid, stack-based interpreter/compiler with the readability of ruby.
Ruby's OO is based on message passing. A message-passing OO is something that could potentially be implemented elegantly in Forth.
Snigl [0] leans more towards multiple dispatch and Lisp than OO and Ruby, but I figured it might me interesting anyway if you've been thinking along those lines.
There were lots of OO Forth implementations back in the day. I used one to make a star field animation system for a planetarium when I was in University. The main thing I would say, though, is that OO tends to encourage you to put things on the heap. This goes away from one of the nicest aspects of Forth where you are encouraged to play on the stack. I went from Forth to C++ and quickly embraced RAII, partially thanks to my experience with Forth. I've often thought we're missing an abstraction here -- something that helps you with cohesion like OO does, but which doesn't force you away from the really efficient and elegant approach of something like Forth.
Look at MOPS (well, I guess iMOPS or PowerMops these days). It was a Forth inspired object oriented language http://powermops.org/
This sounds really interesting (disclaimer: I love both these languages), but isn’t a main advantage of Forth that it compiles to something that is really f*ing fast, and wouldn’t that hybrid potentially give that up?
The reason it's fast is brutal simplicity. But it's a spectrum, with dogmatic Forth close to one end; the more you can keep things simple, the more raw speed you get for free.
The approach I'm using in Snigl [0] is to start with Forth and add more elaborate features as optional/gradual layers. As long as you don't use variables and closures you get to enjoy more raw speed etc.
Reading this book (in 1984 or so) was one of the formative moments for me. Especially the idea that as software developers we should strive for the simplest most elegant solution and we could iterate our designs to get there.
The cartoons are brilliant - I often think of the universal processor (p82) "word, food, data" when designing something that doesn't have a clear purpose.
If you're interested in Forth, I created a WASM implementation some time ago: https://github.com/stefano/wasm-forth
The main limitation is the interaction with the JS world, which is limited to textual I/O, but it's enough to run an interactive REPL.
About the time of this book I transitioned from computer engineering and assembler programming into software engineering. I was lucky to stumble upon Thinking Forth. Swallowed it. Gave me invaluable insight.
(Another important transition stepping stone was Programming Languages - Design and Implementation by Terence Pratt.)
I tried to learn Fourth when I was a kid of about 14. There was an implementation for the TI-99/4A, which I had. But I never grokked it. I am guessing the manuals and other examples assumed knowledge I didn't have. Haven't gone back to it since.
Fortunately I didn’t have access to any Forth implementation when I read Thinking Forth so I could get full credit from the reading undisturbed by any practicing.
Hmmm, the TI-99/4A. Any chance you made Mr. Bojangles dance? (I read that BASIC manual cover to cover)
100 CALL CHAR(96, "995A3C3C3C3C2221")
110 CALL CHAR(97, "1899FF3C3C3C4484")It's a shame Forth is so tricky to find. I learned Prolog and Lisp in school, but Forth was never even mentioned. It would make an excellent introduction to programming if you ask me.
Once I got my hands on a tutorial, I quickly realized it was the perfect foundation for the language [0] I've been designing in my mind.
From 2015: https://news.ycombinator.com/item?id=9842557
From 2011: https://news.ycombinator.com/item?id=3389286
I've never had a chance to play with Forth, but Starting Forth was one of the first good computer books I ever read.
My first job after grad school was writing code for Harris Semiconductors' RTX-2000 processor (native Forth execution) as an apps engineer. Showing people how to morph the compiler, and toggle between assembly & Forth on the fly, blew people's minds. Good times.
I read this book over and over when I was a kid.