4 ms·

My biggest problem with forth has always been the curmudgeonly-ness of the community, it's like they feel compelled to do things at exactly 180⁰ to how the rest

• armitron 4y ago
  This is one of its greatest strengths. The Forth community, large parts of which treat Forth as a secret weapon of sorts, has no particular reason to make concessions on the altar of popularity. This attitude helps to attract out-the-box thinkers and people with a tendency to go against established norms. The SVFIG meetings have been traditionally excellent in showcasing these somewhat unique in today's mainstream programming culture strengths.
• uonpopular_th 4y ago
  [flagged]
• zozbot234 4y ago
  It's important to realize why the computer industry works a certain way and how that compares to different approaches. For instance, there's very real issues with stack machines when you try to generalize them to parallel programs - including extracting fine-grained parallelism from sequential code. The most elegant approach is probably dataflow, but that's still a far cry from the simplicity of the FORTH-inspired, concatenative approach. The register-based CPU's we use are a pragmatic, middle-of-the-road approach.
  • jvanderbot 4y ago
    This appears very insightful, but I can't grok the differences. Got an explainer handy that I and others might start with?
  • kerkeslager 4y ago
    I agree with your larger point that there are important reasons that the industry works the way it does. However, your example that stack machines have some difficulty with parallelism, doesn't make much sense. I'd argue that on the contrary, parallelism is one of the areas where stack machines and Forth-y languages shine. arrayForth/colorForth is sort of the assembly language for GreenArrays chips, for example (GreenArrays chips are specifically built for parallelism in embedded systems). I'll also note that many VMs are stack machines, including Lua's and Python's, and these languages are the certain way and how that the computer industry works. Both these languages compile to a bytecode that looks suspiciously like a forth if you write it postfix (Lua moreso than Python, as Python makes use of environments which aren't Forth-y, while Lua only does that for globals). I think the person you were responding to was pointing out that the Forth community departs from industry norms in cultural ways, not in technical ones. I don't think Forth is really that far outside industry norms, it's just more appropriate to compare it to assemblies and bytecodes than to compare it to high-level languages.
    • zozbot234 4y ago
      GreenArrays use manycore chips based on a processor array approach. So they're using a FORTH-like stack machine on the individual cores, running serial code and not addressing much memory - but that still leaves open the problem of programming the system as a whole. > it's just more appropriate to compare it to assemblies and bytecodes than to compare it to high-level languages. But the FORTH community thinks of it as a high-level language, not just as a machine target. And there are additional difficulties wrt. thinking of FORTH in such terms, such as FORTH being an untyped language and providing only limited ways of structuring programs and data, or enforcing modularity. This means that it will probably be quite hard to develop larger programs using FORTH.
      • t-3 4y ago
        > This means that it will probably be quite hard to develop larger programs using FORTH. "Whenever I hear people boasting of millions of lines of code, I know they have greviously misunderstood their problem." - Chuck Moore Forth is a concatenative language, it transcends/spans categories like "high" or "low level". Typing is trivial to add to the language, but tends not to be common simply due to most Forths being used for embedded development. Structure is also quite free compared to most other languages.
  • tailrecursion 4y ago
    In the case of fine grained parallelism, where named registers allow parallelism that a rigid stack evaluation doesn't -- one can decode the stack instructions using a counter, the stack pointer, assign register numbers off the counter, and generate register-based micro-instructions that can be executed out of order or in parallel in the usual fashion. In this scheme the stack is stored in the register file, and the execution unit (or register-fetch phase if you prefer) has random access to registers.
• shaunxcode 4y ago
  I personally really enjoyed the site layout choices. I viewed it on a phone and it was like you are given a little chunk of info to think about as you scroll to the next.
• throwaway14356 4y ago
  every topic people gather around evolves it's own unique community. The topic is a constraint but it only slightly shapes the culture, the biggest influence is its previous form. This process is far more interesting than any other topic!
• pasquinelli 4y ago
  yeah, forth and the array languages feel like they've developed in isolation for decades. but i find that incredibly interesting.
• davegauer 4y ago
  Please note that these are slides for a talk. Regular web page in the works!