[HN Gopher] As you learn Forth, it learns from you (1981)
___________________________________________________________________
As you learn Forth, it learns from you (1981)
Author : hggh
Score : 86 points
Date : 2024-06-20 08:05 UTC (2 days ago)
(HTM) web link (jupiter-ace.co.uk)
(TXT) w3m dump (jupiter-ace.co.uk)
| asguy wrote:
| 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.
|
| https://thinking-forth.sourceforge.net is worth reading, even if
| you have no desire to ever program any Forth.
| nequo wrote:
| What are your main lessons from Forth for API design? Is it
| something you could summarize?
| saulpw wrote:
| 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.
| nequo wrote:
| 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.
| immibis wrote:
| 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.
| nequo wrote:
| 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 wrote:
| 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.
| 7thaccount wrote:
| 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.
| fuzztester wrote:
| >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 wrote:
| Lol. Probably a more apt description.
| samatman wrote:
| Several literary careers have been made on summarizing the
| main takeaways from LSD.
| immibis wrote:
| If several literary careers have been made summarizing
| it, and it still is not adequately summarized, that
| proves the point.
| klyrs wrote:
| 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.
| LudwigNagasena wrote:
| API design is something relatively concrete though. One can
| provide examples of pre-Forth and post-Forth design.
| diffxx wrote:
| 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."
| 7thaccount wrote:
| 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.
| detourdog wrote:
| Here is a link to the byte magazine issue that inspired the above
| article. https://archive.org/details/byte-
| magazine-1980-08/page/n2/mo...
| ralphc wrote:
| I'm a vintage computer collector and the Jupiter Ace would be the
| holy grail of my collection. Has anyone seen one in real life?
| tengwar2 wrote:
| Do you have any OpenBoot/OpenFirmware machines like the Sun4 or
| early SPARCstations? I was wondering what they were like as
| pure Forth machines.
| shrubble wrote:
| Mitch Bradley was the author of a great deal of that Forth;
| his CForth is on GitHub :
| https://github.com/MitchBradley/cforth
|
| (It might be easier than finding an old Sun machine)
| adrianmonk wrote:
| I'm not a Forth programmer, but I used to be a Sun sysadmin.
| From what I recall, the Forth code on a SPARCstation is
| interpreted and pretty slow.
|
| These docs support that: https://docs.oracle.com/cd/E19455-01
| /816-1177-10/816-1177-10...
|
| The system supports FCode, which is processor-independent
| byte code. This allows expansion devices (like a card or
| peripheral) to bring with them their own platform-independent
| device drivers, which is pretty cool. So you could make a
| disk controller card and then any system that you plug it
| into could boot off it, no matter the CPU architecture.
|
| Anyway, the point is, since it was mainly used for booting
| and diagnostics, I don't think they put much effort into
| performance. For it to be an actually good Forth environment,
| I think you'd want to have some way to run Forth programs as
| native code, either by adding the option to JIT the FCode
| instead of interpreting it or by adding a compiler that
| compiles Forth source to native.
|
| Also, I believe the old PowerPC Macs (like G3, G4, and G5)
| used Open Firmware, so if you wanted this Forth experience,
| you have that option in addition to Sun workstations.
| tengwar2 wrote:
| The G4 did indeed support Open Firmware: I had an MDD.
| paulb73 wrote:
| At my local fine-fare (80s uk superstore) they sold computers
| in a 'concession' stand.
|
| They sold Jupiter Aces. Wish I had the money back then to get
| one!
| rwmj wrote:
| There's one in the Cambridge computer museum:
| https://www.computinghistory.org.uk/det/1332/Jupiter-Ace/
|
| Steve Vickers, one of the founders of Jupiter Cantab, was my
| university lecturer back in the 90s. He taught a very obscure
| course in mathematical structures, and in a sense was both the
| first and last (a decade and a half later) to teach me computer
| science. Previous comments:
| https://news.ycombinator.com/item?id=23760382
| https://news.ycombinator.com/item?id=26375986
| renewedrebecca wrote:
| I've seen one once at a HamFest or something.
|
| There are kits out there to make your own though:
|
| https://www.tfw8b.com/product/minstrel-4d-turbo-jupiter-ace-...
| olvn wrote:
| several on ebay, here's one:
|
| https://www.ebay.com/itm/115272079823?itmmeta=01J10WB15JY1KF...
| rhelz wrote:
| When I read old articles like this, I start wondering what the
| story was behind all those companies mentioned. Stackworks Forth,
| Alan Ashley Assembler. You almost never hear of a company which
| is still around.
|
| Was it actually possible, back then, to make a living selling
| Forth for CP/M computers? Or Assemblers? Did Stackworks have an
| office, with a jaded-looking middle-aged secretary who put out
| her cigarettes in an ashtray on her desk, before she picked up
| when the phone rang? A glad-handling salesman who came back to
| the office every few weeks before going out to sell?
|
| I don't think it has been possible to sell a compiler which isn't
| a loss-leader in a bundle for what, 30 years?
|
| Or were these side hustles? Alan Ashley, was his day job being a
| math teacher or something, and he did this to round out his
| budget?
|
| The industry was a heck of a lot smaller back then, but these old
| articles mention way more different companies. Seems like before
| all these behemoth monopolies there was a lot more air to
| breathe.
| diffxx wrote:
| > I don't think it has been possible to sell a compiler which
| isn't a loss-leader in a bundle for what, 30 years?
|
| I agree and personally feel that this is unfortunate and that
| we are in some ways imprisoned using mediocre to bad compilers
| by our collective refusal to pay for better ones.
| convolvatron wrote:
| i agree that we should have a better model as a society to
| produce things like compilers, but having a direct retail
| relationship with a closed source provider was pretty nasty.
|
| because of tooling, large code bases, and weak
| standardization they had a huge amount of lockin. and only a
| single narrow funnel in which to address deficiencies.
|
| and while certainly on a lower tier than EDA seats, werent
| super cheap. they usually had limited platform support. while
| they did optimize better for their targets, otherwise they
| were poorer systems than gcc, with all its warts.
| tengwar2 wrote:
| It would depend on the generation of CP/M. CP/M 1.0 and 1.1 had
| Gary Kildall dealing with it when he came off duty from a
| nuclear submarine. CBASIC (from Compiler Systems aka Gordon
| Eubanks) dated from the same period and was also a part time
| activity for a nuclear sailor. CP/M 3.0 was mature - you had a
| lot of professional compiler companies like Prospero, Borland,
| FTL, and HiSoft, but by that stage. Some of them, like Prospero
| and HiSoft dated back to the CP/M 2.2 era, and I got the
| impression that they had three or four staff.
| rhelz wrote:
| Thanks for the view back into history. I was kinda under the
| impression that this side-hustle thing was new. Apparently
| its not only old, but was an essential part of the
| technological progress we've had since then.
| db48x wrote:
| Commoditize your complement. If you sell operating systems, it
| pays to make compilers a commodity so that everyone can write
| programs for your operating system. This is true even if you
| aren't "selling" the OS in the traditional sense of the word.
|
| The alternative is a world where developer tools are expensive,
| and thus only the rich can program their own computer.
| cgh wrote:
| The first developer tool I ever bought was Develop-64, an
| assembler for the Commodore 64 by a company called French Silk
| software. I was around thirteen years old and I figured this
| was some big professional company. Much later, I realised it
| was basically one guy and there was no way this was a full-time
| job. I think these tiny shops were pretty common back then,
| basically hobbyists trying to monetise their creations.
| aquariusDue wrote:
| For people interested in Forth I think this is a nice intro:
| https://ratfactor.com/forth/the_programming_language_that_wr...
___________________________________________________________________
(page generated 2024-06-22 23:01 UTC)