What are /r/Forth's favorite Products & Services?

From 3.5 billion Reddit comments

I'm not the one getting triggered by this exchange. It's not that I like or dislike terms. You have clearly stated that you reject the field's standard definitions. I have simply pointed out that without the use of standardized language when interacting with other programmers how exactly do you expect them not to misunderstand if you're not using terms the same way?

You keep latching onto details and attempting to use them strengthen your position in your own eyes. Now you've resorted to insults. Your position is untenable and you are just doggedly refusing to accept reality. As for safe spaces you are the one demanding to be special by using your own personal vocabulary and insisting that people learn your terms rather than using standard terminology.

If you want a Forth like language that's higher level have you ever considered Factor? Forth is a low level language no matter what you personally think about it. It sits just on top of assembly.

Well there is always factor, if you haven't tried it. Arguably had more momentum than oforth or 8th, but the creator hasn't been working on it the last few years. Still a very nice language.

The previous two in this series are available here:

https://archive.org/stream/Forth_Dimension_Volume_19_Number_3#page/n15/mode/2up

https://archive.org/stream/Forth_Dimension_Volume_19_Number_5#page/n7/mode/2up

Does anyone have any more details on this, and or on SOD32 by L.C. Benschop? I gather that this Forth uses relative addresses in it's dictionary [header] but are there other advantages to this besides reduced memory usage?

I read that

> I used [SOD32 by L.C Benschop] (and its virtual machine implementation) as the basis of my own forth toy implementation. Maybe not the fastest forth ever, but clearly the most understandable I found. It even includes so-called "meta"-compilation.

https://groups.google.com/forum/#!topic/comp.lang.forth/_LImo85_0uU

I'm curious if the use of relative addresses has any impact on understandability?

Take a look at this: https://www.hackster.io/news/mecrisp-stellaris-port-brings-the-forth-programming-language-to-the-raspberry-pi-pico-rp2040-4c8e7077ae64 - that’s an open source native Forth compiler

I found this set of slides: www.forth.org/svfig/kk/11-2011-Nelson2.pdf

Also, you may be able to contact the author through this comp.lang.forth thread:

https://groups.google.com/forum/#!topic/comp.lang.forth/xg51FNmEtZ8

EDIT: http://bradn123.github.io/

I grew tired of dealing with x86 assembly under a variety of hosts, and wanted to be able to run RETRO on other architectures.

Rather than writing an implementation in C or another language, I decided to dust off a little MISC based VM I had written a few years back and rewrote RETRO (v10) to run on this. (This was in late 2008, with the first public release in January 2009). In mid-2011 I revised the VM a little and released RETRO11. R11 was very successful for me, with VM implementations in a variety of languages (C, C#, Java, ANS FORTH, Lisp, Scheme, Python, Ruby, Lua, Perl, and others). This was under active development until late 2014, and is still being supported through January 2020.

In 2016 I drastically simplified and rewrote the VM and wrote RETRO12 to run on it. This was initially to address a couple of things:

• complexity in the i/o handling on the old vm
• adding support for multiple instructions per cell to help with code density
• simplification of the minimal vm implementation
• allow for non-terminal based interfaces

I have a main implementation of the VM in C, with alternates in C#, Python, JavaScript, and recently x86 assembly. There's also some work being done towards AVR assembly implementations and one for the scripting engine used by https://godotengine.org/. All run the same basic system (written in assembly for the MISC instruction set), with host-specific features added. (E.g., on the x86 assembly version, there are I/O interfaces to the raw system memory and x86 I/O ports, so I can write device drivers that interact with the actual system hardware).

It's worked out very well for me. At this point, my personal set of tools is mostly RETRO12 based, with a few small bits using shell scripts and Python, though these are slowly being replaced. I also develop and support a set of browser based applications for my employer, with a growing amount of RETRO code replacing the old Python and PHP parts.

Would Common Lisp be a better starting point, given that it comes with bigint support? Then you could just edit your text files to cuddle the numbers with (list and ), and load them in exactly the same way...

Also there's a rather powerful free symbolic maths package available for it.