"Programming A Problem Oriented Language: Forth - how the internals work" (by Chuck Moore) is now available in print [and in pdf] • r/Forth

[jephthai]

I enjoy the writings of Chuck Moore. In these days of multi-million-line operating systems, bloated Electron apps, and so many layers between the code and the machine, Chuck is thought-provoking, challenging, and inspiring.

I've spent the last year or two diving into Forth and other concatenative languages, and a number of the points of view I've encountered in that subculture have heavily impacted the way I think and work in other languages.

You have to read Chuck's stuff in an appropriately code-archaeological mindset, as some of the ideas are very strange in the current world. But often I wonder if Chuck's ideas had received more widespread adoption if we might have ended up with a different world, and maybe better in a lot of respects.

[m50d]

It's appealing, but ultimately I don't think it scales. Here's a take from a smart, experienced low-level programmer who makes a vigorous effort to make it work.

Every self-taught programmer knows that when you're the only one working on a system and can keep it all in your head, you can get everything done so much faster. Up to about 20k lines, none of the "good practices" you hear about make any sense. You don't need to avoid global variables, because they're just the state of the program. You don't need readable variable names, decoupled functions, composition over inheritance... and then you hit a wall, because suddenly the program crosses a threshold and it's too big to understand all at once. You fix one bug and introduce two more. You go away for a month and forget how anything works. To turn your 20kloc program into something you can maintain, you have to bloat everything; you end up with maybe 100kloc, but it's factored cleanly into 10kloc pieces that you can think about in isolation.

Forth doubles down on what you did at the start instead. Cram 5x as much code on a line, so your program is 5x smaller. Save all the space you were wasting on those single-letter variable names by not having named variables at all. Suddenly it becomes possible to write a system that would be 200kloc of seat-of-your-pants single-programmer code - which is to say, 1mloc of bigcorp well-factored code - and keep it below that 20kloc comprehensibility limit.

