I think one often overlooked reason why languages other than Forth, Lisp, et. al. far and away took off is because these other languages are, frankly, much easier to get working sooner.

In the specific case of Forth, so much of the inner mechanics depends not only on correct operation but even upon correct *design*, that despite its tiny, tiny size, it's easy to use facade, it's actually *significantly difficult* to get an environment working.

Forth, in particular, cannot be described as a stack of software layers that play nice relative to each other through clean interfaces.

Don't get me wrong -- the stuff you write *IN* Forth can be written this way, but Forth *itself* cannot be.

As a result, fewer people try, which leads to reduced exposure, thus reduced competition, thus reduced magazine/website exposure, which leads to the perception that it's a niche/toy/etc. language when in fact the opposite is true.

Languages like C, et. al. all have a nice, clean structure. Even BASIC can be written as a set of libraries, with a top-level coordinating layer that binds them together in a cohesive user environment.

This makes them easier to port (either from scratch or from existing code), which increases their popularity, which increases media exposure, which gives the impression it's a workhorse language.

Additionally, the clean, modular structure of the components of these interpreters and compilers lends them to greater R&D (e.g., better register allocators, or adoption of SSA to improve code generation, et. al.).

This leads to more people willing to experiment with new techniques in compilation and/or interpretation. With languages like Forth (specifically), if you want to change how the system works, you have to rebuild the world from scratch. Better hope your Forth is written in itself.

Anyway, these are just some thoughts I've had, as I'm sitting here hacking on DX-Forth, really wishing I were done with it already.

Finishing block I/O is proving hard not because the code is complex, but because the debugging is harder than I would like it to be. There comes a time when I just want the damn thing to be done already. I have other ideas I want to work on!

@vertigo Hmm, I'm not following your argument. Why is it not possible to write libraries in Forth?

@akkartik I said you could.

It's Forth *itself* (the interpreter/compiler/runtime environment as a whole) that does not lend itself to modular development.

@vertigo Oh, I thought that was just the "Additionally" part of your argument. I was thrown by "Languages like C, et. al. all have a nice, clean structure. Even BASIC can be written as a set of libraries.."

Why can't Forth compilers be modular? The Factor toolchain has a pretty nice decomposition into vocabularies. Does it have some feature Forth lacks?

@akkartik Forth doesn't lend itself to modular development because there are too many pieces of the language with circular dependencies.

One example: The Forth REPL depends on QUIT being defined, but QUIT itself *invokes* the REPL.

Block I/O is pretty easy to add in isolation, but the text interpreter and/or compiler have to be made explicitly aware of its existence if you want to LOAD code, etc.

@vertigo Ah, I see.

On the other hand, if it's a small codebase, maybe decomposition isn't so important?

I guess I'm wondering what sort of operation you're trying to perform that had you missing Basic 😁

@akkartik My concerns are with implementation; the decomposability of software for easier testing, especially automated testing.

@akkartik In the past, I'd written a BASIC-like language for my Kestrel-2 which was surprisingly complete, in a matter of a few days. Forth historically takes me several weeks in comparison to come to a modicum of completion.

@akkartik After finishing block I/O (which I expect to complete by end of this week; possibly end of today even), I still have to write the Forth compiler.

Note that I've been hacking on this language since November. ;)

@vertigo Fascinating to hear this perspective. The concern about testability particularly resonates.

I'm really interested to play with what you're building when it becomes available.

@akkartik This version of Forth is not going to be generally available. I mean, it'll be uploaded to the Kestrel-2DX repository, but it's just a dev tool, really.

The real Forth for the Kestrel-3 will be a port of eForth 1.0, a real, honest to goodness, 64-bit Forth.

I think these will be the last Forths I'll write though (at least in raw assembler). I think, going forward, I'm going to go back to writing Forth in Forth itself.

@akkartik If you're interested in reviewing the code that completes the block I/O access words, here's a link to the combined diff of my branch:

chiselapp.com/user/kc5tja/repo

@akkartik As of this posting, I just need to link it against the BIOS to actually transfer data (right now, it just prints messages to the screen telling me what it -would- do if it actually talked to BIOS).

@vertigo on a tangent re BIOS: how do you recommend replacing proprietary firmware and the monstrosity that is UEFI?

I realize the question may not be applicable to your custom hardware, but perhaps you have some advice? Say I want to build an OS in straight-up Assembly. What would be the easiest way to load it from disk and start running it? Easiest meaning least amount of code, without using any proprietary firmware or device drivers either. (Hardware recommendations are a valid answer.)

@akkartik I don't have an answer to your question. First, you will need to turn off *all* security-related boot options. Second, I absolutely would use the GPT (the only good thing to come from UEFI); the old-fashioned partition tables are a disaster.

@akkartik But beyond that, I don't have any good answers; as far as I can tell, all modern PC hardware is proprietary now.

Follow

@akkartik To a large extent, this is what motivates the Kestrel -- if I can't hack on my PC with off-the-shelf resources (either in a book somewhere or online), especially without fear of bricking my hardware, then I have no choice but to roll my own.

Today's PCs are appliances. Thanks Intel, thanks Microsoft.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!