Levels of code in Forth programming (2002)
ultratechnology.com
ultratechnology.com
One example is a simple Forth word (macro) to convert 3 bytes into one 32 bit number integrates well into code for dealing with an adc chip.
However I wouldn’t want to write while applications in Forth as dealing with stack swaps becomes annoying. Still writing your own Forth is pretty fun too. I did mine by basing C compiler XMacros which made porting to an Itsy M4 trivial (about 3-4 of work) [1].
Still there’s a few Forth’s for Arduino’s, Itsy’s, ESP’s [2] which are really fun as they enable repl style interactive programming with hardware while still being blindingly fast!
1: https://github.com/elcritch/forthwith 2: https://github.com/zeroflag/punyforth
However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.
Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have.
That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.
The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using.
Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it.
To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.
"High level" means details abstracted away and solved so you don't have to think about them. Our CPUs understand only the most primitive of instructions; the purpose of all software is to climb the ladder of abstraction, from a multiplication routine abstracting over repeated addition, to "Alexa, set an alarm for 8 AM." To write things yourself is the very essence of descending to a lower level.
Abstraction comes at the price of loss of fidelity, yes - Alexa might not ask you to specify exactly what form your alarm will take - but the benefits are a vastly increased power/effort ratio. It's worth it, because most of the time you don't care exactly how a task is done - you just care that it IS done. And - mostly - your needs are not that special.
Frankly, sharing information on how to do things so that others can build upon them is the only reason we have technology at all. Perhaps you've read "I, Pencil"? With a lifetime of effort and study, you would struggle to create a single pencil drawing from "scratch". Chuck Moore's supposedly astonishing productivity notwithstanding, I notice that all of the software I actually use is a heavily layered tower of abstraction (and, curiously, none of it is written by Chuck Moore). It appears that by and large the choice is between layered, multi-author code - and no code at all.
Perhaps you never saw the images from the Philae space probe? Because that's an RTX2010 that powers it, one of Chuck Moore's designs.
Maybe you don't use Moore's software directly, but you never know when it has been used for you [1].
[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...
See also: Emacs, the ultimate customizer's editor, easily shapeable to your particular needs -- and currently losing badly to Visual Studio Code which is only readily customized with configuration options and third-party packages. When you need to pair or mob, having a common toolset and vocabulary beats having a special-snowflake environment.
It would be awesome to get back to first principles, but modern systems try to do so much that I wonder how practical it would be to reinvent them — and I would how practical it is to say, ‘well, don’t do that then.’
I'm inclined to say that, e.g., the modern browser is a cautionary tale that complements the Chuck Moore approach to things: By forever piling thing on top of thing in an evolutionary way, you end up with a system that ultimately feels more and more cobbled together, and less and less like it ever had any sort of an intelligent designer. Perhaps the lesson is that it can be worthwhile to occasionally stop, take a real look at what things you really do need, aggressively discard the ones you don't, and properly re-engineer and re-build the system.
Obviously there are issues of interoperating with the rest of the world to consider there, and Moore has made a career of scrupulously avoiding such encumbrances. But a nerd can dream.
Once unstoppable sectors, like aerospace (to mix comparisons) began to reverse and decline in the early 70s. No one really saw it coming. I can't think if one publicly known or credible person called it in 1969 shortly after the moon landing, at least on record. Oversupply of engineers in the US and the West became a thing. And engineering still suffers here because of aerospace's decline. Forth began to lose steam around then, right? Forth, hardware and Cold War (barriers) politics are inextricably linked, perhaps. And then GNU/Linux and BSD saw its high-collaboration paradigm birthed around that time. Nixon/Kissenger talks with closed China began around then too, and now relations are breaking down with a more open China today.
Look how Lua scripting came about not terribly so long ago. Some parallels. Brazilian trade barriers. Now half believe Huawei is evil. Cross-hardware story may be cracking. Many believe Google is evil. Open software may be cracking. And there are rifts between US, EU, and China on how to regulate the internet. A new Cold War may be brewing. It's a nerds nightmare.
If anyone can tie in distributed ledger and specialized AI coder productivity tools, or something to counter this argument or round it out, that would be awesome.
EDIT: I was mistaken. Forth caught on with personal computer hobbyists in the 1980s, per Wikipedia. However, as a career or industry,slow downs with NASA and Cold War spending seemed to take some wind out of Forth's sails. I've noted that lot of that type of work was what paid people to write Forth. And the open-source paradigm with C/C++ and GNU Linux was even more limiting, I believe.
Couldn’t say exactly, but it’d probably look something like this:
https://en.wikipedia.org/wiki/Display_PostScript
:)
People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.
65 emit
vs
putchar(65);
vs
(print 'A')
It's all the same to me.
I realize the problem isn't Forth, some people (such as the writer for example) are capable of pulling amazing feats for such a primitive tool.
But as a result, the programming languages [0] I've designed since have all been part Forth and part Common Lisp.
Some lessons simply did not age well.... Even in world of today's microcontrollers, which often have kilobytes of RAM and very different CPU styles, people still write mostly hardware abstracted code.
But it's a miniature of the same tragedy as Node.js applications that consume ten times the resources needed just because it allows people to do more with more... In a logarithmic way.
A couple of questions:
1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming?
2. What is “sourceless programming”? Where is a good place to learn more about it?
2. Sourceless programming was something Chuck Moore tried for a while where he designed a machine that was the virtual machine he wanted to program, implemented it in hardware, and then edited byte code directly for it. Later he stepped back and went to colorForth, which has the source/binary separation we are all accustomed to.
> but it won't resemble what most people in computing expect from a browser or photo editor.
In the sense that an end user would interact with some low level API primitives, rather than a full GUI? I’d love more examples or metaphors, or maybe a link where I could learn more.
For instance, OKAD (chip design and simulation CAD package) is 500 lines of colorForth. Although it includes all sorts of fancy tools, he also applied his ruthless minimalism to the requirements.
If it were a complex application it wouldn't be very forthy would it? Factor the problem instead of trying to factor a preconceived solution.
> 2. What is “sourceless programming”? Where is a good place to learn more about it?
Sourceless programming was used in Okad a vlsi design tool written by Chuck Moore.
http://www.ultratechnology.com/mofe16.htm
Brad Nelson also experimented with sourceless forth:
https://docs.google.com/presentation/d/1wL2eqf7eHGEybsK0C4MU...
Is the author exaggerating here, or did they actually succeed at writing something that could pass whatever Turing test level his boss could offer?
If it's the latter, what then-current knowledge would they likely have sourced?
Even then I don't agree that portability/abstraction isn't important - it's got the potential to be an extremely reductionist position. Instead I'd argue it's incredibly expensive and should be treated as such.
Using a cross-platform framework isn't incredibly expensive in time or performance cost. It's done by one-person projects and large businesses alike. There's issues but that's way overstating it.
Then, there were 4GL's like Lansa and Windev that made it easier to do than creating non-portable, native applications. Those weren't used for performance-sensitive code, though. Mostly business apps.
The right number of abstractions is very powerful. Too many any you'll sink under the weight of them.
This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head.
This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews.
This means that you have trouble sharing code with yourself in your next project.
You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine.
I personally think that deep optimization is something that the machine should do, they are better than humans at this most of the time. And humans should do want machines currently can't.
You're still coding against a machine, and you still have to spend time learning the vicissitudes of that machine. But you also have the impedance mismatch between the virtual machine you're developing against and the physical machines you intend the software to run on. All software abstractions are, to some extent, leaky.
People usually insist that software should be modular, so that you don't have to have millions of lines of code in your head when making a local change. That's what drove the procedural evolution and later the OOP evolution.
So if you're a good boy/girl/etc. you write your million-LOCs PC application as modules that are manageable for (ideally) a single person. Then you need an extra programmer to glue the modules together.
> This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews.
Where does Forth prohibit peer reviews and pair programming? If you have a bus factor of 1, it is because you don't want to pay the price of increasing it. It has nothing to do with Forth; plenty of projects in super-high hyper-readable projects have a bus factor of 1.
> This means that you have trouble sharing code with yourself in your next project.
Not really. It's easier to copy/paste/hack Forth code. The code is more compact for various reasons: point-free style makes it less verbose, you tend to factor more intensively and you code exactly what you need.
> You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine.
No, that's the other way. When you code e.g. for a little-endian, two's complement CPU then you don't have to worry about big-endian and sign magnitude. You are actually also optimizing programmer's cycles too.
Being tightly coupled to the machine is what embedded programming really is about. Embedded programming is often about writing esoteric values at occult addresses in order to bang out bits on an SPI bus. Running a Python program on Debian on a rPI is not really embedded programming.
[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...