11 ms·

Forth: The programming language that writes itself

• deleted 1y ago
  [deleted]
• behnamoh 1y ago
  Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that are "dumbed down" seem to absolutely dominate our world (Python, Ruby, JS, etc.)
  • JonChesterfield 1y ago
    They scale extremely effectively to large problems solved by a team size of one, maybe two. The story goes that changing the language to fit how you're thinking about the problem is obstructive the rest of the people thinking about the same problem. I'm pretty sure this story is nonsense. Popular though.
  • mcdonje 1y ago
    It kinda happened with markup languages. HTML, SVG, and some other domain specific markup languages are all XML, which is a subset of SGML. The thing there is those DSLs have their own specs. Coding is a social activity. Reading code is hard. When there are multiple ways of doing things, it's extra hard. People want to have relatively standardized ways of doing things so they can share code and reason about it easier. If there's a lisp or racket or a forth that's defined as a DSL, it might take off if it's standardized and it's the best solution for the domain.
    • gldrk 1y ago
      HTML uses a ton of SGML features not part of XML (sometimes erroneously though to be non-standard ‘tag soup’, not to mention self-closing tags). You need either a specialized parser or an SGML processor + DTD.
      • shawn_w 1y ago
        Wasn't HTML4 the last one defined as a SGML DTD? 5 and on is its own beast. (rip XHTML)
        • gldrk 1y ago
          You are right. There is a third-party DTD that should be mostly compatible (https://sgmljs.sgml.net/docs/html5.html https://sgmljs.sgml.net/docs/html5.html). In reality, HTML4 was never implemented to the letter by user agents, because people do things like putting -- inside comments.
  • tarkin2 1y ago
    One simpler explanation: in forth you are forced to keep the stack, and modifications to the stack, in your short term memory, albeit only really three numbers in most cases. Whereas with C et al you simply look down the page at the variables, far less taxing on your short term memory. Well-written and designed high-level forth words often transcend that and tend to be, quite literally, readable however, in a way that is incredibly rare to see in C et al. Of course the argument is that other programmers shouldn't be expected to see the problem in the way the original problem solver did.
    • rpcope1 1y ago
      This is probably why you see things like locals get used a lot as modern Forth programs grow. It doesn't have to be brutal early days Chuck Moore genius programs, but I guess you start getting away from the original ethos.
      • tarkin2 1y ago
        I think even with locals you're still mentally dealing with a few items on the stack in each word usually. But, yes, locals do help you from passing around items from word to word: you see the usage of the local far easier than you see the location of the stack elements.
  • lukan 1y ago
    What I heard is with Forth, basically no 2 environments are alike, but highly customized, meaning every forth programmer creates his own language in the end for his custom needs. So collaborating is a bit hard like this. The only serious forth programmer that I know, lives alone in the woods doing his things. So from a aesthetic point of view, I really like the language, but for getting things done, especially in a collaborative way? But who knows, maybe someone will write the right tools for that to change?
    • coliveira 1y ago
      This is not a real issue, because the same thing can be said about C. No two C projects are the same, each has its own set of libraries, macros, types, etc. I think the main problem is that Forth systems don't have a standard way of creating interfaces like C and other languages have. So the diversity of environments becomes a big issue because it's difficult to combine libraries from different sources.
      • andoando 1y ago
        I think it goes beyond that no, because you can do meta programming with Forth
      • jstimpfle 1y ago
        That's not right. C coders have no problem at all diving right into most other C codebases.
    • anta40 1y ago
      I think like C, there's standard/ANS Forth. But most likely lots of those Forth coders implement their own which don't necessarily conform to the standard.
    • veltas 1y ago
      Have you tried collaborating with Forth? There's a lot of documented history of people doing so in industry when it was actually used, and more recently I've usually found Forth codebases approachable and easy to follow. Personally I think this is the pay-off for writing the code in the first place because Forth is very difficult to write in a clear way, if you actually manage to do it you've probably made it very clear to follow because otherwise it's hard to finish your project and make it work at all.
  • saghm 1y ago
    I don't think "power" is really that helpful a metric in determining how useful a programming language is. If you think of programming from the standpoint of trying to specify the program you want out of all of the possibly programs you could write, one of the most helpful things a programming language can do is eliminate programs that you don't want by making them impossible to write. From that standpoint, constraints are a feature, not a drawback.
    • zovirl 1y ago
      And at the extremes, too much power makes a tool less useful. I don’t drive an F1 car to work, I don’t plant tulips with an excavator, I don’t use a sledgehammer when hanging a picture. Those tools are all too powerful for the job.
      • tsegratis 1y ago
        planting flowers? trowel planting foundations? excavator once you specify "the job", the best tool is "the solution" to that job only. anything else is excess complexity however if "the job" is unspecified, power is inverse to the length of "the solution" so is constraint of power bad? -- a fascinating question just like music can be created by both additive and subtractive synthesis; every line of code creates both a feature and a constraint on the final program in which case power can be thought of as the ability to constrain...
        • tsegratis 1y ago
          that is quite wild... it implies expressivity is the ability to constrain it implies drawing on a page, or more broadly, every choice we make, is in equal parts a creative and destructive act so maybe life, or human flourishing is choosing the restrictions that increase freedom of choice? it's so meta it's almost oxymoronic; concretely: we imprison people to maximize freedom; or, we punish children with the aim of setting them free from punishment this is the same as the walk from law into grace found in Christian ethics maybe the ultimate programming language then, provides the maximal step down that path, and this is also the most useful definition of "power" i.e. place on people those restrictions that increase their ability to choose
  • rpcope1 1y ago
    I worked at a place that had a big Forth codebase that was doing something mission critical. It was really neat and cool once you finally got it, and probably hundreds or maybe thousands of people had touched it, worked on it and learned it, but the ramp was pretty brutal for your average developer and thus someone decided it would be better to build the same thing over with a shitty almost-C-but-not-quite interpreted language. It certainly made it easier for more people to understand and build, even if the solution was less elegant.
    • kragen 1y ago
      That sounds interesting! Do you have any tips for us on how to use Forth effectively? What was the codebase?
      • rpcope1 1y ago
        Honestly, when I write forth now, which is usually for embedded targets, I've got a customized version of zforth that I've grafted some stuff like locals into. If it's a small program, it's better to not be afraid of things like globals, and just spend at least twice as much time factoring, writing comments and thinking than writing. It's important to read other people's Forth code and try to understand, as there's a zen and style that looks very different than how you'd write something like Java. It's freeing and enlightening once it clicks, but you have to fight a ton of the way you think about "normal" code. As far as the codebase, I probably shouldn't say too much (may it's been long enough now, but Idk), but all I'll say is that was a important part of things at a certain disk drive manufacturer.
        • kragen 1y ago
          That makes a lot of sense! Thanks! What were the most common mistakes you saw people new to Forth making? Being afraid of global variables is one of them, I infer.
  • kragen 1y ago
    I think those other languages have real advantages you aren't seeing. —·— The other day akkartik wrote an implementation of the program Knuth used to introduce literate programming to the CACM readers: https://basiclang.solarpunk.au/d/7-don-knuths-original-literate-programming-example-in-lua https://basiclang.solarpunk.au/d/7-don-knuths-original-liter... It just tells you the top N words by frequency in its input (default N=100) with words of the same frequency ordered alphabetically and all words converted to lowercase. Knuth's version was about 7 pages of Pascal, maybe 3 pages without comments. It took akkartik 50 lines of idiomatic, simple Lua. I tried doing it in Perl; it was 6 lines, or 13 without relying on any of the questionable Perl shorthands. Idiomatic and readable Perl would be somewhere in between. #!/usr/bin/perl -w use strict; my $n = @ARGV > 1 ? pop @ARGV : 100; my %freq; while (my $line = <>) { for my $w ($line =~ /(\w+)/g) { $freq{(lc $w)}++; } } for my $w (sort { $freq{$b} <=> $freq{$a} || $a cmp $b } keys %freq) { print "$w\t$freq{$w}\n"; last unless --$n; } I think Python, Ruby, or JS would be about the same. Then I tried writing a Common Lisp version. Opening a file, iterating over lines, hashing words and getting 0 as default, and sorting are all reasonably easy in CL, but splitting a line into words is a whole project on its own. And getting a command-line argument requires implementation-specific facilities that aren't standardized by CL! At least string-downcase exists. It was a lark, so I didn't finish. (In Forth you'd almost have to write something equivalent to Knuth's Pascal, because it doesn't come with even hash tables and case conversion.) My experience with Smalltalk is more limited but similar. You can do anything you want in it, it's super flexible, the tooling is great, but almost everything requires you to just write quite a bit more code than you would in Perl, Python, Ruby, JS, etc. And that means you have more bugs, so it takes you longer. And it doesn't really want to talk to the rest of the world—you can forget about calling a Squeak method from the Unix command line. Smalltalk and CL have native code compilers available, which ought to be a performance advantage over things like Perl. Often enough, though, it's not. Part of the problem is that their compilers don't produce highly performant code, but they certainly ought to beat a dumb bytecode interpreter, right? Well, maybe not if the program's hot loop is inside a regular expression match or Numpy array operation. And a decent native code compiler (GCC, HotSpot, LuaJIT, the Golang compilers, even ocamlopt) will beat any CL or Smalltalk compiler I have tried by a large margin. This is a shame because a lot of the extra hassle in Smalltalk and CL seems to be aimed at efficiency. (Scheme might actually deliver the hoped-for efficiency in the form of Chez, but not Chicken. But Chicken can build executables and easily call C. Still, you'd need more code to solve this problem in Scheme than in Lua, much less Ruby.) —·— One of the key design principles of the WWW was the "principle of least power", which says that you should do each job with the least expressive language that you can. So the URL is a very stupid language, just some literal character strings glued together with delimiters. HTML is slightly less stupid, but you still can't program in it; you can only mark up documents. HTTP messages are similarly unexpressive. As much as possible of the Web is built out of these very limited languages, with only small parts being written in programming languages, where these limited DSLs can't do the job. Lisp, Smalltalk, and Forth people tend to think this is a bad thing, because it makes some things—important things—unnecessarily hard to write. Alan Kay has frequently deplored the WWW being built this way. He would have made it out of mobile code, not dead text files with markup. But the limited expressivity of these formats makes them easier to read and to edit. I have two speech synthesis programs, eSpeak and Festival. Festival is written in Scheme, a wonderful, liberating, highly expressive language. eSpeak is in C++, which is a terrible language, so as much as possible of its functionality is in dumb data files that list pronunciations for particular letter sequences or entire words and whatnot. Festival does all of this configuration in Scheme files, and consequently I have no idea where to start. Fixing problems in eSpeak is easy, as long as they aren't in the C++ core; fixing problems in Festival is, so far, beyond my abilities. (I'm not an expert in Scheme, but I don't think that's the problem—I mean, my Scheme is good enough that I wrote a compiler in it that implements enough of Scheme to compile itself.) —·— SQL is, or until recently was, non-Turing-complete, but expressive enough that 6 lines of SQL can often replace a page or three of straightforward procedural code—much like Perl in the example above, but more readable rather than less. Similarly, HTML (or JSX) is often many times smaller than the code to produce the same layout with, say, GTK. And when it goes wrong, you can inspect the CSS rules applying to your DOM elements in a way that relies on them being sort of dumb, passive data. It makes them much more tractable in practice than Turing-complete layout systems like LaTeX and Qt3. —·— Perl and Forth both have some readability problems, but I think their main difficulty is that they are too error-prone. Forth, aside from being as typeless as conventional assembly, is one of the few languages where you can accidentally pass a parameter to the wrong call. This sort of rhymes with what I was saying in 02001 in https://paulgraham.com/redund.html https://paulgraham.com/redund.html, that often we intentionally include redundancy in our expressions of programs to make them less error-prone, or to make the errors easily detectable.
  • elitepleb 1y ago
    frankly it's a miracle any of them scaled at all, such popularity mostly comes down to an arbitrary choice made decades ago by a lucky vendor instead of some grand overarching design
  • socalgal2 1y ago
    I'm not entirely sure this is different from other languages but I believe a common complaint about lisp is every solution ends up writing a DSL for that solution, making it hard to understand for anyone else. So it's a super power if you're a small team and especially if you're a team of 1. But if you're a large team it doesn't scale.
  • pjmlp 1y ago
    Sadly our industry carries mostly about brick layers and usually tries to go into technologies that make it easier to deal with employees like replaceable servants at low wage prices. The large scale salaries SV style isn't something that you will find all over the globe, in many countries the pay is similar across all office workers, regardless if they are working with Git, or Office.
    • vlovich123 1y ago
      That argument implies that you would actually see these languages in communities with large SV style salaries which isn’t the case. It turns out that “brick layer” languages are also easier to understand not just for the next person taking over but yourself after a few months. That’s valuable even to yourself unless you value your time at 0.
      • pjmlp 1y ago
        Why? The less the VCs have to spend with employees the better. See the famous quote about Go's target audience, or 2000's Java being a blue colour job language. Not only do languages like Lisp, Forth, Smalltalk require a people to actually get them, a bit like the meme with burritos in Haskell, they suffered from bad decisions from companies pushing them. Lisp suffered with Xerox PARC, Symbolics and TI losing against UNIX workstations, followed by the first AI Winter, which also took Japan's 5th project with Prolog alongside with it. Smalltalk was getting alright outside Xerox PARC, with big name backers like IBM, where it had a major role on OS/2, similar to .NET on Windows, until Java came out, and IBM decided to pivot all their Smalltalk efforts into Java, Eclipse has roots on Visual Age for Smalltalk.
        • gjvc 1y ago
          psst blue "collar" :-)
        • vlovich123 1y ago
          Your entire post makes the claim that it’s because the vast majority of programmers get paid the same as other roles and that’s why there’s the language selection pressure there is. High salary jobs would be the exception yet they also make pragmatic choices about languages. It’s a two sided market problem - employers want popular languages to be used so they have a talent pool to hire from and don’t end up having a hard time finding talent (which then also implies something about the salary of course but it’s a secondary effect). Employees look to learn languages that are popular and are easy to find employment in. Not sure if you’ve spent any time with them but VCs and investors more broadly generally could give two fucks about the language a business is built in. There are exceptions but generally they just want to see the business opportunity and that you’re the team to go do it. There’s a reason it’s difficult to find employment with Haskell or Lisp or other niche languages and it’s because they’re niche languages that “you have to get” - not easy to learn and generally not as easy to work with as “popular” languages that see significantly more man hours dedicated to building out tooling and libraries. There’s also secondary things like runtime performance which is quite poor for Haskell or Lisp if you’re a beginner and even people familiar with the language can struggle to right equivalent programs that don’t use significantly more memory or CPU. And finally the languages can just be inherently more difficult and alien (Haskell) which attracts a niche and guarantees it remains a niche language that attracts a particular kind of person.
  • zovirl 1y ago
    I was lucky, early in my career, to work at a place which used a lot of Perl and to read Damian Conway’s book, Object Oriented Perl. It was an amazing, mind-expanding book for me. It was filled with examples of different approaches to object-oriented programming, more than I ever dreamt existed, and it showed how to implement them all in Perl. So much power! And right in line with Perl’s mantra, “there’s more than one way to do it.” Unfortunately, our codebase contained more than one way of doing it. Different parts of the code used different, incompatible object systems. It was a lot of extra work to learn them all and make them work with each other. It was a relief to later move to a language which only supported a single flavor of object-oriented programming.
  • procaryote 1y ago
    Powerful languages invites people to do needlessly complex things. Needlessly complex things are harder to understand. Harder to understand is worse. Code that matters is usually read and extended many more times than it is written, over time by different people, so being straightforward beats most other things in practice
    • jedwards1211 1y ago
      Stack-based programming may be simple but it doesn’t seem like it would be easy to read and understand for large-scale programs at all.
  • cjfd 1y ago
    One thing I note is that all of the languages you name are very far from the machine. Also Forth is not close to the modern machine. Note that it only has two integer types and the larger one can be aligned either way you make sure it is not.
    • lycopodiopsida 1y ago
      > One thing I note is that all of the languages you name are very far from the machine Common lisp is one step away from assembly - you disassemble any function and it is, in fact, a valid strategy of one wants to check the compiler optimizations.
      • cjfd 1y ago
        I googled a bit on how common lisp is compiled. Apparently it is possible to add some sort of type hints and ensure that parameters/variables have a certain type. If one uses that for most code, it would potentially be enough to qualify as being close to the machine.
        • vkazanov 1y ago
          Yes, in a way common lisp code can be locally lowered to a well-typed language. What people do is just write code they way they usually write dynamic lisp and then add types to functions where necessary for performance. SBCL generates good assembly, btw.
        • Zambyte 1y ago
          What does "close to the machine" mean to you?
          • cjfd 1y ago
            To me it means that one attempts to use the machine well. I.e., avoid introducing overheads that have nothing to do with the problem one is trying to solve. As an example of something that is very far from the machine imagine wanting to add some integers together. One can do this in untyped lambda calculus by employing Church Numberals. If one looks at the memory representation now your numerals are a linked list of a size equal, or proportional, to the number. However, the machine actually has machine language instructions to add numbers in a much more efficient way. For this discussion maybe the most relevant example is that using dynamic typing for algorithms that don't need it is distant from the machine because every value now has a runtime type label that is actually not needed because if your program could actually be statically typed, one would know in advance what the type labels are so they are redundant.
  • ErroneousBosh 1y ago
    It's a different solution for a different time. Forth was an excellent way to write a powerful and expressive programming language that could self-host with a bare minimum of assembly language "bare metal" programming. The fridge-sized computer that Forth was originally developed on had double-digit kilobytes of memory (maybe 8192kwords, with 16-bit words) and clocked instructions through at a whopping 300kHz or so. The microcontroller that drives the Caps Lock LED on your keyboard is a hundred times faster with a hundred times the memory. These days we do not need to squeeze editor, compiler, and target binary into such a tiny machine. If you're developing for a microcontroller you just use C on your "big" computer, which is unimaginably more powerful. In the olden days of the 1990s I used a development system for embedded stuff that was written in and targetted Forth on a Z80 with a whopping 64kB of RAM and 5.25" floppies, but that was at least ten years old and five years out of date at the time. You're probably reading my words on a slice of glass the size of half a sandwich that contains more computing power than existed in the whole world when Forth was first written. It's a shame because writing something like Forth from the ground up (and I mean, assembly code to load the registers to start the ACIA to begin transmitting text to the terminal) perhaps in an emulated early 80s home computer is a great way to get a sense of what the chip behind it all is doing, and I feel that makes you a better programmer in "real" languages like Go or Python or C.
    • kragen 1y ago
      What would your top two tips for beginning Forth programmers be? Other than "don't use Forth".
      • ErroneousBosh 1y ago
        Find an existing implementation that runs on some computer you already have, or have an emulator for. Then find a computer you're really into, and port fig-Forth to it, just for fun. Don't copy the source across, type it in with your own changes as you go. Edit: Don't forget to have fun. That's the most important thing. You're doing this because you *can*, and just to see what will happen.
        • 1y ago
  • lproven 1y ago
    > Why is it that languages like this don't scale? Stanislav Datskovskiy addressed this rather well: https://www.loper-os.org/?p=69 https://www.loper-os.org/?p=69
    • randallsquared 1y ago
      I've read that a number of times, but this is the first time since the rise of vibe engineering. > I predict that no tool of any kind which too greatly amplifies the productivity of an individual will ever be permitted to most developers. There's a new essay in here, somewhere, about why copilot and AI coding is succeeding at bridging this gap.
      • astrobe_ 1y ago
        It is too risky for companies to rely on a language that have a small pool of programmers. The bigger the company, the bigger the language must be. AI multiplies this availability, not productivity.
        • lproven 1y ago
          Flipside: it looks like the most productive programmers are those who work alone and not in a large pool. The core point of the article is that team development is slower and less efficient. Which means management must make a choice: getting good code relatively fast from a small pool of high-value individuals that it must therefore cherish and treat well... Or get poor-quality code, slowly, but from a large and redundant group of less skilled developers, who are cheaper and easier to replace. It is a truth universally acknowledged that from the three characteristics of "good, fast, and cheap", you can pick which two you want. In this case, maybe the choice is as simple as "good and fast" or "cheap." If the structure of the business or the market requires management to pick "cheap" (with concomitant but unspoken "bad and slow") then the structure, I submit, is bad.
      • lproven 1y ago
        > why copilot and AI coding is succeeding at bridging this gap. I mean, unless it proves with time that in fact it does not help at all and actually slows people down. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
  • 7thaccount 1y ago
    I think it's a simple abstraction situation and the move for programming environments that include everything. Geordi Laforge doesn't code much on the Enterprise. He simply asks the computer to build him a model of the anomaly so he can test out ideas. In a way, modern languages like Python (even before LLMs) let you get a lot closer to that reality. Sure you had to know some language basics, but this was pretty minimal and you'd use those basic building blocks to glue together libraries to make an application. Python has a good library for practically anything I do and since this is standard, it's expected that a task doesn't take too long. I can't tell my boss I'll need 3 years to code my own solution that uses my own libraries for numpy and scipy. You're expected to glue libraries together. This is why MIT moved SICP from scheme to Python. It's a different world. With Forth, every program is a work of art that encapsulates an entire solution to a problem from scratch. It's creator chuck moore takes this to such a level that he also fabs his own chips to work with his forth software optimally. These languages had libraries, but they weren't easy to share and didn't have any kind of repository before Perl's CPAN. Perl really took off for awhile, but Python won out by having a simpler language with builtin OO (Perl's approach was a really hacky builtin OO or you download a library...). To be honest though, I spent a decade trying many languages (dozens including common lisp, Prolog, APL, C, Ada, Smalltalk, Perl, C#, C++, Tcl, Lua, Rust...etc) looking for the best and although I never became experts in those languages, I kept coming to the conclusion that for my particular set of needs, Python was the best I could find. I wasted a lot of time reading common lisp books and just found it much easier to get the same thing done in Python. Your mileage will vary if you're doing something like building a game engine. A lot of people are just doing process automation and stuff like that and languages like Python are just better than common lisp due to the environment and tooling benefits. Also, although Python isn't as conceptually beautiful as lisp, I found it much easier to learn. The syntax just really clicked for me and some people do prefer it.
  • username223 1y ago
    I don't think there's a unifying reason why programming languages languish in obscurity; it's certainly not because they're "too powerful." What does "powerful" even mean? I used to care more about comparing programming languages, but I mostly don't these days. Actually used/useful languages mostly just got lucky: C was how you wrote code for Unix; Python was Perl but less funny-looking; Ruby was Rails; JavaScript is your only choice in a web browser; Lisp had its heyday in the age of symbolic AI. Forth and (R4RS) Scheme are simple to implement, so they're fun toys. Some other languages like Haskell have interesting ideas but don't excel at solving any particular problems. Both toy and general-purpose programming languages are plentiful.
    • lycopodiopsida 1y ago
      Alike to big fortunes, no one wants to hear the truth about lot of them existing due to simple luck. There is a significant amount of post-hoc rationalization to explain the success by some almost magic virtues. Or even explain the success by lack of such virtues - "worse is better" and so on.
  • mikewarot 1y ago
    >Why is it that languages like this don't scale? I've concluded that Forth isn't as powerful as Lisp because it can't do lists or heaps. STOIC addresses these and other limitations. Unfortunately it's got the least search friendly language name ever.
• nikolay 1y ago
  Many people glorify the simplicity of Lisp as an interpreter, but Forth is similar and underappreciated. Sadly, the only code I've written in Forth is... PostScript. Yeah, PostScript is a dialect of Forth. As a child, I really was amused by the demo of GraFORTH on Apple ][, which included 3D wireframe animations, which at the time were magical.
  • lutusp 1y ago
    > As a child, I really was amused by the demo of GraFORTH on Apple ][, which included 3D wireframe animations, which at the time were magical. I originally wrote GraFORTH (https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul) to escape the slow world of integer BASIC on my first computer (an Apple II). Because it relied on large blocks of assembly code to produce nice graphics, it perhaps misled people about what Forth could do on its own. Later I wrote a variation I called TransFORTH (https://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/programming/forth/TransFORTH%20%5D%5BB%20Reference%20Manual.pdf https://mirrors.apple2.org.za/ftp.apple.asimov.net/documenta...) that supported floating-point. I intended to combine GraFORTH and TransFORTH, but my computer didn't have enough RAM. Innocent times, different world, before the personal computing tail began wagging the dog.
    • vidarh 1y ago
      Someone mentioning childhood tech and the creator showing up is peak HN, in the best possible way. I love little threads like this... I never used a Forth as a child, but I recall reading about it and marvelling over it at a time when getting hold of huge amounts of pirated games was easy, but finding anywhere to even buy more serious tools could be challenge... I think it was probably 20+ years before I actually ended up trying a Forth.
    • ErroneousBosh 1y ago
      > I originally wrote GraFORTH Oh really? Given you were around at about the correct time period, could you hazard a guess at what dialect this very old Forth game from Byte magazine was written in? https://github.com/RickCarlino/Cosmic-Conquest-1982 https://github.com/RickCarlino/Cosmic-Conquest-1982 It has some graphics commands in that I couldn't find in any other version of Forth on the Apple II. I'm a little outside the Apple II demographic, since they didn't really take off in the UK - although the very first home computer I ever used was an Apple II owned by the father of the guy that founded Rockstar Games :-)
• kragen 1y ago
  This is, I think, the best overview of Forth, and computing as a whole, that I've ever seen.
  • sph 1y ago
    Big compliment, coming from you. (I wish you would write again. I have immensely enjoyed the stuff on your website)
    • kragen 1y ago
      Thanks! You might want to git clone http://canonical.org/~kragen/sw/pavnotes2.git/ http://canonical.org/~kragen/sw/pavnotes2.git/.
• dlcarrier 1y ago
  That is assuming that you, with German grammar, write.
  • DavidSJ 1y ago
    I believe, that you that sumes as mean.
• rpcope1 1y ago
  If you like Forth, but find it challenging to build real stuff with, Factor (https://factorcode.org/ https://factorcode.org/) is most or all of the good stuff about Forth designed in a way that's much easier to do things with. It was designed by Slava Pestov (who I think had a big hand in Swift), and honestly it's a lot of fun to build webapps and other programs with, and much less brutal to read than Forth can be.
  • arethuza 1y ago
    I have very fond memories of programming in PostScript within NeWS/HyperNeWS - it did quite a few things that I've never seen in any other environment. Edit: To be fair relying on PostScript probably did limit the appeal, but I actually really liked it.
    • DonHopkins 1y ago
      Thank you fellow HyperLooker! For me, PostScript WAS the appeal! For the rest of the civilized world, Arthur van Hoff wrote "PdB", an object oriented PostScript => C compiler. https://news.ycombinator.com/item?id=10088193 https://news.ycombinator.com/item?id=10088193 >Arthur van Hoff wrote PdB, and we used it for to develop HyperLook (nee HyperNeWS nee GoodNeWS). You could actually subclass PostScript classes in C, and vice-verse! https://news.ycombinator.com/item?id=29964271 https://news.ycombinator.com/item?id=29964271 >That's interesting! I love Forth, but I love PostScript even more, because it's so much like Lisp. What is it about PostScript that you dislike, that doesn't bother you about Forth? >Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript. Leigh Klotz used PdB at Xerox PARC, and wrote this about it here: https://regex.info/blog/2006-09-15/247#comment-18269 https://regex.info/blog/2006-09-15/247#comment-18269 >OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java. Syntactic Extensions to PdB to Support TNT Classing Mechanisms: https://www.donhopkins.com/home/archive/NeWS/PdB.txt https://www.donhopkins.com/home/archive/NeWS/PdB.txt Most of the built-in HyperLook components were written in C with PdB. I wrote HyperLook wrapper components around TNT 2.0 (The NeWS Toolkit) objects like pie menus, Open Look menus, sliders, scrolling lists, buttons, etc. I used them in the HyperLook edition of SimCity, which you can see in this screen snapshot: https://www.donhopkins.com/home/catalog/hyperlook/HyperLook-SimCity.gif https://www.donhopkins.com/home/catalog/hyperlook/HyperLook-... Arthur later went on to join Sun (James Gosling's "First Person" group), wrote the Java compiler in Java, and AWT, then left Sun to form Marimba, where they developed "Castanet" (push code and content distribution), and Bongo (HyperCard/HyperLook for Java, with a WYSIWYG UI editor and script editor, that dynamically ran the Java compiler to compile and hot patch scripts attached to objects on the fly. Which was groundbreaking at the time, though IDEs do it all the time now). https://news.ycombinator.com/item?id=25434613 https://news.ycombinator.com/item?id=25434613 >Bongo is to Java+HyperCard as HyperLook is to PostScript+HyperCard. Danny Goodman himself (the HyperCard book author) wrote a book about Bongo! Arthur's Forward explains it well. https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/dp/1575212544 https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/... https://archive.org/details/officialmarmba00good https://archive.org/details/officialmarmba00good >Foreward >Marimba was formed in early 1996 by four members of the team that created Java. Kim Polese, Jonathan Payne, Sami Shaio, and I left Sun Microsystems and founded Marimba with the goal to build commercial consumer applications written entirely in Java. >While at Sun we concentrated on creating a great multi-platform, portable, efficient, object-oriented, multi-threaded, and buzzword-compliant language. However, we paid too little attention to developing tools. In early 1996 Java was largely still a language for skilled programmers who are happy with emacs, a Java compiler, and lots of coffee. Luckily these so-called "Rambo" programmers loved Java and made it very successful. >Creating large applications in Java turned out to be much harder than we had anticipated, so we decided that we needed better tools before we could build better applications. That is why we created Bongo. Bongo is a tool that allows you to quickly create a user interface using a variety of widgets, images, audio, and animation. After you have created a user interface you can script it in Java, or you can easily hook it up to a Java program. >Bongo is a high-level tool that provides a clean separation of semantics and design elements. >It allows multi-disciplinary teams to work simultaneously on a large application without getting in each other's hair. You will find that it is a very powerful tool that is great for creating good-looking, functional, but still very flexible user interfaces. In addition to the standard widgets, Bongo enables you to extend the widget set by creating new widget classes in Java. >This means that you can develop your own set of widgets which are easily integrated into user interfaces developed with Bongo. >One of the great features of Bongo is its capability to incorporate applets into user interfaces. >This enables you to use applet creation tools from third-party software vendors to create components of your user interface and combine these components into a single consistent application using Bongo. This is the way of the future: In future releases, Bongo will naturally support Sun's JavaBeans which will further simplify the process of integrating components created by different tools. This way, you can choose the tools that are appropriate for the job, rather than being stuck with the tools provided by the environment. >A lot of the ideas behind Bongo are based on a tool called Hyper NeWS which I developed for the NeWS windows system during the late '80s (NeWS was another brain-child of Sun's James Gosling). HyperNeWS used the stack, background, and card model which was popularized by Apple's HyperCard. Bongo goes a lot further than HyperNeWS by allowing arbitrary container hierarchies and scripting. >I am really excited that Danny has written this excellent book on Bongo. It clearly explains the concepts behind Bongo, and it takes you through many examples step by step. This book is an essential tool for all serious Bongo users. >Have fun, Arthur van Hoff, Chief Tenology Officer, Marimba, Inc.
• tombert 1y ago
  Forth has been a peripheral fascination of mine for about a decade, just because it seems to do well at nearly every level of the software stack. Like a part of me wants to build a kernel with it, or make a web server, or anything in between. I've never actually done any Forth, though, just because it's a bit arcane compared to the C-inspired stuff that took over.
• fennec-posix 1y ago
  A long read but one that's quite incredible. Has definitely helped my understanding of computing get closer to the metal so to speak.
• nakamoto_damacy 1y ago
  I wish "Simple Made Easy," by Rich Hickey, could be applied here. Forth is simple but not easy. If there is something as simple as Forth but also accessible to mere mortals (aka easy) then I'd like to know what it is (I don't consider Clojure itself as a language to be simple in this sense).
• shevy-java 1y ago
  Back in 2004 or so - ancient days now - I remember an elderly programmer on #gobolinux (freenode IRC back in the days) who kept on praising Forth. I never understood why, but he liked Forth a lot. Now - that in itself doesn't mean a whole lot, as it is just anecdotal, but people who are very passionate about programming languages are quite rare. I've not seen something like that happen with any other language (excluding also another guy on #gobolinux who liked Haskell). I did not see anyone praise, say, PHP, perl, JavaScript etc.... Some languages people don't like to talk about much. Forth though was different in that regard. I never got into it; I feel it has outlived the modern era like many other languages, but that guy who kept on talking about it I still remember. His website also was built in Forth and it was oddly enough kind of an "interactive" website (perhaps he also used JavaScript, I forgot, but I seem to remember he said most or all of it was implemented in Forth - turtles all down the way).
• punkbrwstr 1y ago
  [dead]
• sriku 1y ago
  I've had a soft spot for Forth and am toying with a silly Forth-like interpreter for web programming ... if not for actual use, at least for some fun time. One concept it adds is the notion of a "current selection" which can define the available vocabulary to use and is used to select and work with DOM elements. Just experimenting. https://github.com/srikumarks/pjs https://github.com/srikumarks/pjs Edit: As a kid, I disliked BASIC as a language though it let me do fun stuff. So I made an interpreter in BASIC for a language I'd like and it turned out Forth-like (and I didn't know about Forth at that time). I guess I'm still that kid some 35 years later.
• rtpg 1y ago
  it mentions sometimes not naming things as great, but... what does naming intermediate values in forth look like? Is there even a naming scope that would allow for me to give values names in case I don't want to get entirely lost in the sauce?
• js8 1y ago
  I used to be a fan of these languages like Lisp and Forth and Joy (and Factor and Haskell), but then I found that what I a really long for is just (untyped) lambda calculus (as a universal language). (Combinatory logic is just a similar representation of lambda calculus, but the differences go away quickly once you start abstracting stuff.) I think expressing semantics of all (common) programming languages in lambda calculus would give us a solid foundation for automated program translation. And we should aim for that, the babel tower of languages doesn't really help anyone. The current issue I have is with type theory. So I am trying to embed notion of types directly into the lambda terms, so they would sort of "automatically typecheck" when composed. The crucial in this, in my opinion, are lambda terms that do not use lambda abstraction in their body, because you can think of these terms as a kind of mini-DSLs that have yet to be interpreted. Anyway, once we can translate calculus of constructions (and other common formal logics) into untyped lambda calculus, it will also help us doing automated theorem proving. It must be theoretically possible, but to my knowledge nobody has really done this sort of hardcore formalization.
  • procaryote 1y ago
    Why specifically untyped?
    • js8 1y ago
      Because it is the simplest thing we have, and has a pretty straightforward self-interpreter. It feels like you need a lot more metamathematics to deal with typed lambda calculus than with untyped one, and types are something that comes without a justification. Anyway, the idea is, if you have a language, you can think of source code written in the language as a giant lambda term, where you have all lambdas upfront and only composition in the body. A tree of symbols to be composed, essentially. And then to interpret this source code in a language, you supply definitions of the language's primitives as arguments to the source code term. Now if your language is typed, the primitives need to be chosen in such a way, so that the interpreted term (the source code applied to language primitives) fails to normalize if the program is not typed correctly. You can then have a correspondence between the primitives of the typed language that typecheck and simpler set of primitives of the same language used purely for computation, used under the assumption that the program typechecks. This correspondence "defines" the typing mechanism of your language (in untyped lambda terms).
• jll29 1y ago
  FORTH has some elegance and it's so simple that it is tempting to implement it. However, no language should permit defining the value of 4 by 12, as there is no situation in which this can bring more good than harm in the long term. Another issue that affects FORTH but also Perl and other languages is that they deal with a lot of things implicitly (e.g. the stack, or arguments to functions). Most people agree that explicity is more easy to read than implicit.
  • ErroneousBosh 1y ago
    > However, no language should permit defining the value of 4 by 12, as there is no situation in which this can bring more good than harm in the long term. A Skil saw should not permit you sticking your fingers in the spinning blade, yet most people know that this is a stupid and dangerous thing to do.
    • schwartzworld 1y ago
      Lots of saws have safety features to keep fingers from being removed. It happens all the time.
• peter303 1y ago
  RPN interpreters require very little core memory. So they were popular with computers where core memory was under ten kilobytes. But its horrible for software engineering with multiple programmers and large codebases. Lacks structures, interfaces, modules, data abstraction that you expect in a modern language. We called it the "Chinese food" of coding- ten minutes later you had nomidea what you just coded.
• praptak 1y ago
  "Working without names (also known as implicit or tacit or point-free programming) is sometimes a more natural and less irritating way to compute. Getting rid of names can also lead to much more concise code. And less code is good code." Does Forth really reduce the burden of naming things? You don't name results but don't you have to pay for it with the burden of naming words? (My impression is that there's more words in a Forth program than functions in an equivalent program in a language that has named variables).
  • 7thaccount 1y ago
    The quote makes more sense IMO for array languages like J that support a tacit style. J's "trains" just make things flow without a lot of variables. Aaron Hsu's Co Dfns compiler (spoken about on here and YouTube) also uses this style with Dyalog APL. Forth is concatenative, so you can build the words on top of each other without worrying about a ton of variables. So I think it's partially true for Forth.
  • vdupras 1y ago
    Yeah, I wouldn't have phrased it like in the article either. What I'd say is that Forth is more about naming processes than variables.
  • astrobe_ 1y ago
    > Does Forth really reduce the burden of naming things? I would say that you have less names, but they are more important. Plus, it is more difficult to name things because you prefer short names; in all languages, when you have a good naming "discipline", follow a naming convention, you end up with an informal "grammar" inside of your names. In Forth this is even more important. > My impression is that there's more words in a Forth program than functions in an equivalent program in a language that has named variables Yes, some people have called that "ravioli code" or "confetti code", IIRC. But most of them are support words. In Forth, you also eventually end up with "module APIs". This also exists in C or Java or ..., except the ratio useful:support is lower.
• stsquad 1y ago
  In my first proper job as a software engineer I wrote a bunch of Forth for "fruit machines". I don't know what the US equivalent would be but they are low stakes gambling machines which are quite common in UK pubs. The core processor was a 6809 and Forth was chosen because the interpreter was super small and easy to implement. I really appreciated the quick interactive way you could update and tweak code as you tested it. I did get slightly weary of having to keep the state of the stack in your head as you DUP and SWAP stuff around but that was probably due to my inexperience and not decomposing things enough. They continued to use Forth as the basis for their 68000 based video gaming machines although when it came to the hand classifier for video poker we ended up using C - mostly because we wanted to run a lot of simulations on one of these new fangled "Pentium" processors to make sure we got the prize distribution right to meet the target repayment rate of ~98%.
  • _vqpz 1y ago
    We just refer to them as “slot machines” in the US
  • deleted 1y ago
    [deleted]
• alganet 1y ago
  There's a certain mesmerizing effect that creeps in once you start digging into programming language fundamentals. Any kind of notation, really, can do that to a person. It's kind of hypnotic. I avoid it like the plague (getting too much into it). Not because I dislike it, but because I like it so much. I believe the ideal programming language must be full of problems, and then obvious ways to get around those problems. It's better than a near-perfect language with one or two problems that are very hard to get around. The "Stop Writing Dead Programs" video mentioned is quite nice. It's surprising how the web is a platform for many of the languages the presenter offer as inspiration.
• vertnerd 1y ago
  I was captivated by the August 1980 issue of Byte magazine, which had a cover dedicated to Forth. It was supposed to be easy to implement, and I imagined I might do that with my new KIM-1 6502 board. Alas, the KIM-1 was lost when I went to college, and life forced me down different pathways for the next 45 years. About a year ago I finally began to work on my dream of a Forth implementation by building a Forth-based flight management computer into a spaceflight simulation game that I am working on. Now, instead of writing mostly C# or GDscript code in Godot, I am trying to figure out ways to create a useful device using this awkwardly elegant language. I'm having fun with it. One of the interesting bits is that I have been able to make the Forth code an entirely separate project on Github (https://github.com/Eccentric-Anomalies/Sky-Dart-FMS https://github.com/Eccentric-Anomalies/Sky-Dart-FMS), with a permissive open-source license. If anyone actually built a real spacecraft like the one in my game, they could use the FMS code in a real computer to run it. There is one part of the linked article that really speaks to me: "Implement a Forth to understand how it works" and "But be aware of what this will not teach you". Figuring out the implementation just from reading books was a fascinating puzzle. Once I got it running, I realized I had zero experience actually writing Forth code. I am enjoying it, but it is a lot like writing in some weird, abstract assembly language.
  • area51org 1y ago
    I had that issue, and I think I still might have it in my closet. (Weren't those Robert Tinney covers amazing?) I always wanted to try out Forth but had no real opportunity. Maybe I should now?
  • PaulHoule 1y ago
    Circa 1980 BASIC was the dominant language for micros because you could fit BASIC in a machine with 4k of RAM. Although you got 64k to play with pretty quickly (1983 or so) it still was a pain in the ass to implement compilers on many chips, especially the 6502, which had so few registers and addressing modes that you're likely to use virtual machine techniques, like Wozniak's SWEET 16 or the atrocious p-code machine that turned a generation of programmers away from PASCAL. FORTH was an alternative language for small systems. From the viewpoint of a BASIC programmer in 1981 the obvious difference between BASIC and all the other languages which that you could write your own functions to add "words" to the language. FORTH, like Lisp, lets you not only write functions but create new control structures based on "words" having both a compile-time and run-time meaning. FORTH's answer to line numbers in BASIC was that it provided direct access to blocks (usually 1024 bytes) on the disk with a screen editor (just about a screenful on a 40x25) You could type your code into blocks and later load them into the interpreter. Circa 1986 I wrote a FORTH for the TRS-80 Color Computer running the OS-9 operating system and instead of using blocks it had POSIX-style I/O functions. FORTH was faster than BASIC and better for systems work, but BASIC was dominant. Probably the best way to use FORTH was to take advantage of it's flexibility to create a DSL that you write your applications in.
• schwartzworld 1y ago
  I spent a few months playing with forth after seeing a talk on it at Boston Code Camp. I struggled to find a practical application (I do web dev), but it had a lasting effect on my style of programming. Something about the way you factor a forth program changed me. Now I mainly do functional-flavored typescript, and while forth is NOT an FP language, there is a lot that carries over. In Forth, the language rewards you for keeping your words focused and applying the single responsibility principal. It’s very easy to write a lot of small words that do one thing and then compose your program out of them. It’s painful to not do this. There is no state outside the stack. If you call a word it pulls values off the stack and deposits values back on the stack. Having no other mechanism for transferring data requires you to basically create data pipelines that start to look like spoken language.
• mkovach 1y ago
  I first encountered Forth on a TI-99/4A, complete with that magnificent expansion box that looked like industrial HVAC equipment. Hearing me complain about TI Extended BASIC's glacial pace, my parents saw in one of my magazines that Forth was faster and bought it hoping I would find it helpful. It was mind-bending but fascinating. I managed a few text adventures, some vaguely Pac-Man-esque clones, and a lingering sense that I was speaking a language from another dimension. I've since forgiven my parents. Forth resurfaces now and then, usually when I reread Leo Brodie's thought-provoking Forth books, and I feel like I'm decoding the sacred texts of a minimalist cult. I came away thinking better, even if I've never completely caught up with the language.
• snitty 1y ago
  I remember programming in Forth on my Palm Pilot, as there was a Forth interpreter for it.
• whartung 1y ago
  The Forth super power is that you have full control over how a symbol is evaluated, both at compile and runtime. I don't know of anything else that offers that. Lisp doesn't. That gives the developer pretty much free rein to do whatever they want, which can be both good and bad. I've always loved the elegance of Frank Sergeant's 3 Instruction Forth paper [1], it's very cool once you wrap your head around it. Also, studying the F83 Metacompiler is valuable as well. F83 is a very capable 8/16-bit Forth system. I honestly marvel at how much work must have gone into F83, given the tools of the time. I wish I knew more about its development journey. How it got bootstrapped. [1] https://pygmy.utoh.org/3ins4th.html https://pygmy.utoh.org/3ins4th.html
• dcreager 1y ago
  Stepping away from Forth in particular, one of the benefits of a stack-based / concatenative language is that it's easy to implement on constrained hardware. uxn [1] is a great example of that. And shameless self-promotion, if you're interested in how these kinds of languages compare with more traditional named-based languages, with more theoretical constructs like the lambda calculus and combinatory logic, and with gadgets like a PyBadge — well you're in luck! I gave a talk about exactly that at the final Strange Loop [2]. [1] https://100r.co/site/uxn.html https://100r.co/site/uxn.html [2] https://dcreager.net/talks/concatenative-languages/ https://dcreager.net/talks/concatenative-languages/
  • Rendello 1y ago
    TL;DR: I'm trying to Forth a Lisp. This is long winded, but maybe you have some thoughts here. I've been building a DOM-builder API recently in Rust. The existing options (there are many) tend to use textual templating, which can't reason well about anything, or basic macros, which never support indentation. I wanted something that was just code, where I'd be in full control on the indentation (or lack thereof) programmatically. The closest equivalent is Python's Dominate [1], though its indentation mechanisms are buggy. So I built a system using the traditional tree where Nodes own other Nodes at random addresses, and I built a renderer that renders those nodes and concatenates their strings recursively. It ended up working but it was hacky and very slow for the large inputs. In release mode, it was taking almost a minute to render 70 files, and I want about two orders of magnitude lower. I ran it through profilers and optimized it a bit, but wanted to see if I could simplify the architecture and reduce the amount of work the computer could do. I read about flattening ASTs [2] and how through optimizing that format, you can end up with a sort of bytecode [3]. I also looked into Data-Oriented Design, watching Mike Acton's famous talk [4], Andrew Kelley's talk about DoD in Zig [5], and reading through the DoD book by Richard Fabian [6]. I ended up with something that works quite well for traversing and rendering, which is a stack that can be traversed and rendered in O(n), but I lost my nice Dominate-like API. As in, I can build these beautiful, flat trees, but to embed those trees in my code, I need to either materialize a tree in the traditional style first and then push it onto these stacks, or do some sort of macro magic to make these stack pushes. I wonder if this is a common issue with stack-based programming. It is, in my case, quite simple for the computer, but hard to fit into an API without building up the stack manually! --- 1. https://pypi.org/project/dominate/ https://pypi.org/project/dominate/ 2. https://www.cs.cornell.edu/~asampson/blog/flattening.html https://www.cs.cornell.edu/~asampson/blog/flattening.html 3. https://old.reddit.com/r/ProgrammingLanguages/comments/mrifdr/treewalking_interpreters_and_cachelocality/gumsi2v/ https://old.reddit.com/r/ProgrammingLanguages/comments/mrifd... 4. [Mike Acton] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc 5. [Zig] https://www.youtube.com/watch?v=IroPQ150F6c https://www.youtube.com/watch?v=IroPQ150F6c 6. https://www.dataorienteddesign.com/dodbook.pdf https://www.dataorienteddesign.com/dodbook.pdf
• DonHopkins 1y ago
  Coco Conn and Paul Rother wrote this up about what they did with FORTH at HOMER & Assoc, who made some really classic music videos including Atomic Dog, and hired Charles Moore himself! Here's what Coco Conn posted about it, and some discussion and links about it that I'm including with her permission: https://news.ycombinator.com/item?id=36751574 https://news.ycombinator.com/item?id=36751574 Mitch Bradley came up with a nice way to refactor the Forth compiler/interpreter and control structures, so that you could use them immediately at top level! Traditional FORTHs only let you use IF, DO, WHILE, etc in : definitions, but they work fine at top level in Mitch's Forths (including CForth and Open Firmware): https://news.ycombinator.com/item?id=38689282 https://news.ycombinator.com/item?id=38689282
• pardner 1y ago
  In early 80s when I was a wee nerd in college a gentleman named Ray who owned Laboratory Microsystems was nice enough to give a poor college kid a copy of his excellent Forth implementation for the then-nascent IBM PC. I breadboarded a little EPROM programmer (driven by a parallel printer port with the programming code done in Forth because I couldn't afford a real one). Then breadboarded implemented a little Z80 system with a bunch of general purpose I/O and a Forth "OS" in EPROM. Used that little setup as the basis for a number of projects, including a home alarm system with phone-based control plus voice synthesis phone-based alert calling (which a couple silicon valley VCs were gracious enough to take a meeting about). Forth gave me wings. Despite it's reputation as a "write-only language". Good times.
• mmaug 1y ago
  Like many here, the annual "language" issue of Byte Magazine in 1980 introduced me to Forth. Although I was enrolled as an engineer in college, I was a frustrated (mediocre) programmer but my upstate NY institute did not offer a Comp Sci degree at that time. Forth was a gateway drug for me and demystified the concept of compiling for me. Prior to Forth, when a thousand Freshman engineers were writing their Fortran IV projects for an 8am class the next morning on mainframe 3270 terminals, we imagined that the operators must have to continuously pour water on the compiler to keep it cool. Yeah, it was 1980 and computers were still a little magic. But Forth and threaded code was a life changer; it explained so much! My 3rd year, I partially implemented a 32-bit Forth in IBM S360 Assembler but getting I/O to work was my downfall (mostly due to my poor skills and lack of experience.) But the threaded interpreter and the basic stack ops all worked. But then I was introduced to Lisp... But my love of Forth never left me. I make my living with C in the early days, but predominantly SQL and Bash these days. When I had my second (third?) midlife crisis, I got two tattoos on my arm: one is the Y Combinator in Lisp (I 'lost' a trailing parenthesis due to a cut-n-paste error in the template given to the tattoo artist, so I had to go back and get another tattoo with an error message pointing out the missing parenthesis.), the second tattoo is the implementation of an ANSI Forth word: : ? @ . ; The fact that I could write an entire function with only punctuation characters was mind-blowing and reminds me to approach problems in unique ways. The tattoos are also great ways to start up conversations in bars...
• 1vuio0pswjnm7 1y ago
  "There is absolutely no reason we have to use increasingly inefficient and poorly-constructed software with steeper and steeper hardware requirements in the decades to come." The term "we" as used here hopefully means individual, free-thinking computer users, not so-called "tech" companies If Silicon Valley companies want to use increasingly-inefficient, poorly-constructed, resource-insatiable software, then nothing stops them from doing do "Forth is not easy. It may not always even be pleasant. But it is certainly simple." Complex isn't easy, either That is why (a) "insecurity", unreliability, expense, etc. and (b) complexity generally go hand-in-hand
• wodenokoto 1y ago
  Hot take from someone who has never seen concatenative languages outside of bash and R pipes, has never written any lisp, just read about it on forums like this: Forth is lisp in reverse, without the parenthesis. Which, as a big fan of piping things sounds really sweet.