Programming Forth caused the most massive change in my programming mindset (the LSD of programming languages). Even more so than Lisp. Thinking of the rapid rise of the base language to the problem domain (i.e. it's a DSL construction kit) opened my eyes to how to design useful and extensible APIs.
Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving.
Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code.
Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model.
Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access.
To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description.
Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."
I didn't use FORTH long, maybe for a year, (back when 8080s were The Thing), but I remember my first reaction (after learning about Reverse Polish) to it: it was like using assembly language, but without the pain.
(Moved to 6502; don't recall having a version for that.)
I think a lot of recent Forths (at least outside of the embedded space) have been written in C or C++ rather than assembly now that the processors are incredibly complicated. Of course, you can write forth on anything including the JVM or in Python...etc.
Factor might be a counterexample if one considers it a Forth, the VM is in part implemented in C++: https://github.com/factor/factor
I think it's portability and ease of development rather than CPU architecture complexity that makes someone pick C/C++ over assembly when implementing a Forth system. Because the Forth won't need much of the assembly language or obscure CPU instructions, the complexity of the architecture won't really matter to whoever is implementing it.
JonesForth is popular for teaching, but most implemented Forths people talk about on r/forth seem to only be written in ASM if the target is embedded. Portability, simplicity, and the complexity of modern processors just seem to make ASM less of a good option these days. I'm no forth expert though...mainly a lurker.
Reddit has issues, but searching for topic + "reddit" is one of the only remaining ways to make Google not a piece of steaming ad-infested garbage. For example, if you want to find the best budget rollerblades, Google will happily serve you page after page of auto-generated garbage. On reddit you can find real enthusiasts giving recommendations.
Also ...ycombinator isn't exactly just a community run bulletin board either. Although HN not being ad infested is absolutely amazing. Also the simple design.
Yeah, I'm not going to the Internet and ask about things I'd like to buy, I'm going to ask my friends or take a chance on second hand stuff. A SearxNG instance that hardly ever serves up Google responses and Wikipedia are my main search engines outside systems I control.
Sure, I'm not really using this as a web forum, I'm not here for the community.
It sounds like you almost want to live off grid completely (I'm exaggerating a bit based on your response - it's not meant to be condescending either btw...hard to convey tone online).
I certainly get that itch sometimes after the person at the coffee shop asks me if I've downloaded the app for the 50th time. No, I don't want 45 apps on my phone just so I can get a tiny discount or a free coffee each year.
Regarding the comment on asking friends. I think that has some value, but it assumes that you know someone for everything you're interested in or that they have the same kind of purchasing power or ideas as you. The Internet can be helpful there if you're interested in the best bang for the buck for a newbie, or the best product period once you've spent more time.
If push comes to shove I certainly want to be prepared to do so, but no, it's not something I yearn for. I have many other reasons to try and keep the large US IT-companies at arms length, among them the criminality of US law with regards to data protection rights.
However, most weekends I travel to the forest with my family and we spend some time walking, cooking and hanging out in a distinctly analog setting.
No, it doesn't. It assumes they might know someone who knows someone that has valuable input. Doesn't require that they have direct experience either, it's usually enough that they have adjacent experience. And then there's books, when _I find myself to be the unique snowflake in my social network there's always someone who wrote a good book or more on the topic. By now my physical library is quite large and covers a large portion of occidental modernity, both fiction and the sciences.
The Internet is nice and all, and sometimes there's good advice in contemporary web forums, but it's also pretty young and lacks both the depth and width of the last few centuries of dead tree storage. These days people also throw second hand books after you if you say you're interested, or they charge a euro at most unless it's something collectors might find valuable.
I quite enjoy computers and computer networks, though. It's mostly the social and entertainment industrial side of it that I find unsatisfying.
They just said it was like the LSD of programming languages. Your question is kind of like "What are your main takeaways from LSD? Can you summarize?" which realllly misses the point.
I don’t think so. There are many ways to describe how a mind altering experience with LSD would change how you relate to yourself and your environment. I am curious how Forth changed parent’s approach to programming.
You can describe LSD, or a novel programming paradigm, just as well as you can describe Beethoven's 5th symphony in words.
The amount of lost bits of information makes the explanation totally worthless, even though you technically can explain it. The point is it's a waste of time. You won't understand LSD, Beethoven or Forth until you have tried them.
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.
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.
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.
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.
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.
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?
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.
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.
> 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
In my experience, the value of a trip isn't what you take away from it; it's the things that you can't take with you. Nobody really wants to see a whole slideshow of your vacation photos; it'll never compare to being there.
There is a large contingent of people that claim to know about X because they read a good book on it, which is ludicrous nonsense. Indeed the most unique things of any experience is what you cannot put into words.
Language is a very lossy compression algorithm, and some concepts aren't even computable in the first place (i.e feeling and emotions)
These take much less board space (especially when considering locking holes) and work much better than Tag-Connect with and especially without the locking holes (those pin lock things are available, but they suck)- I mean they are easy to insert and stay in place, very nice for firmware people to use. They seem ambiguous about which side of the board you can plug them into, but they are actually (barely) polarized.
The main disadvantage is the expense of the connector and expense of castellated holes on the edge of your board. If you can afford the BOM cost use a surface mount 10-pin 50-mil header, or if you can afford the footprint space and some holes, use the SKEDD connector.
BTW, for SPI-flash chips: an option is to use a socket for them.
You can stir-fry on an induction cooker just like you can pull a caravan with a Fiat 500 (a small car for those who don't know the type), you just need a smaller caravan and travel at a slower pace. You might want to avoid those steep passes. Don't try to overtake, keep off the road when the wind is above 5 Bf. and avoid motorways.
I have a lot of experience in this what with me being Dutch - where Nasi Goreng (Indonesian-Chinese stir-fried rice) is somewhat of a national fare - and having cooked on:
- gas: one of the best options for stir-frying, you can use any type of wok/wadjang you want. Use the largest burner you can find so you can fry larger batches at the same time while keeping the heat up.
- resistance-electric (whether cast-iron or coil or ceramic or halogen): not what I'd choose for this, you need a flat-bottom pan which does not warp under high heat -> cast iron or heavy aluminium -> slow to respond. Generally not enough power for keeping up the heat while stir-frying larger batches.
- induction-electric: also needs a flat-bottom pan which needs to be ferromagnetic, many if not most domestic induction cookers lack the required power (4 kW or above) for a good result. Avoid 2 kW indiction cookers without 'boost' function as those are simply too weak for even small batches
- wood-burning stove with removable rings: together with gas the best option since you can sink the wok/wadjang down into the fire by removing enough rings and stoke up the fire to whatever heat you require. I can easily stir-fry 8 portions in a single batch in a large wok on the wood burner (nominal power 4.5 kW but it can go higher if needed).
So, gas or wood, take your pick. If you have to choose electric and you really want to be able to stir-fry you'll want to get an induction wok cooker.
This is exactly the problem. Have /you/ contemplated what would happen if you applied that reasoning to any other group (e.g. Jews, Blacks, Oracle employees)?
Anybody who derives their identity from their nomenclature quadruple of skin-color-religion-politics-sex sucks.
Don’t have a problem with white people, Christians, conservatives (the old kind who put America first and didn’t want to reduce the rights of others) and men. Combine all those? Clearly a stunted individual that’s deeply disliked and they know it. Like what kind of man is so lacking in self-assured manliness that they need to include "male" in their identifier? What type of Christian needs to shout loudly near the temple about their faith? Etc.
Have you ever met anybody reasonable who described themselves as a name quad that includes their skin color, sex, politics and religion? I haven’t. I keep trying to come up with a name quad that wouldn't sound super annoying in a hypothetical Twitter bio and I can't find a single combination that doesn't sound like a crazy person.
X is a better experience for me now, than it was before Elon's takeover. If I don't want to see something, I don't look at. If I don't want to allow someone to interact with me, I block them. If I believe something is bullshit/a lie, I participate in the community notes.
I don't need a nanny to pre-chew my information for me.
Yes. It's there to keep things unspecified. If you leave the job, you're not paid out unused vacation. If you use too much, you run afoul of an unspoken rule
