8 ms·

Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my exp

by haolez 7y ago

Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.

adestefan 7y ago
That is exactly what Chuck Moore wanted when inventing Forth.
- haolez 7y ago
  I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)
  - mr_crankypants 7y ago
    The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.
    - dTal 7y ago
      Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.
      - astrobe_ 7y ago
        No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need. Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have. That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.
        markus_zhang 7y ago
        at least we can get rid of the bloated web apps once everyone begins to do so...but would it be possible if libaries are written in a way that it's easy to just integrate just a portion into existing code?
        mr_crankypants 7y ago
        The problem there is that most "libraries" are actually frameworks. The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using. Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it. To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.
        abstract7 7y ago
        Wow that go me thinking. What if specialized AI code recommenders could sniff out solutions. Get away from libraries with objects or structs with methods that mutate. As more people realize composing functions (Forth has concept of composing words, correct?) with fewer side effects is a good thing, I wonder if it's possible. There is some amount of my workflow where I'm looking at StackOverflow, my git project history or others, examples even on blogs (at least when I was new), or my little code snippet journal for stuff already solved. Automate getting idiomatic solutions from a StackOverflow or Github commits of sorts, or something. I know we are no were near, but FB's Aroma and others have the first gen AI recommenders in the pipeline that at a high level do this. That way we are just dealing with code snippets. I've only read Forth code and introductions to it, but it seem all about composition. However this is hard to conceive with today's coding forums and repos because most are gluing mutating library APIs (turtles all the way down) together. So a code recommender paradigm of this sort is chicken vs egg.
    - rauhl 7y ago
      I agree with you, but I wonder what his answer to stuff like GUIs would be. There’s a tremendous amount of complexity and domain knowledge in stuff like drawing fonts, and in cryptography, and so forth — and very very few of us have the time to become competent in even one of those, let alone all of them. Then consider the amount of work necessary to have a modern browser: text parsing of not one but three languages, language interpretation, more graphics, more cryptography. It would be awesome to get back to first principles, but modern systems try to do so much that I wonder how practical it would be to reinvent them — and I would how practical it is to say, ‘well, don’t do that then.’
      - mr_crankypants 7y ago
        I don't know what Moore would say. Personally, I've retreated to the back end - used to be full stack, but I'm just sick to death of how overcomplicated front-end work has become. I'm inclined to say that, e.g., the modern browser is a cautionary tale that complements the Chuck Moore approach to things: By forever piling thing on top of thing in an evolutionary way, you end up with a system that ultimately feels more and more cobbled together, and less and less like it ever had any sort of an intelligent designer. Perhaps the lesson is that it can be worthwhile to occasionally stop, take a real look at what things you really do need, aggressively discard the ones you don't, and properly re-engineer and re-build the system. Obviously there are issues of interoperating with the rest of the world to consider there, and Moore has made a career of scrupulously avoiding such encumbrances. But a nerd can dream.
        abstract7 7y ago
        Also consider that all we know is a world that has become more global, open, and relatively peaceful post 1970s. If collaboration were to slow or decline, open-source would be harmed. And/or if Google and Facebook lose its dynamism from politics, regulation, and maturity, corporate sponsored open-source could be shaken. Google could become like AT&T and Facebook like Ericsson or something in some way. Once unstoppable sectors, like aerospace (to mix comparisons) began to reverse and decline in the early 70s. No one really saw it coming. I can't think if one publicly known or credible person called it in 1969 shortly after the moon landing, at least on record. Oversupply of engineers in the US and the West became a thing. And engineering still suffers here because of aerospace's decline. Forth began to lose steam around then, right? Forth, hardware and Cold War (barriers) politics are inextricably linked, perhaps. And then GNU/Linux and BSD saw its high-collaboration paradigm birthed around that time. Nixon/Kissenger talks with closed China began around then too, and now relations are breaking down with a more open China today. Look how Lua scripting came about not terribly so long ago. Some parallels. Brazilian trade barriers. Now half believe Huawei is evil. Cross-hardware story may be cracking. Many believe Google is evil. Open software may be cracking. And there are rifts between US, EU, and China on how to regulate the internet. A new Cold War may be brewing. It's a nerds nightmare. If anyone can tie in distributed ledger and specialized AI coder productivity tools, or something to counter this argument or round it out, that would be awesome. EDIT: I was mistaken. Forth caught on with personal computer hobbyists in the 1980s, per Wikipedia. However, as a career or industry,slow downs with NASA and Cold War spending seemed to take some wind out of Forth's sails. I've noted that lot of that type of work was what paid people to write Forth. And the open-source paradigm with C/C++ and GNU Linux was even more limiting, I believe.
petjuh 7y ago
In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.
- TeMPOraL 7y ago
  Moreover, in any nontrivial application, you have modules and layers of abstractions - and those boundaries are DSLs on their own. It's actually good to think of them as languages the client code will use to write its solutions in (SICP makes this point early in the book too). People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.
kreetx 7y ago
Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.
- pointfree 7y ago
  "Over the Shoulder 1 - Text Preprocessing in Forth" https://www.youtube.com/watch?v=mvrE2ZGe-rs https://www.youtube.com/watch?v=mvrE2ZGe-rs - Sam Falvo demonstrates writing a blog engine in Forth.
jacquesm 7y ago
I don't see the semantic difference between calling a subroutine or using a Forth word. 65 emit vs putchar(65); vs (print 'A') It's all the same to me.

