[immibis]

Probably in a similar way to learning Haskell, assembly, Erlang, data-oriented design, 4k demo programming, or any other thing that is unconventional enough that your normal patterns don't work and you are forced to expand the set of ways you know how to program.

[7thaccount]

Not OP, but I would only partially agree with that statement. Sure, learning all those things is mind altering. If you only know Java or Python...Haskell is very unusual.

However, the Forth experience and reading about legends like Chuck Moore (at least for myself), just gave me this feeling that most of our problems come from software bloat and having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore. Such a system is ironically more efficient from a developer's perspective (at least until you run into weird bugs and edge cases) as developers just basically glue together libraries and only need surface level understanding to get something running. Another option might be to design your own hardware and then a simple forth system on top of that which exactly solves the problem and nothing else. The implementor would have laser level understanding of the design choices. Of course, there are other issues such as how to maintain such a unicorn, even if it is beautiful and elegant. Today, we have lovecraftian horrors with huge swaths of people working together to keep all the abstraction levels working together and hope there aren't any leftpad incidents.

[immibis]

Low level "machine sympathetic" programming is just one type. If you restrict yourself to it, you'll be no better than the programmer who's restricted to any other type. All these abstractions didn't spring out of nowhere - in many cases they make for very flexible software that is cheap to create. Go learn both ends. And the middle. And the weird outliers.

[7thaccount]

Agreed. I stated above that abstraction hell has its benefits. At the end of the day though you mainly are just slapping components together with that and not understanding how the problem truly works.

In my industry we do a lot of optimization and the standard technique is to not reinvent the wheel and to use a solver (e.g. Gurobi) where you give the silver your decision variables and constraints and have it quickly return the optimal decisions. This is great, but costs a lot of money (the best solvers are almost entirely commercial) and you treat a core part of your program entirely like a black box and you also have to fight things like the license manager and so on. Another option is not to create your own generic solver that solves all problems, but rather a solver that solves just your problem. The one company I know that does this has been enormously successful and their product is incredibly fast and lightweight with zero dependencies besides Windows (really cool). The only negative is that now the application is tightly connected to his own solver and they can't just switch it out easily with a different one like most people can. It's all a set of tradeoffs at the end of the day.

[fuzztester]

>having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore

s/infinite abstraction levels/Rube Goldberg contraptions/

[7thaccount]

Lol. Probably a more apt description.

[bitwize]

I really wish techies would stop whinging about "bloat".

All those abstractions are necessary in order to do software engineering of real-world systems at scale. Forth lets Chuck Moore put something together quickly in very little code, that serves Chuck Moore's needs adequately well, but... Chuck Moore isn't the average person, let alone the average developer. Chuck Moore doesn't need, for example, a file system; why have one if you can just memorize the sector numbers for everything on disk?

A lot of the "bloat" in modern computing consists of things necessary in order to make computers tractable for ordinary people. This is as true for things like Electron[0] as it is for C and conventional operating systems vs. Forth on bare metal. And if technology doesn't work for people, it doesn't work.

[0] Electron has enabled a Cambrian explosion of cross-platform apps by vastly reducing the time and effort it takes to develop such an app. Developer effort is often the costliest part of software; by that metric, Electron has probably saved billions of dollars, despite consuming hundreds of megabytes that would otherwise be wasted anyway.

[Teckla]

All those abstractions are necessary in order to do software engineering of real-world systems at scale.

No, they're not.

[nequo]

This is both vague and speculative though. Vague because you have made no specific claims that could be evaluated one way or the other. Speculative because you have said nothing about Forth.

You cannot make engineering decisions based on "it'll change how you program." There are several concrete examples of turning imperative code into pure monadic code that contains less boilerplate and is less noisy with Haskell's do notation. Exhaustiveness checking, encoding invariants in types, those all have good examples that one can read and agree or disagree with. Surely there are concrete examples that one can give about Forth too?

[skydhash]

It's metaphysical. Like learning a foreign language widen your perspective. It's a particular insight you gain about the act of programming that makes you realize that you've been boxing yourself to a very small imperative/oop space.

Writing C code feels like writing a rule book, writing java feels like designing a lego set, writing lisp feels like writing proof, writing prolog feels like writing puzzles. Writing forth feels like writing a dictionary, then after that you write a few sentences. They're different feeling, but forth is one of the most flexible as you can go up and down from the most basic units to the high level ones. As another comment has mentioned, you can program forth where the basic units are elements from another language, and construct a dsl/dictionary out of it. Then switch the basic units while retaining your business logic for a faster implementation without a full rewrite.

[immibis]

Not just the realization you were boxed into a space, but also knowledge of stuff inside a different box. The more boxes you have the ability to access, the better.

[saulpw]

The creator of Forth wrote this:

> I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. -- Chuck Moore

https://www.ultratechnology.com/moore4th.htm

You might appreciate other quotes from the above page.