Прототипом Jfo является язык Forth, придуманный и реализованный Чарльзом Муром еще в начале 70-х годов.
Краткость, простота реализации и мощь языка Forth были взяты на вооружение при создании Jfo.
Forth всегда отличался от других языков - маленькое ядро (чуть более 5 Кб), возможность использования без операционной системы
на разных платформах и возможность "выжать" из него больше, чем на первый взгляд кажется.

Отправной точкой для создания Jfo послужила практическая необходимость.
В 1997-1998 годах, работая над клиент-серверным приложением, базирующемся на RMI протоколе, разработчики столкнулись со стандартной проблемой
- созданием огромного количества быстро изменяющихся отчетов и документов.
Естественно, создать новый отчет/документ на Java можно, но при этом требовалась перекомпиляция самого приложения, а пожелание отдельно взятого клиента, скажем, срочно изменить название колонки отчета, приводило к бесконечным модификациям и перекомпиляциям.
Стало очевидно, что необходим скриптовый язык, интегрированный с Java и оперирующий объектам Java, а также способ описания отчетов/документов.
Игорь Томасов (автор языка) в течении недели сформулировал и реализовал базовую версию Jfo.
Эта версия стало первой и получила обозначение Jfo v. 1.0.

Версия Jfo 1.0 расширялась, и в конечном итоге кроме отчетов/документов на Jfo были переведены и формы ввода данных.

Jfo v. 2.0 была фактически переработкой версии 1.0 и использовалась для тех же целей, плюс в одном из проектов на Jfo 2.0 производилась обработка SMS-сообщений,
приходящих в Web-приложение со стороны сервера мобильного оператора. В первых двух версия Jfo следовал стандартам Forth, лишь добавив интеграцию с Java.

Начиная с версии 3.0 Jfo все больше отклонялся от Forth, при этом, оставляя только принципиальные идеи.
В Jfo v. 3.0 появилась концепция декларации слов-примитивов, освобождения синтаксиса от большого числа предопределенных слов и использования префиксов.
Префиксы в частности должны были решить проблему создания строк. Вот так создавалась строка в Forth и Jfo v. 1.0-2.0:

Forxx is an extensible programming language for text manipulation inspired by Forth and REXX.

Thyrd is an experimental, reflective, visual programming language and environment. In Thyrd, both data and code are stored in cells situated in nested two-dimensional grids. The user interface animates the transition from a cell to its subordinate or superordinate grid to help keep the user oriented in the hierarchical grid structure. All operations the user can perform to edit the structure are implemented as operators in the Thyrd language, thus a Thyrd program can inspect and modify itself or other programs in the same space.

Thyrd is a member of the Forth family of languages. Thyrd is a postfix concatenative language most similar to Joy in that it uses quotation and combinators to implement iteration and recursion. The environment provides a viewer that animates the stacks of a Thyrd program and allows the program to be stepped both forwards and backwards.

The primary view of Thyrdspace is a 2D grid of text and icons. A view may be overlaid with a panel consisting of arbitrary widgets editing the contents of individual cells or an entire grid. A Thyrd application can be constructed in which all of the code and data are hidden behind panels and revealed only at the user's request.

Thyrd is implemented in Tcl/Tk and Poet.

ForthMinus is an alternative scripting engine for OpenSimulator. It's dialect resembles (loosely) the FORTHprogramming language and it's code runs within a Virtual Machine (VM). It's primary purpose was to test the feasibility of implementing a VM to handle the micro-threading of scripts as well as speed up the development of llFunctions for the main LSL script engine. It currently has some advantages and disadvantages versus the primary script engine (DotNetEngine):

Advantages:
Micro-threading - User scripts cannot lock up the Engine's threads. Perpetual loops can be created without fear of the engine becoming unresponsive.
State Saving - A ForthMinus script can be state saved thus allowing for script persistence through sim resets.
Security - All scripts are ran under the VM opposed to being compiled into CIL and ran in parallel to OpenSimulator (although AppDomain implements some security measures).

Disadvantages
100% NOT LSL compatible - It does not resemble LSL/C/C# at all.
Slower - Since code is executed interpretively, scripts are quite a bit slower than compiled CIL is.