by haolez 7y ago

adestefan 7y ago

That is exactly what Chuck Moore wanted when inventing Forth.

haolez 7y ago
I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)
- mr_crankypants 7y ago
  The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.
  - dTal 7y ago
    Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.
    - astrobe_ 7y ago
      No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need. Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have. That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.
      - markus_zhang 7y ago
        at least we can get rid of the bloated web apps once everyone begins to do so...but would it be possible if libaries are written in a way that it's easy to just integrate just a portion into existing code?
        mr_crankypants 7y ago
        The problem there is that most "libraries" are actually frameworks. The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using. Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it. To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.
        abstract7 7y ago
        Wow that go me thinking. What if specialized AI code recommenders could sniff out solutions. Get away from libraries with objects or structs with methods that mutate. As more people realize composing functions (Forth has concept of composing words, correct?) with fewer side effects is a good thing, I wonder if it's possible. There is some amount of my workflow where I'm looking at StackOverflow, my git project history or others, examples even on blogs (at least when I was new), or my little code snippet journal for stuff already solved. Automate getting idiomatic solutions from a StackOverflow or Github commits of sorts, or something. I know we are no were near, but FB's Aroma and others have the first gen AI recommenders in the pipeline that at a high level do this. That way we are just dealing with code snippets. I've only read Forth code and introductions to it, but it seem all about composition. However this is hard to conceive with today's coding forums and repos because most are gluing mutating library APIs (turtles all the way down) together. So a code recommender paradigm of this sort is chicken vs egg.
  - rauhl 7y ago
    I agree with you, but I wonder what his answer to stuff like GUIs would be. There’s a tremendous amount of complexity and domain knowledge in stuff like drawing fonts, and in cryptography, and so forth — and very very few of us have the time to become competent in even one of those, let alone all of them. Then consider the amount of work necessary to have a modern browser: text parsing of not one but three languages, language interpretation, more graphics, more cryptography. It would be awesome to get back to first principles, but modern systems try to do so much that I wonder how practical it would be to reinvent them — and I would how practical it is to say, ‘well, don’t do that then.’
    - mr_crankypants 7y ago
      I don't know what Moore would say. Personally, I've retreated to the back end - used to be full stack, but I'm just sick to death of how overcomplicated front-end work has become. I'm inclined to say that, e.g., the modern browser is a cautionary tale that complements the Chuck Moore approach to things: By forever piling thing on top of thing in an evolutionary way, you end up with a system that ultimately feels more and more cobbled together, and less and less like it ever had any sort of an intelligent designer. Perhaps the lesson is that it can be worthwhile to occasionally stop, take a real look at what things you really do need, aggressively discard the ones you don't, and properly re-engineer and re-build the system. Obviously there are issues of interoperating with the rest of the world to consider there, and Moore has made a career of scrupulously avoiding such encumbrances. But a nerd can dream.
      - abstract7 7y ago
        Also consider that all we know is a world that has become more global, open, and relatively peaceful post 1970s. If collaboration were to slow or decline, open-source would be harmed. And/or if Google and Facebook lose its dynamism from politics, regulation, and maturity, corporate sponsored open-source could be shaken. Google could become like AT&T and Facebook like Ericsson or something in some way. Once unstoppable sectors, like aerospace (to mix comparisons) began to reverse and decline in the early 70s. No one really saw it coming. I can't think if one publicly known or credible person called it in 1969 shortly after the moon landing, at least on record. Oversupply of engineers in the US and the West became a thing. And engineering still suffers here because of aerospace's decline. Forth began to lose steam around then, right? Forth, hardware and Cold War (barriers) politics are inextricably linked, perhaps. And then GNU/Linux and BSD saw its high-collaboration paradigm birthed around that time. Nixon/Kissenger talks with closed China began around then too, and now relations are breaking down with a more open China today. Look how Lua scripting came about not terribly so long ago. Some parallels. Brazilian trade barriers. Now half believe Huawei is evil. Cross-hardware story may be cracking. Many believe Google is evil. Open software may be cracking. And there are rifts between US, EU, and China on how to regulate the internet. A new Cold War may be brewing. It's a nerds nightmare. If anyone can tie in distributed ledger and specialized AI coder productivity tools, or something to counter this argument or round it out, that would be awesome. EDIT: I was mistaken. Forth caught on with personal computer hobbyists in the 1980s, per Wikipedia. However, as a career or industry,slow downs with NASA and Cold War spending seemed to take some wind out of Forth's sails. I've noted that lot of that type of work was what paid people to write Forth. And the open-source paradigm with C/C++ and GNU Linux was even more limiting, I believe.

petjuh 7y ago

In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.

TeMPOraL 7y ago
Moreover, in any nontrivial application, you have modules and layers of abstractions - and those boundaries are DSLs on their own. It's actually good to think of them as languages the client code will use to write its solutions in (SICP makes this point early in the book too). People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.

kreetx 7y ago

Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.

pointfree 7y ago
"Over the Shoulder 1 - Text Preprocessing in Forth" https://www.youtube.com/watch?v=mvrE2ZGe-rs https://www.youtube.com/watch?v=mvrE2ZGe-rs - Sam Falvo demonstrates writing a blog engine in Forth.

jacquesm 7y ago

I don't see the semantic difference between calling a subroutine or using a Forth word. 65 emit vs putchar(65); vs (print 'A') It's all the same to me.