User:Eekee

I'm not the world's biggest fan of esoteric languages, but I love the feeling of getting a program working while at the same time, I have difficulty with complexity. Befunge-93 appeals with its the limited scope and 2D nature, you can just see program flow. Taking it up as an alternative to the mobile gaming I've been wasting my time on lately, I find Befunge-93 is a good game; perhaps a little too addictive! ;)

Funge-98 may be a little too complex. I'm not sure because I have problems with technical jargon. Jargon which is not well-defined can be incredibly vague, and I have problems with remembering definitions. Maybe I'll get the hang of it eventually.

Forbefunge project

I'm starting work on a small range of Befunge interpreters in Forth, but...

Befunge popped my ego! |:-1 lol I wrote a Befunge-93 interpreter in just 2KB of Forth code. I had it all tested and everything worked. It looked likely to work, with different Forth interpreters, on hardware ranging from the latest mobile devices to the original IBM PC and perhaps back into the 8-bit era. I was very proud of it indeed! Then, for the first time, I tried a program which output a string with a run of commas instead of a loop. I'm not a very big beer fan, but being told innumerable times that I have -1 bottles of beer was still not much fun. The Forth interpreter crashing was worse. What happened? When implementing stringmode I had assumed that strings were null-terminated, that stringmode pushed a 0 before pushing the characters. Not so. The hello world programs with loops rely on the interpreter supplying 0s on stack underflow. Forth supplies garbage or crashes. A good solution won't fit in the 128 bytes I have left in 2K Befunge, especially not when I also want to improve single-stepping.

I'll just have to make 3K Befunge instead. I think I'll keep 2K Befunge for my own use, remembering to add a `0` every time I use stringmode. I already have to add some `$` before exit to many example programs because they leave stuff on the stack. Also, it's size-limited, using a 1KB `block` for its program space, typically 64x16 chars. I could adapt the implementation of `block` which I wrote for PForth to have a larger block size.

The dream of working on a vast range of hardware is still alive. Futureproof and retrocompatible! ;) Forth standards change exceedingly rarely. Many still-available and some still-maintained Forth systems conform to the late-80s ANSI Forth standard. Saying "Future proof" is always a gamble, but the latest GForth supports Forth-2012 while apparently retaining all the definitions of 80s ANSI Forth. It itself runs on a wide range of systems including Android devices.

As much as I'd like full compatibility, I don't want to support Befunge programs which rely on line buffering to make input appear in the correct order. I found one such program and it was quite a surprise -- esoteric use of the operating system! ;) But still, Forth was designed to run natively, without an operating system, and wasn't designed for such buffering.

Incidentally, the emoticon |:-1 is the code which tripped over my spurious null terminator and deflated my ego. ^_^;