71–80 of 97 posts
Anyone who wants to see a modern forth with elements of common lisp that is focused on application development should check out Factor. Concatenative languages are really fun to use once you get over the initial hump. https://github.com/factor/factor
>...what just ends up being some sort of Lisp with a funny notation.
Earlier quoted context omitted.
FORTH has both an "inner interpreter" and an "outer interpreter" (aka the compiler, but that also works interactively like an interpreter). The inner interpreter is the thing that threads between words, and is typically an assembly function named "NEXT", which can be just a few instructions. Here is the FIG-FORTH 6502 implementation of "NEXT" (which is a bunch of instructions since the 6502 has 8 bit registers and si…
Here's a cool dynamic WebAssembly based Forth: https://el-tramo.be/blog/waforth/ >The Interpreter >The interpreter runs a loop that processes commands, and switches to and from compiler mode. >Contrary to some other Forth systems, WAForth doesn’t use direct threading for executing code, where generated code is interleaved with data, and the program jumps between these pieces of code. WebAssembly doesn’t allow unstruc…
https://chrome.google.com/webstore/detail/postscript-viewer/...
I wonder if NeWS, or something similar, could be resurrected in-browser?
Forth style is great for writing but very hard for reading. I'm playing around with the idea that you use a Forth-like language to interactively develop code. The steps you perform become AST nodes. Then when you want to read it, it comes out in another form. This is more ideal because it is more interactive and you can see the immediate result every step of the way. This is different than writing traditional code be…
I have many ideas for such a system, but it will require much experimentation to get it right and, at this moment, is just vaporware.
Earlier quoted context omitted.
You define words which are like functions which you could use to operate on multibyte data. Most forth code uses large dictionaries of words. So it will look like 'dosomething decode bytes' where bytes is your utf8 and decode is some utf8 decoder and so on. edit: see https://rosettacode.org/wiki/UTF-8_encode_and_decode#Forth for a forth word for decoding utf-8
Looking at this Forth code as a programmer who has never written any Forth code, I can understand how "ordinary" code looks to non-programmers. That whole RPN business means I cannot even figure out where to start reading.
There are Forth words with generally agreed-on definitions but it seems it's not designed to grow a large, common vocabulary in the way that modern package managers enable.
The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…
When that is layered on top of overly generic libraries/frameworks, you may end up using only parts of the underlying vocabulary. Now the project is stuck with two vocabularies. Learning the generic one doesn't get you far and may be actively misleading ("yeah, we never use features X and Y of the framework, instead we've overridden Z with our own implementation that does all this plus W").
Can you please give some examples on those who are extremely productive using FORTH? I'm intrigued. I think FORTH could be very useful to someone who prefers to work alone or in small group, but I'm not sure how do they use it in daily life.
Mitch Bradley. He wrote the firmware for Sun machines, made an IEEE standard of it, open sourced it for OLPC. Highly productive guy. Interview with him seems to have disappeared from the web? http://mitchbradley.blogspot.com/2010/08/open-firmware-and-o...
The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…
The counterpoint is that every software project of reasonable complexity evolves its own language anyway. When that is layered on top of overly generic libraries/frameworks, you may end up using only parts of the underlying vocabulary. Now the project is stuck with two vocabularies. Learning the generic one doesn't get you far and may be actively misleading ("yeah, we never use features X and Y of the framework, inst…
The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…
Sometimes... you don't need to understand anyone else, or to be understood by anyone else. Sometimes you just want to do what you need to do.
The goal of replicating understanding is all well and good, but that shouldn't be the primary goal of programming language development, nor should it be the primary goal of programming.
I don't think that anyone is suggesting that we start rebuilding enterprise service frameworks in Forth.
The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…
The counterpoint is that every software project of reasonable complexity evolves its own language anyway. When that is layered on top of overly generic libraries/frameworks, you may end up using only parts of the underlying vocabulary. Now the project is stuck with two vocabularies. Learning the generic one doesn't get you far and may be actively misleading ("yeah, we never use features X and Y of the framework, inst…
But these problems are, in their way, a sign of success at the package management level. If you don't have good package management then people probably aren't having much success at sharing code.
We should still aim for building and sharing stable, well-understood, high-quality code libraries. Unfortunately, sometimes the way to get there is to go through a period of instability.