CAUTION The logiqub is experimental technology. You are the only one responsible for any consequence resulting from its use. Check license terms.

The logiqub is a scripting language designed to be:

In the style of the Forth language, it is an assembler for a virtual stack machine. Because of the design, features common in other languages are purposefully left out:

The main problem when designing a language is that everyone has different needs. Therefore it's impossible to provide a solution that perfectly suits everyone anyway. Trying to do it would bloat the system, and add a lot of uneeded complexity. People undervalue the benefits of not having to deal with existing code. Less code also means less bugs, less maintenance and more fun.

Why? Because reinventing the wheel to learn how things work is fun. Do you know how a random number generator, a square root function, a pahtfinding algorithm or a chess engine is written? That is what the logiqub is about: challenging yourself to understand how the most interesting (and sometimes useful) programs are done. It's a bare bones, do it yourself system. You are expected to modify it and extend it to suit your needs.

If however, you feel like you really want to use a more feature complete system, take a look at Factor.

They have done an incredible work to promote the style of concatenative languages. And like me they take inspiration from Forth, Lisp and Smalltalk. They are also very knowledgable about virtual machine and compiler construction. The primary difference is that the logiqub is focusing on simplicity, efficiency and agility. Just compare the distribution size and the complexities of the vocabularies.


The main purpose of this system is application development and scripting on multiple platforms. Stability is not important, if that prevents evolution towards a better design. Expect the API to break all the time without notice. Aside from that, more applications, tutorials, and videos will be added over time, so people can take inspiration from the examples and implement their own ideas.


The logiqub virtual machine code is 100% hand written assembly code. The instruction dispatch technique is direct threading.

100 million increments

  interpreter | seconds | command
  luajit      |    0.18 | luajit 1to100M.lua
* logiqub     |    0.30 | logiqub 1to100M.qub
  pypy        |    0.80 | pypy 1to100M.py
  tcl         |   17.17 | tclsh 1to100M.tcl
  python279   |   19.05 | python2 1to100M.py
  lua5.1      |   20.00 | lua 1to100M.lua
  python342   |   34.47 | python3 1to100M.py3
  mit-scheme  |  134.17 | mit-scheme --quiet < 1to100M.scm
  tcl-naive   |  274.00 | tclsh 1to100M-naive.tcl
  dash        |  967.00 | dash 1to100M.sh
  bash        | 3200.00 | bash 1to100M.sh

50 million procedure calls

  interpreter | seconds | command
  pypy        |    0.28 | pypy call.py
  luajit      |    0.34 | luajit call.lua
* logiqub     |    1.44 | logiqub call.qub
  lua5.1      |   11.53 | lua call.lua
  python279   |   19.90 | python2 call.py
  tcl         |  650.00 | tclsh call.tcl
  mit-scheme  |   ??.?? | mit-scheme --quiet < call.scm
  tcl-naive   |   ??.?? | tclsh call-naive.tcl
  bash        |   ??.?? | bash call.sh


Bigger system based on bytecode have a lot of overhead. Because decoding bytecode is inherently slow, people created Just-In-Time compilers (although a more recent trend is towards Ahead-Of-Time compilation). In all cases there is enourmous complexity overhead and waste of resources. Small and fast is always better, if you can afford the time to think about what you need to solve your problem. The logiqub is a proof is that. The raw executable size is about 35 kilobytes.


Based on the Forth language, the logiqub's simplicity and efficiency in translating ideas into executable code makes it nearly universal. There is no need to create dependencies by using another language or complex technology to:

You can use a single language to do everything, without having to mix in other languages, because you have the ability to redefine its semantics and create your own Domain Specific Languages within the base system.

By understanding what you need and focusing only on that, you can solve most small scale problems, while keeping everything under control. After defining the words that describe your application's domain, you can begin testing those words individually and iterate on the design very fast.


Windowsx86 32bit
Linuxx86 32bit
RaspbianarmV7l 32bit


The foreign function interface is not automated (as you should expect). Still, a number of C libraries have been tested, with more to come.


The logiqub provides a C header file to use its capabilities as an external library.


Graphical applications are designed to run with a console to type commands while the application is still running. This helps with testing and debugging. It's also very easy to change the application's state since the same symbols declared during the edition phase are available. No need to compile with debugging symbols and then attach a debugger.

compiled:    Design/Edit, Compile/Link, Test/Debug
interpreted: Design/Edit, Test/Debug

A shorter development cycle increases productivity, and gives you to time to focus on design and debugging. It is not apparent immediately, but if you imagine that the logiqub is compiling while executing, you will understand what I mean. The trade-off between speed of edition and speed of testing, while keeping resources usage low, is just the best I found.