Add Remove

excerpt Which leads us to compactness, not only on the syntactic level, but on the abstraction level. The inability to understand software has led to a proliferation of layers, trying to shield the programmer from details that he ought not know about. Operating systems (agglomerating their own abstractions) live below runtime libraries, which in turn are the base for application level libraries that lay the ground for language-level abstractions, an ever growing tower of abstraction for abstractions sake, or better: the admission of our lack of knowledge about what is actually executing. This is considered a good thing nowadays ("ignorance is strength"), but it actually gives you nothing but disadvantages. First, the low-level interfaces to the functionality of operating systems, binary file formats or direct hardware access aren't as arcane and forbidding as they are commonly seen. They are only badly documented (if at all), or contain undocumented extensions specific to particular systems or applications. Or they are just shoddily designed by hardware engineers that have decided that the "nice" part of the interface can be done by the software guys. on 12/18/2019, 8:30:57 AM

excerpt Doing everything yourself frees you from having to understand mediocre abstractions, bloated libraries full of useless stuff, and the bugs that necessarily infest code that was written for universal use by people who have not (and can not) account for the universality of applications that may possibly use that code. Reuse has become a dogma, even though there are first signs that it is carefully questioned. That emphasis on reuse just demonstrates the industrial drive to produce assets, to create lasting value (call it codebases or intellectual property). It's an illusion that denies the fact of software rot. What you reuse of a library is usually just a tiny part, but you pay for all the unused or pointless functionality and particularly for the bugs that are not yours. on 12/18/2019, 8:34:48 AM

excerpt And this is an important point: to do everything yourself gives you a superior understanding of the software you produce. It allows you to modify it at every level to your needs. It makes it possible to be able to account for every byte (if you do it right) in your binary. When was the last time you were able to do that? So to program in Forth means, you invariably implement it yourself, and don't worry about "standards". As the old saying goes: "If you have seen one Forth - then you have seen one Forth." And that's totally ok. on 12/18/2019, 8:35:18 AM

excerpt Forth is a language for solving practical problems. It is a language for turning LEDs on and off, for moving motors, for writing pixels into a frame buffer, for writing device drivers, for bringing up something runnable on single board computers. It is also a language for searching, sorting and manipulating data and implementing the gruntwork that will always be in one or the other way a job like that. If you want to parse XML or JSON, it is surely possible, but it won't make you happy. It is not a language for writing meaningless abstractions on top of other meaningless abstractions, or for writing a library that solves a specific problem in the most possible general way, using that fancy algorithm or data format that happens to be hip today. It is an excellent tool for writing virtual machines, assemblers, or custom data formats. Once you are willing to simplify the problem to the point where it is natural to implement it in Forth, while at the same time you are just able to fulfil the intended goal, you are on the right path. It requires out-of-the-box thinking and a lot of thought, but rewards you with something that stands a better chance of not being just another pile of code that barely works, quickly rots, or ends up being a liability that you regret having ever written and that has grown to a point where rewriting or replacing it becomes harder and harder. on 12/18/2019, 8:36:46 AM

excerpt Writing "good" Forth code is very hard, or at least what I consider good Forth code, which may be different from what others consider good. Forth has been called a "write only language", but only because it requires an additional effort to simplify your code to a point where everything becomes obvious. This is an art, it is a moment of transcendence, which I don't claim to have ever reached, but sometimes I get a glimpse of it, an inkling of the fact that if I would work very hard on this, it will become so simple, so heavily factored, using such obvious and clear names that everything just falls into place. It is this moment that programmers experience every once in a while, where a short, simple piece of code just does what it is supposed to do, without any extra baggage, easily understandable. To achieve it in Forth is much harder, it may require more time, many rewrites, but the results are even more satisfying, as the result is smaller, much simpler, fully self-contained and not burdened by code that you can not trust. When you forget about that urge of productivity, which has become the moloch we sacrifice our children to, you may be able to achieve that particular thing that is called quality, elegance, art. It may take a lifetime, you may never reach that far, but still you should strive for it. on 12/18/2019, 8:38:39 AM

excerpt Or you remain a cog in the machine, developing on absurdly convoluted "software stacks", using inadequate and brittle languages, connect barely matching interfaces to only small parts of too many bloated libraries, using insanely sophisticated tools of incomprehensble complexity and trot on, asking yourself why everything sucks and why the last time you actually enjoyed programming and were you could be genuinely and deservedly proud on what you accomplished, was when you were a kid... on 12/18/2019, 8:39:15 AM

via Thoughts on Forth Programming on 12/19/2019, 6:52:21 AM