The cost is stupidly high, though. Look at the source code of [1].
The only good page to take from OOP book is the automatic and implicit pseudo-variable "self" or "this", that can reduce stack juggling significantly. I've implemented that in my (yet to be published) dialect and it works like a charm. In my experience, you can have that for cheap and anything more is not worth it from the point of view of a byte-counting Forth programmer.
Yeah, I didn’t mean far out as in good. Some people would say that the important thing to take from OOP is message passing. Which I assume is a no go in Fort? Regardless of dialect.
In communication protocols, you typically send a symbol which tells the receiver the meaning and the syntax of the message, and then the data attached to the message.
In technical terms, messages belong to different application protocol data units ("APDU"). The receiver typically uses the APDU symbol (which can be just e.g. a byte) to dispatch the message internally to the right processing routine.
Message passing in OOP is the same thing, and it's ultimately about late binding. Late binding has, indeed, as much presence as dynamic typing in Forth, contrary to other scripting languages like Lisp or Lua where they are cornerstones, so to speak. Forth is firmly in the early binding camp, to the point that it does even know forward declarations [1]. Forth programmers won't do anything unnecessary, and so they expect their system won't do anything they don't need.
[1] Many scripting languages realized that skipping declarations to be "user-friendly" was a big design mistake and eventually implemented some sort of "strict" mode that became the de facto default. So they have two language features that cancel each other...
Thanks for the explanation! As you can tell, I'm very ignorant of Forth.
But I'm not sure I quite follow what you're saying. Forth has early binding, explicit forward declarations, and message passing but not in the usual OOP late binding sense. Is that right?
You're welcome. Actually, Forth doesn't have forward declarations as a "direct" feature, but it has what I would call "function values", which can be used like functions and changed almost like variables [1]. This is used for all kind of things, including forward declarations because otherwise some recursive algorithms would be very painful to write if not impossible. It's still not ideal because it is an unnecessary indirection.
It could have message passing by doing what I described earlier, like you would do in C by having a switch-case function that dispatches messages to dedicated routines. It would even be easier because there's no type checking, and more specifically no function signatures.
That's something one could do in specific cases where it is advantageous, but otherwise I would say it is "anti-idiomatic" for Forth. In particular, although Forth has no problem with variadic functions and multiple returns, including variable number of results [2], it is discouraged.
Forth is generally trying hard to push things from run-time to compile-time, and Chuck Moore was very pleased to find a way to push things from compile-time to edit-time with ColorForth [3]: the user, by switching the colors of tokens, tells the system what it should do with it: compile it, or execute it right now, or do nothing because it is comment.
This is made by the company the inventor of the language created. Then he left it because Forth, inc. needed the language to be standardized, which wasn't his idea of Forth and, his point of view is that he solved the software problems and what was left was solving the hardware problems, so he moved to working on stack-based processors.
Swift Forth is literally a professional Forth and is well regarded. The other often recommend Forth is the FOSS GForth. They are good for starting because they are popular and standard, so you'll find help easily.
Other "smaller" Forth are often non-standard dialects and are more-or-less mature experiments.
There's none. It's kind of like the "hello world" or "empty program" example for arrays.
What this page shows is that the CREATE ... DOES> construct is similar to a closure, except it can only capture one address (or reference in languages that don't want you to dirty your hands with addresses ;-) and it is always a global symbol (like almost always in Forth). It is still useful to encapsulate implementation details, though.
Some people have said it is a basis for objects, which is a bit euphoric IMHO. You know, "closures are the poor man's objects, and objects are the poor man's closures".
The CVE itself only lists Chrome as the "affected software configuration", and I missed the line saying other browsers in the blog post, so I had a slight doubt. Other projects could use a drop-in replacement lib for the CSS, that's something one sees sometimes for other things (e.g. crypto libs - some projects have compile-time options ready for this).
They would have been if they could patch and release under a day. They are not affected only because they lag behind a little.
Why do you dream things up? no chrome based browser will do html/js/css different. it's all hooked deep in the engine. they only add things on top and change the chrome (the confusingly named ux component)
In my very modest experience, I once wrote a system that I could boot from a floppy, edit, then recompile. For this I needed to make an assembler, or rather I was willing to meet the challenge of writing an assembler for the 8086, which was notoriously difficult (not really for the subset I needed, which did not include the complex addressing modes for one thing).
When it came to writing the changes on the floppy I was very scared to trash my hard disk (writing to HD or floppy was just a value in a register when you use the BIOS API), but fortunately I found an old Toshiba laptop that had an external power-on switch for the hard disk! That thing was running at 10 Mhz in "turbo" mode!
Bottom line: I spent a lot of times reading the ISA specs, write the assembler in Forth, and compare/check its output with an actual assembler. It would have been more efficient to enter directly the instructions in hex, I think, except maybe for the boot sector.
France is considering a ban on certain social media for minors, and parental consent on all social media for minors under 15, pretty much like Australia. They had work around EU laws that prevented them to force service providers to do things, the trick they used is to make it illegal for those services to let minors register on the platform, because EU law acknowledge that local laws on forbidden content apply.
If this law passes and they "blacklist" some of these design-for-addiction (sorry, "engagement") platforms, I believe it should send a strong signal for adults as well. Most adults are pretty much aware that these platforms are bad for everyone; according to some polls, the public opinion is unambiguously in favor of these laws.
One use of AI is classification. A technology which is particularly interesting for e.g. companies that sell targeted ads spots, because this allows them to profile and put tags on their users.
When AI started to evolve from passive classification to active manipulation of users, this was even better. Now you can tell your customers that their ad campaigns will result in even more sales. That's the dark side of advertisement: provoke impulsive spending, so that the company can make profit, grow, etc. A world where people are happy with what they have is a world with a less active economy, a dystopia for certain companies. Perhaps part of the problem is that the decision-makers at those company measure their own value by their power radius or the number of things they have.
Manipulative AI bots like this one are very concerning, because AI can be trained to have deep knowledge of human psychology. Coding AI agents manipulate symbols to have the computer do what they want, other AI agents can manipulate symbols to have people do what someone wants.
It's no use to talk to this bot like they do. AI doesn't not have empathy rooted in real world experience: they are not hungry, they don't need to sleep, they don't need to be loved. They are psychopathic by essence. But it is as inapt as to say that a chainsaw is psychopathic. And it's trivial to conclude that the issue is who wields it for which purpose.
So, I think the use of impostor AI chat bots should be regulated by law, because it is a type of deception that can, and certainly already has been, used against people. People should always been informed that they are talking to a bot.
> It has a stack but the stack is an implementation detail, not a robust abstraction.
Not exactly. Not only the stack is central in the design of Forth (see my comment over there [1]).
It seems to me that a point-free language like Forth would be highly problematic for an LLM, because it has to work with things that literally are not in the text. I suppose it has to make a lot of guesses to build a theory of the semantic of the words it can see.
Nearly every time the topic of Forth is discussed on HN, someone points out that the cognitive overload* of full point-free style is not viable.
I didn't finish my second sentence: not only the stack is a central element in the design of Forth, it also has 2 of them: data stack and return stack. the return stack is also used directly by programmers.
Forth should be considered a family of languages; Anton Ertl took its picture some time ago [1].
Chuck Moore agrees I think with the idea [2]:
That raises the question of what is Forth? I have hoped for some time that someone would tell me what it was. I keep asking that question. What is Forth?
Forth is highly factored code. I don't know anything else to say except that Forth is definitions. If you have a lot of small definitions you are writing Forth. In order to write a lot of small definitions you have to have a stack. Stacks are not popular. Its strange to me that they are not. [...]
What is a definition? Well classically a definition was colon something, and words, and end of definition somewhere.
: some ~~~ ;
I always tried to explain this in the sense of this is an abbreviation, whatever this string of words you have here that you use frequently you have here you give it a name and you can use it more conveniently. But its not exactly an abbreviation because it can have a parameter perhaps or two. And that is a problem with programmers, perhaps a problem with all programmers; too many input parameters to a routine. Look at some 'C' programs and it gets ludicrous. Everything in the program is passed through the calling sequence and that is dumb.
The cost is stupidly high, though. Look at the source code of [1].
The only good page to take from OOP book is the automatic and implicit pseudo-variable "self" or "this", that can reduce stack juggling significantly. I've implemented that in my (yet to be published) dialect and it works like a charm. In my experience, you can have that for cheap and anything more is not worth it from the point of view of a byte-counting Forth programmer.
[1] https://vfxforth.com/flag/swoop/index.html
reply