It's not built for hiding at all, that's what submarines are for (and that's where our nukes are).
2,240 karma · joined October 1, 2011
It's not built for hiding at all, that's what submarines are for (and that's where our nukes are).
It's a better service than FB or Instagram that depress because people only show their good sides there... As you said, she was an essential part of the community ;-)
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.
[1] https://forth-standard.org/standard/core/DEFER
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...
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.
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.
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".
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.
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.
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.
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.
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.[1] https://www.complang.tuwien.ac.at/anton/euroforth/ef04/ertl0...
Now it's a classic, you need an expert in order to check the work of the machine, because the "customer" is by definition not able to do it.
Aside from highly technical domain, in purely literary works, I think that the translator is a co-author - maybe IP laws acknowledges that already? I remember the translation of E.A. Poe by C. Baudelaire for instance; I think you could feel Baudelaire's style because it is a lot "warmer" than Poe's. I've also read a translation of a Japanese novel and I was quite disappointed with it. I don't know Japanese but I have read/watched quite a few mangas/animes, so I could sense the speech patterns behind the translations and sometimes thought they could have made better choices.
In any case, one will still need a translator who is good at "prompt engineering" to get a quality translation. I don't know. Maybe translators can add this skill to their CV, so they can propose quick-and-dirty/cheap translations, or no-AI high quality translations.
Some suggest "no-AI" labels on cultural products already - I think if it becomes a reality it will probably act as "quality signaling", because it is becoming more difficult every year to tell the difference between AI and human productions. It won't matter if what you read was written by an AI or a human (if it quacks and looks like a duck...), but what the customer will probably want is to avoid poorly-prompted machine translation.
TPMs can be reprogrammed by the customer. If the device needs to be returned for repairs, the customer can remove their TPM, so that even the manufacturer cannot crack open the box and have access to their secrets.
That's only theory though, as the box could actually be "dirty" inside; for instance it could leak the secrets to obtained from the TPM to mass storage via a swap partition (I don't think they are common in embedded systems, though).
Sometimes people look sort of "superstitious" to me about Git. I believe this is caused by learning Git through web front-ends such as Github, GitLab, Gitea etc., that don't tell you the entire truth; desktop GUI clients also let the users only see Git through their own, more-or-less narrow "window".
TBH, sometimes Git can behave in ways you don't expect, like seeing conflicts when you thought there wouldn't be (but up to now never things like choosing the "wrong" version when doing merges, something I did fear when I started using it a ~decade ago).
However one usually finds an explanation after the fact. Something I've learned is that Git is usually right, and forcing it to do things is a good recipe to mess things up badly.
All of this failed - or rather, was undone and cancelled by the "modernization" of the Web. Namely the arrival of for-profit companies on the Web, be it Facebook of the press like the New York Times.
It was a boon as they brought valuable content, but they brought it with their own rules. The first set of which is the ads-supported model, which is by definition the opposite of free content; an ad-supported website is not free in a very sneaky way, and it's not just about privacy and manipulative practices (targeted ads, as if ads were not already manipulative enough). Users are actively prevented from consuming the content the way the want.
The situation today is that very few browsers offer out-of-the-box a way to apply a personal CSS, and I think none will generate a ToC from the headers of a HTML page.
And the "semantic" part - far from specialized and more accurate semantic markup frameworks that were considered - is being completely taken over by LLMs; an insanely expensive brute-force solution IMHO.
The web has already be reinvented mostly the way you suggest, see for instance the Gopher and Gemini protocols, but they'll stay forever "niche" networks. Which could be not so bad, as it is very clear that the Web is full of actors malicious to various degrees. Tranquility by obscurity?
Also, artists in general are a peculiar profile I think. It's not only famous singers that take drugs, commit suicide etc. One can easily find many writers and painters, some of them even only became famous postmortem.
But OP is correct, companies don't care as long as it doesn't translate into higher sales (or lower sales because the competitor does better). That's why you see that sort of optimization mainly in FOSS projects, which are not PDD (profits-driven development).