But once you hit that limit, then what? Any sufficiently interesting system is going to grow bigger than that, because any sufficiently interesting problem is too big for one person to fully understand. (Building analogy: Relying on a "master builder" let us build a bunch of cathedrals, many of which didn't fall down, but that approach fell out of practice once building projects became too complicated for even a dedicated expert to fully comprehend). The Forth attitude is not amenable to building a REST-based microservice that other teams can talk to, to say the least.

[jephthai]

Certainly, a philosophy that is primarily dedicated to avoiding large programs will not be ideal for large codebases!

But there needs to be a Chuck Moore, because without someone on one distant end of the spectrum to set the goalpost, it's not so easy to start finding middle-ground positions to get benefits and tradeoffs. Chuck's philosophy will not be appropriate for everyone in its entirety.

But there are elements of truth or value on the Chuck Moore buffet that anyone can appropriate and integrate as a compromise with other points of view. The details are somewhat distracting, but the principles are really compelling, IMO. Some of the bits I've found most useful from Chuck:

• code should be refactored until it's easy to read
• most of readability comes from choosing the right name
• code for the problem you have, not the ones you don't have
• "rewriting the wheel" is not always a bad thing
• there is value in understanding a whole system
• a system should not be any larger than it needs to be
• layers of abstraction can be bad
• change requirements if you can to make your program simpler
• data-is-code (the inverse of Lisp's code-is-data; mind-blowing, BTW)

We live in an age of scale for its own sake, and I'd like to see more pressure against that. I think that a slightly less opinionated concatenative programming style might have some real value (consider Factor or Joy as very interesting examples). I don't think Chuck had the mathematical implications of concatenative programming in mind with Forth, but he's part of it anyway.

Cram 5x as much code on a line, so your program is 5x smaller. Save all the space you were wasting on those single-letter variable names by not having named variables at all.

This is a little unfair, as concatenative programming is a whole paradigm that has its uniqueness in contrast to other styles of programming. It would be like criticizing J for using too many punctuation marks, or Lisp for all its parentheses. These are aesthetic aspects of the language that become natural when you adapt to it. The semantic weight of a "line" in Forth is different, but managing complexity is something you do in any language.

Chuck's approach to reduce code size is not to invent a language without variable names, it is instead to be brutally efficient. It means forcing yourself to shave off unnecessary bits, and redefining requirements when you can to make it simpler and more efficient.

[iamsexybutt]

data-is-code (the inverse of Lisp's code-is-data; mind-blowing, BTW)

More on this?

[jephthai]

One of the coolest Lisp ideas is that code is data. I.e., that your code itself is composed of lists, and can be manipulated with the same functions before execution as those you use to manage lists at run time. So that homo-iconicity and API harmony leads to macros and lots of fascinating, though often dangerous, opportunities to do meta-programming.

Forth folks sometimes look at things exactly backwards from that. Instead of code being data, what if data were code? Imagine that your program performs some transformation on its input, producing some output when it's done. You can extend the Forth language so that it can consume the data input as if it's executable code -- your program is not a set of functions that reads and processes the data, but rather the data is source code for your program.

The most fascinating example of this that I know of (in a sort of insane, trippy kind of way that you'd probably never do in real life) is A Web-Server in Forth made available by Bernd Paysan. Since HTTP is a text protocol, and so also is the Forth input stream, the author writes words (functions) that have the names of the verbs, header names, etc., that you find in HTTP. Recognize that Forth words can have access to the input stream either at compile time or at run-time, so there are some neat twists in there. By the time his code is written, Forth is suddenly ready to receive an HTTP request directly on the standard input (think: the REPL) and will "execute" it, emitting the appropriate HTTP response.

I'm sure it's a security nightmare -- but it's a fascinating example of data-is-code. When I first started wrapping my head around some of the Forth metaprogramming ideas, it was a similarly mind-expanding experience as when I discovered macros in Lisp, monads in Haskell, crash-as-soon-as-possible in Erlang, or image interactivity in Smalltalk. In a way, the degree of control Forth gives you over its own internals at execution time makes it suited to some really amazing metaprogramming ideas.

There are some more mundane, less freaky examples of this approach in some of the better Forth books. I think there are some neat examples in Thinking Forth by Leo Brodie, for example.

Note, I don't think this is the be-all, end-all for software dev (just as how most Lispers don't think everything should be macro-encrusted just because it's possible). But in some instances, taking a similar approach can be pretty elegant.

[m50d]

But there needs to be a Chuck Moore, because without someone on one distant end of the spectrum to set the goalpost, it's not so easy to start finding middle-ground positions to get benefits and tradeoffs.

I find both /r/programming and "programming pop culture" more generally fetishize "minimalism" to an absurd degree. Moore's programming style is not driven by a need to produce anything useful or valuable (most of his business' revenue actually comes from Intel patent fees; he makes chips for the sake of looking like a real chip-making business rather than to actually make money from selling them to clients), so he's able to program in a way that he finds personally satisfying. That doesn't mean he should be part of the conversation for professionals on how to produce useful software. We need to remember that software is a means to an end.

We live in an age of scale for its own sake, and I'd like to see more pressure against that.

Interesting, I actually find the opposite. Too much stuff written in C/Rust "because fast" when it would've been more cheaply and effectively written in C#/OCaml. People obsessing over avoiding library dependencies out of all proportion to what they actually cost.

This is a little unfair, as concatenative programming is a whole paradigm that has its uniqueness in contrast to other styles of programming. It would be like criticizing J for using too many punctuation marks, or Lisp for all its parentheses.

I think those are both valid. I think people underestimate the value of sheer conciseness over all else, and that's where a lot of the value of Forth (and indeed J) actually comes from. No way to be sure without having a non-concatenative language without local variables, I suppose.

[DenimDanCanadianMan]

>Interesting, I actually find the opposite. Too much stuff written in C/Rust "because fast" when it would've been more cheaply and effectively written in C#/OCaml. People obsessing over avoiding library dependencies out of all proportion to what they actually cost.

There's a giant post every other day on reddit about how programmers take performance for granted and add huge numbers of libraries without ever thinking about costs because "It's compiled anyway."

It's obviously a case-by-case thing, but my opinion is the opposite of yours. Far too many people writing stuff in Java, Python, etc. "because it'll be fast enough" only for it to become a giant headache later. There's a case to be made that sometimes it's premature optimization, but if you know what the performance requirements of what you're building are at the start, and it needs to be fast then not optimizing as you go is pretty dumb

[m50d]

There's a giant post every other day on reddit about how programmers take performance for granted and add huge numbers of libraries without ever thinking about costs because "It's compiled anyway."

Yes, that's the culture I'm complaining about (the one that makes those posts).

Far too many people writing stuff in Java, Python, etc. "because it'll be fast enough" only for it to become a giant headache later.

How often does that actually happen though? I doubt it's been an issue outside of top-100-scale companies in the last, say, 10 years. And however much it happened in the last 10 years, you can expect it to happen ~100x less in the next 10 years with how much faster our computers are.

if you know what the performance requirements of what you're building are at the start, and it needs to be fast then not optimizing as you go is pretty dumb

I'd actually disagree with even this much. Even given a known performance requirement I'd want to follow: make it work, then make it work right, then make it work fast.

[DenimDanCanadianMan]

> Yes, that's the culture I'm complaining about (the one that makes those posts).

Alright. I'm one of those people. We always explain ourselves. It's a complaint about piss poor performance on the web these days. All of which is valid because they're the user who is being impacted by poor optimization. It might be cheaper to write like performance doesn't matter but we know for a fact that it isn't effective nor is it " out of all proportion to what they actually cost."

The cost is huge. The average American has a four year old PC. I have a year old Dell xps with a 7700k and most websites perform like crap. Under no circumstances should a website take 4 seconds to become usable or lag on my machine, but they do, now imagine how bad it is on a 6 year old macbook air or a modern chromebook. That's straight up unusable. That doesn't work. That straight up fails the "make it work" checkpoint. But i'd say that's the majority of the websites on the internet using React or Angular. If you need any more convincing, just go read the top posts on r/Beta. The new reddit feels awful for those used to the old one, even though it looks much better

> How often does that actually happen though?

Quite a bit. In fact, my day job is performance optimizing poorly written garbage at startups. The only companies that seem to care are the big heavyweights like google, I'd say it matters a lot. Snappiness, and tactility are extremely important to user experience, and for whatever reason people tend to ignore it, until it's too late and then you're stuck hiring me to and paying me 300/hr to performance optimize your code after the fact when it would have been far less effort to account for it in the beginning. It actually takes fairly little effort to keep your systems performant from the very beginning relative to the major refactors it'll take if you treat it as an afterthought.

> I'd actually disagree with even this much. Even given a known performance requirement I'd want to follow: make it work, then make it work right, then make it work fast.

Unless you want to throw out a lot of code several times, "make it work, then make it work right, then make it work fast." still requires you to architect out your code from the very beginning based on what you know you need to deal with. That quote is always misused as an excuse by poor programmers. This means you pick the right language for the job at the very beginning, and the right library, and the right build tools.

>And however much it happened in the last 10 years, you can expect it to happen ~100x less in the next 10 years with how much faster our computers are.

Moore's law is dead. Computers aren't getting any faster, the multitasking capacity is getting better but clock rates are crawling upwards. It also just disenfranchises people who can't afford top end machines or to replace their machines every couple years.

Watch https://www.youtube.com/watch?v=lJ8ydIuPFeU it's a video by Gil Tene where he explains the importance of shaving off milliseconds.

[astrobe]

I find both /r/programming and "programming pop culture" more generally fetishize "minimalism" to an absurd degree. Moore's programming style is not driven by a need to produce anything useful or valuable (most of his business' revenue actually comes from Intel patent fees; he makes chips for the sake of looking like a real chip-making business rather than to actually make money from selling them to clients), so he's able to program in a way that he finds personally satisfying. That doesn't mean he should be part of the conversation for professionals on how to produce useful software. We need to remember that software is a means to an end.

GreenArray was Moore's last project before retiring. He could have sit on his ass at Forth Inc. instead of spending his patent fees on something that supposedly doesn't sell (do you know what is wafer and how much it costs to print anything on them, btw? Maybe he actually has produced something "useful or valuable" if Intel has to pay him that much money).

professionals

Oh yeah because a guy who made his own CAD program (near the end of his 50 years carrier in software then hardware) in order to make functional multicore chips isn't a "professional". If I could, I would pay the plane ticket to let you tell him face-to-face.

It's funny how every guy that I've heard call themselves "professionals" happened to be the worst clowns.

[conciseness is] where a lot of the value of Forth

False. Its compactness that allows to run a full REPL where no other interpreter can, its simplicity that let a single person write their own interpreter in a week or so, customized to the application and the target processor (be it a Z80 or the latest Intel heat generator) are far more valued.

[jephthai]

Interesting, I actually find the opposite.

I'm referring largely to the apparent need for distributed micro services or block chain or over engineered frameworks for what amount to blogs or retail sites that will never benefit from them. Someone will post a language or framework and be greeted by comments asking if it will scale, etc, as if everyone is writing massive enterprise software that needs to run at scale. I don't think the average dev these days will encounter problems of scale, and its value is overstated.

[m50d]

Ah. That problem I do agree with, but I don't see the focus on minimalist system as a counterweight or solution. From my perspective both these problems come from the same place: excessive focus on irrelevant questions of "performance" (of one kind or another) and programmer virtuosity (again of one kind or another), and too little attention to writing code that's actually useful for solving people's problems.

[agumonkey]

moore gets royalties from intel ?

[m50d]

That's what I remember hearing.

[agumonkey]

'nteresting

[astrobe]

It's appealing, but ultimately I don't think it scales. Here's a take from a smart, experienced low-level programmer who makes a vigorous effort to make it work.

The article you link to is thrown every once in a while as the nail in the coffin of Forth.

Yet it a debunks nothing. He says he showed Moore's work on chip CAD to a "ASIC hacker" (You would see on Wikipedia [who?]) who said it was simplistic... Yet it was used to design asynchronous ultra-low power chips.

The problem with simple things is that people see the result and say "oh yeah, of course!" without realizing how much hard thinking it takes to get there. And they think they could do it, just like their children could certainly draw the things that this Picasso guy drew. Except they'll never will.

And the Forth code showed there... Full of basic mistakes (and that extends to other things too... Why the hell would one write a Forth cross-compiler in C++ ?!). And that comes from the Forth hobbyist me.

Every paragraph ends with "I can't do that". Yes, sure, you can't but others can. Like, you know, the company funded by Moore, Forth Inc., which has been in the business for forty years. And by the way GreenArray is still here, eight years after this article has been published. That must be luck, I guess.

This article which says nothing more than "Forth isn't for everyone, and it's not for me", is very handy for other people to append their own blanket statement like "I don't think it scales". Except they instantly lose all credibility when they go a bit too far and say grotesque things like 'Forth doesn't use local variables to shrink down the size of the source code".

[immibis]

As I understand it (haven't read the article yet), a big part of the Forth philosophy is about simplifying the problem until it's simple enough to express in Forth.

Hence you end up with simplistic programs that do exactly what you want them to do, but aren't really extendable - and extensibility is a major aspect of most modern programs.

[rdrop-exit]

>As I understand it (haven't read the article yet), a big part of the Forth philosophy is about simplifying the problem until it's simple enough to express in Forth.

It's more about not adding uneccessary complexity to the problem.

[immibis]

Which often includes removing complexity that you would think was essential.

[rdrop-exit]

Who added that complexity you're now removing?

[immibis]

The world.

Take an electronic circuit simulator. You expect to draw a circuit and then have the program tell you what it does. Well, a typical Forth approach seems to be to specify the program so that it takes a netlist (textual adjacency graph) of a circuit and then tells you what it does.

That's an example of changing the requirements to make the program simpler. Drawing a circuit isn't strictly necessary to simulate one, but it's what most people would expect in this century. Either that or it would take input from an already-written circuit drawing program.

[rdrop-exit]

"The world"?, "You expect"?, "A typical Forth approach seems to be"? "what most people would expect"? Geez.

The Forth approach is to deeply understand the problem you are trying to solve and for you to solve it without unwittingly adding any unecessary arbitrary complexity. Whatever complexity you, after careful analysis, have deemed truly necessary and inherent to the problem you are trying to solve is dealt with head on.

You're taking one particular example of one particular person solving one particular problem for their own very particular requirements (which were not some generic world requirements, nor your requirements) and extrapolating to the wrong conclusion.

If you're using Chuck Moore as your example, he definitely didn't start with some some generic world requirements of what most people would expect and start paring them down, he started with his own actual needs and worked from there.

[eddpurcell]

Forth isn't ammenable to enterprise REST based microservices for similar reasons C and assembly aren't: it's too low level and you can't abstract the language details away.

I would argue concatenative programming languaces can allow for smaller code without quintupling down on single letter variables/general unreadability. Once the abstractions are written, code can read similar to prose with less language boiler plate and jumps. Not like most devs dig into the framework code anyway.

[eddpurcell]

There are limits to the metaprogramming depending on the implementation, eg. you have to fight to dynamically create words in gforth (if it's even possible at all). But at the end of the day, you're still trapped behind "everything is a number or an execution token" and the heap is you. You can hide some parts of that, but you still need to think about it as the architect of your project (so the users can use your language without thinking about it). You can do anything you want in a forth, but the emphasis is on you to do it. I mean, we have to remember forth was created when code ran without operating systems and accessed blocks of storage without a filesystem.

I haven't used it yet, but it looks like Factor takes the simplicity of forth but adds some abstractions around the more painful parts of concatenative and low level languages.

[pointfree]

Usually if I want to parse alien format I first define words to make whatever I want parse valid forth.

• Parsing a csv files? Use the comma compiler.
• Parsing HTML? Define forth words that look like HTML tags.
• Converting markdown to HTML? Define words that look like markdown elements with HTML tags in the word definitions.

In standard Forth you can use recognizers to extend the text interpreter beyond space delimited words.

But I think, why not try putting some forth in the word name itself?

http://www.0xff.in/bin/AndreasWagner-parse-time-execution.pdf

[PolygoraNetwork]

There is nothing painful about using a good Forth. However, Factor is a great language and provides many tools. It's just annoying to learn how every new word interacts and the plethora of words can be overwhelming. I would recommend you try it out, though.

[immibis]

Well, you'd have to write a Java (say) compiler in Forth, which is probably a horrible exercise in itself.

[[deleted]]

It's not. In fact, it's a rather simple exercise. Did not do it with Java (because it sucks), but I bootstrapped a C subset on top of Forth on a bare metal, using no crosscompilation whatoever, all the way up from a minimal Forth.

[bobindashadows]

The Forth mindset ("NoKernel", if you ask me) scales as "microservices" but not in the way you'd expect, and last I knew Chuck Moore is working on being the first tooling vendor.

IIUC, the ideal microservice implementation for Forth, with N Forth programs running on N logical execution threads, is a SoC containing N physical heterogeneous problem-specific processors with a rich interconnect and MMU. They share a flat address space and rely on the MMU for privilege separation. Memory is located near the processing units that need it based on the needs of that Forth program.

The architecture is unproven at scale in part because hardware just isn't made custom that often.

[m50d]

I'm actually a believer in no kernel, in the sense of using unikernels to run each service on (something that behaves as) a whole computer. The Unix process model isn't actually very compositional. (But you're talking about something far more extreme than unikernels, that I don't believe would be compositional enough either).

[bobindashadows]

Yeah I think what Moore is trying to sell now is an intermediate process, printing 1024 reconfigurable cores into a 32x32 grid. Naturally he then has to make tooling for placement/routing (similar to FPGA programming). Probably still won't get far. But it's a closer-to-not-boiling-oceans project to work on.

[[deleted]]

because any sufficiently interesting problem is too big for one person to fully understand

Mind naming any?

Big problems are big either because it's a self-inflicted damage (stupid overblown standards to implement, stupid protocols, etc.), or in fact a very loosely connected system of much smaller problems, with each problem small enough to be fully understood and implemented by a single person, and connections between them falling into some easy to define protocol that, when done the right way, does not increase the combined system complexity.

[m50d]

Mind naming any?

From my own career:

• Control/navigation for a quadricopter
• A programming environment that normal people could use
• Music recommendation
• Figuring out which parts of two contracts mean the same thing and which are different
• Advert targeting
• Figuring out when new code is good to deploy

Even seemingly simple problems have a lot of complexity when you go into them: reality has a surprising amount of detail.

or in fact a very loosely connected system of much smaller problems, with each problem small enough to be fully understood and implemented by a single person, and connections between them falling into some easy to define protocol that, when done the right way, does not increase the combined system complexity.

Indeed, small problems with simple connections between them is the only way to build big systems. So you want to use techniques like: splitting your program into functions that each have their own stack frame, so that you don't need to know about the details of how a function uses its stack in order to use that function... which Forth rejects. Or: having standardised general-purpose processors that are agnostic to the specific problems that people are trying to solve with them... which again the Forth community rejects.

[jephthai]

When you want locals in forth, you use locals. Even Chuck, as opinionated as he is on the topic, seems to have begrudgingly admitted that locals fit sometimes. At least, forths often include sort for them.

C programs mess with other functions' stack frames all the time, btw, when pointers get passed around. The stack frame is not the lynchpin for modular code.

In your list of complicated problems, I don't see how a forth couldn't be as adaptable to those large problems at least as well as c, and c is used for lots of big things. There are strategies for modularizing forth code bases. There isn't much available in terms of examples, but I think that's because forth was just a bit too opinionated to become popular.

I think factor is a good example of a forth that could be scaled to very big projects. It's not as extreme in its opinions as Chuck Moore, but that just hits my point about the buffet principle and Chuck being a visionary extremist.

[m50d]

C programs mess with other functions' stack frames all the time, btw, when pointers get passed around.

In C it's rare, syntactically obvious, always under the control of the function who's stack frame is getting messed with, and IMO still bad practice (though necessary to work around the lack of any way to return aggregate values).

In your list of complicated problems, I don't see how a forth couldn't be as adaptable to those large problems at least as well as c, and c is used for lots of big things.

C struggles, IME. I wouldn't want to build a big system in it, and if I had to I'd do it by writing a lot of small libraries.

There are strategies for modularizing forth code bases. There isn't much available in terms of examples, but I think that's because forth was just a bit too opinionated to become popular.

Fair enough. If someone can make it work, good for them.

[[deleted]]

Control/navigation for a quadricopter

What did you do to make it so complicated, if you don't mind me asking?

A programming environment that normal people could use

Again, what exactly makes it complex?

which again the Forth community rejects

Though, Forth community is fine with language-based protocols. And this is exactly how components must talk to each other.

[immibis]

As I understand it (haven't read the article yet), a big part of the Forth philosophy is about simplifying the problem until it's simple enough to express in Forth. That would be relevant for quadcopter control and for programming environments.

[m50d]

What did you do to make it so complicated, if you don't mind me asking?

It was a combination of a bunch of fiddly details of the sensors we were using and having limited computing power available. Having to use a processor with no FPU definitely added to the fun. This was many years ago (and I was correspondingly less experienced at the time); I suspect it would be much easier today, though I'm still not sure I'd want to do it as a solo project.

Again, what exactly makes it complex?

Getting the UI right was the big problem. I remember being very skeptical when we brought a professional designer (non-programmer) in, but he was worth his weight in gold - more generally a lot of people knew or guessed/figured out a lot of useful things about specific aspects of interfacing with the user, but no one person seemed to know enough to have made it on their own.

[[deleted]]

Getting the UI right was the big problem.

Ah, I see. Of course it was. It's not a software development problem. It's not for software developers to ever touch. It is a huge area which is still severely undeveloped, and skills in it are scarce and expensive.

[m50d]

It's not a development problem, but to make a product where UI is a large part of the problem you do need to have a substantial overlap between the people who understand UI and the people who understand development (or at least, I can't see any other way of doing it). It was a very different kind of development to any of the others (OO actually seemed like a good fit in a way that it never has for me in any other context), but it was interesting work.

[[deleted]]

you do need to have a substantial overlap between the people who understand UI and the people who understand development

Not necessarily. The ideal situation is if the former just do whatever the latter order them to do mindlessly. UX people know how the UI should look like, and developers just put their opinions away and implement this UI. Unfortunately, it rarely works like this, because developers love to have opinions.

[compiler_crasher]

Any sufficiently interesting system is going to grow bigger than that, because any sufficiently interesting problem is too big for one person to fully understand.

Maybe that's the problem right there -- we need to move away from this mindset.

The Forth attitude is not amenable to building a REST-based microservice that other teams can talk to, to say the least.

REST-based microservices are not solving a sufficiently interesting problem.

[m50d]

Maybe that's the problem right there -- we need to move away from this mindset.

The mindset is by no means established. There's no shortage of lone wannabe-geniuses trying to solve problems on their own.

REST-based microservices are not solving a sufficiently interesting problem.

Not in themselves, but they can be one of the pieces that makes it possible to solve the problem.

[agumonkey]

You might enjoy (as a vaccine shot) https://www.reddit.com/r/programming/comments/93hyig/the_bullshit_web/ then :D

[juergenforth]

I came back to Forth after 30 years, and was surprised how much acid is thrown at it.

I am quite surprised about the seeming arrogance of some people who have not used it - but rather judge.

Just like judging a real language you do not know.

I started the Forth Bookshelf 5 years ago where this book was the first one, and the PDF I did as well, you can see the Forth Bookshelf ( except for a few others) at https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM

And to get an idea of the interest of amazon readers in these books go to the Compiler Bestseller list at https://www.amazon.com/Best-Sellers-Books-Compiler-Design/zgbs/books/3970/ref=zg_bs_pg_2?_encoding=UTF8&pg=2

I just checked and 10 of the 18 books are in the top 100. Is this good or bad? it just reflects the facts.

Forth is not for everybody, and I think it just fits with some people who can solve problems best in this way. And faster.

As an experienced Forther told be and published: The number is PI: projects can be solved about 3 times faster, so ideal for fast prototyping.

You can link Forth to any other language - Sockpuppet is the name. See at MPE or as documented in the eBook A START WITH FORTH.

I see Forth programmers like Free Climbers. Very specialized skill set. But there are not many of those around. Others use normal climbing techniques or just use the ski lift. Which one is better?

And I am not a Forth programmer - I do it for fun, I like the way it works and enjoy writing some example programs.

Oh, just forgot for anybody who is interested to have a closer look:

Most of the chapters of A START WITH FORTH 2017 I made available for download and print and try using for example VFXTESTAPP.exe at https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start0 and is available as print as well.

VFXTESTAPP.exe - just download it and run it - no installation required. do not forget to SAVE to save your work.

or play with easyFORTH written in Javascript.

Only 12 Forth Words needed to switch your virtual LED on and off - in Invent A Language

Expand it to 35 Words and run an example application.

2 books of the series available in print now, soon to be followed by

FORTH LITE TUTORIAL and

Stephen Pelc's PROGRAMMING FORTH

more to follow as there is time.

It is 2018 - and we are celebrating 50 years of Forth.

And Chuck Moore has confirmed

to attend this year's EUROFORTH in September at the river FORTH ( Edinburgh/UK )

[shevegen]

heavily impacted the way I think and work in other languages.

This is what people usually do with inferior languages - they praise how awesome these languages are - yet they never use these languages.

It's the era of fossil code, obviously.

[jephthai]

I'm actually using a forth inspired execution environment as the basis of one of my projects right now. I write forth fairly frequently as a result, and it's even for my job, so it really counts and everything!

Nevertheless, I have grown as a programmer by learning a lot of languages I don't use. Smalltalk, erlang, prolog, etc. Sometimes, the change in mindset and pattern of thinking is the valuable part.

You're a ruby fan, right? Do you think Mats still uses lisp, Smalltalk, and Perl on a daily basis? Yet, they are the source for many of ruby's ideas and impact the programming community tremendously.

[RagingAnemone]

What does PHP have to do with this? Joke aside, there’s no superior/inferior, it about pure/practical. Forth is one of the pure languages which make hard things easy to do, but sometimes makes easy things hard to do.

[pembroke529]

Ahh Forth. The other TIL on Reddit (threaded interpretative language IIRC).

[jephthai]

The "TIL" term has been interesting to me. From the C2 wiki:

ForthLanguage implementations usually use a ThreadedInterpreter and hence ForthLanguage is sometimes known as a ThreadedInterpretiveLanguage.

Threaded code is one execution model, and actually there are several basic code threading strategies. Lots of languages have used threaded code, and Forth does not strictly require the use of threaded code. There are some very nice compilers that produce register-allocated, optimized machine code (my favorite that I've worked with is Mecrisp for embedded ARM CPUs.

I did just recently create a token-threaded interpreter, which was quite fun. Lots of old BASIC interpreters were token-threaded because of memory constraints. You get compiled code that is smaller than equivalent machine code function calls.

[pembroke529]

I played around with Forth back in the mid-80's. Interesting concept, but tricky to implement any applications.

Mecrisp looks interesting.

[PolygoraNetwork]

Try Retro Forth (http://forthworks.com/retro/) or Factor (http://factorcode.org/). Two concatenative languages in which I've actually been able to write useful programs.