I was captivated by the August 1980 issue of Byte magazine, which had a cover dedicated to Forth. It was supposed to be easy to implement, and I imagined I might do that with my new KIM-1 6502 board. Alas, the KIM-1 was lost when I went to college, and life forced me down different pathways for the next 45 years.
About a year ago I finally began to work on my dream of a Forth implementation by building a Forth-based flight management computer into a spaceflight simulation game that I am working on. Now, instead of writing mostly C# or GDscript code in Godot, I am trying to figure out ways to create a useful device using this awkwardly elegant language. I'm having fun with it.
One of the interesting bits is that I have been able to make the Forth code an entirely separate project on Github (https://github.com/Eccentric-Anomalies/Sky-Dart-FMS), with a permissive open-source license. If anyone actually built a real spacecraft like the one in my game, they could use the FMS code in a real computer to run it.
There is one part of the linked article that really speaks to me: "Implement a Forth to understand how it works" and "But be aware of what this will not teach you". Figuring out the implementation just from reading books was a fascinating puzzle. Once I got it running, I realized I had zero experience actually writing Forth code. I am enjoying it, but it is a lot like writing in some weird, abstract assembly language.
Circa 1980 BASIC was the dominant language for micros because you could fit BASIC in a machine with 4k of RAM. Although you got 64k to play with pretty quickly (1983 or so) it still was a pain in the ass to implement compilers on many chips, especially the 6502, which had so few registers and addressing modes that you're likely to use virtual machine techniques, like Wozniak's SWEET 16 or the atrocious p-code machine that turned a generation of programmers away from PASCAL.
FORTH was an alternative language for small systems. From the viewpoint of a BASIC programmer in 1981 the obvious difference between BASIC and all the other languages which that you could write your own functions to add "words" to the language. FORTH, like Lisp, lets you not only write functions but create new control structures based on "words" having both a compile-time and run-time meaning.
FORTH's answer to line numbers in BASIC was that it provided direct access to blocks (usually 1024 bytes) on the disk with a screen editor (just about a screenful on a 40x25) You could type your code into blocks and later load them into the interpreter. Circa 1986 I wrote a FORTH for the TRS-80 Color Computer running the OS-9 operating system and instead of using blocks it had POSIX-style I/O functions.
FORTH was faster than BASIC and better for systems work, but BASIC was dominant. Probably the best way to use FORTH was to take advantage of it's flexibility to create a DSL that you write your applications in.
I am convinced that someday, device manufacturers will realize that complicated, small touchscreen UIs are a horrible idea. They're even worse for seniors, because our fingers are losing dexterity, may be slightly swollen and stiff, and are prone to tremors. So, at a point in our lives when merely holding the phone can be a challenge, navigating some ambiguous UI while our fingers are obscuring the very thing we're trying to use is insanity.
But Apple is the worst because of its Apple ID requirement. I tried to resurrect an old iPhone of mine only to get stuck in a week-long perpetual ID recovery loop with Apple. Enter the new password wrong too many times, and you have to wait another week to try again. Want to create a new Apple ID? Nope. No duplicate IDs attached to the same phone number. I finally just recycled the phone. I'm old. I don't have time to waste on an iPhone.
Fun link. I never wrote GPU drivers, but it does remind me of writing my first Ethernet card driver back in the day. I felt like I had decoded the Rosetta Stone, and there was absolutely no one to talk to who understood how that felt.
This is a familiar concept from reading about WW2 spy stuff (Between Silk and Cyanide, for example, which I highly recommend). But what REALLY intrigues me is the typeface of the letter with its upper-case 'E' used in place of 'e'. What's up with that?
The suggestion that it may have been a striker from a bilingual - cyrillic typewriter that was mixed in is an interesting possibility; someone transcribing diplomatic telegrams in WWII may indeed have need of access to Cyrillic typewriters…
Interesting idea, but both the Cyrillic and Greek capital E would be a similar size to the Latin capital E. And in both alphabets the lower case e doesn't look like a smaller capital E. It's е/ε.
Might be unrelated in this example, but when a message is written in a lazy ROT13-like cypher, the letter e becomes a notorious rat that allows anyone to break the entire thing in very little time.
Randomizing/obfuscating the letter case might buy you a little time, though I think it's something else entirely here.
Zvtug oR haeRyngRq va guvf RknzcyR, ohg juRa n zRffntR vf jevggRa va n ynml EBG13-yvxR plcuRe, guR yRggRe R oRpbzRf n abgbevbhf eng gung nyybjf nalbaR gb oeRnx guR RagveR guvat va iRel yvggyR gvzR.
Enaqbzvmvat/boshfpngvat guR yRggRe pnfR zvtug ohl lbh n yvggyR gvzR, gubhtu V guvax vg'f fbzRguvat RyfR RagveRyl uReR.
V guvax gur vqRn jnf gb fcyvg guR uvtu seRdhrapl "r" gb gjb qvssReRag flzobyf r naq R ng yRffRe serdhrapvRf. Fvzcyl ercynpvat nyy r'f jvgu R qbrfa'g qb gung.
2) the teletype machine has unique letter so the machine it was received in is known (and hence which staff received it), reducing the ability to forge messages. Different machines could have had special letters, or all machines handling secrets had that particular "e"??
3) the machine broke and the repair shop only had a small-caps "E" handy.
The document on the picture was for sure typed on a typewriter. Teletype machines would either be all caps or all lower case. Also they wouldn't be able to print a multi column header like on top of the document.
That's what makes this interesting to me. Because I feel like, if you own an operatable train car that can be hooked up to AmTrak, then you not only don't have to ask for the pricing, but do you even have to google to see if you can hook it up?
An operable train car could be something you have as a coop deal. If you are good with tools you can probably trade labor for use of a car. (There are several rr clubs restoring old cars that would then qualify - check the club for terms - might even be a club event so the costs are shared with others)
The canonical Bell Biker helmet that I remember was an ugly and expensive white bowl-thing for serious road cyclists that started becoming popular in the late 70s as ten-speed bicycles became more popular with adults.
This statement in the article is a real head-scratcher:
> Until now, the Southern Ocean region was virtually inaccessible to satellites due to its low temperatures and the complex, ever-changing dynamics of sea ice.
I hate to cast doubt on the veracity of such an interesting story, but this really makes me wonder whether the entire article is just AI garbage.
There is nothing in the article you linked that explains why "low temperatures and the complex, ever-changing dynamics of sea ice" used to make the region "virtually inaccessible to satellites" but now no longer does.
Further, I did a search using "challenges of satellites in the Southern Ocean" and found no info, rather than plenty of info.
edit: I eventually found the following link which does seem to discuss some challenges, but does not indicate that they have been solved. It certainly does not support the claim that the region is "inaccessible to satellites".
Doesn't need to be AI to be garbage per se, popular science should always be read with some skepticism as it's often a translation (pop sci) of a translation (news publication) of a paper (the actual source).
Example, pop sci will show a rendering of a lush green planet with a headline like "EXTRATERRESTRIAL LIFE FOUND!11", the news release will be something like "Potentially life-supporting planet discovered by xyz", and the actual paper will be something like "measuring device foobar123 noticed a 0.2% decrease in luminance of star aybabtu-1337 at a period of .6 frotz/picoyear indicating this planet probably isn't cooked or frozen but what do we know lol"
That sentence is garbage for sure but if you read it with good intentions from the journalistic view it almost makes sense. It is about remote sensing from satellites, not about the satellites themselves. There are lots of interesting edge cases where remote sensing does not work. The problem is usually that it is expensive to get on the ground data to validate models.
I left the software engineering field about 17 years ago to become a high school teacher. One of the things I taught was computer science (to high schoolers) and I recall sitting in many meetings of HS CS educators discussing the upcoming critical shortage of workers with CS degrees. I would tell them I left the field because there wasn't much work, and they would look at me like I was crazy. "Something wrong with that guy... He can't find work when there's a CRITICAL SHORTAGE of workers!!"
I discovered this site about 20 years ago, and it appears to be as good as ever. The volume of detailed documentation here is all you need to dispel fantasies about a moon landing hoax.
About a year ago I finally began to work on my dream of a Forth implementation by building a Forth-based flight management computer into a spaceflight simulation game that I am working on. Now, instead of writing mostly C# or GDscript code in Godot, I am trying to figure out ways to create a useful device using this awkwardly elegant language. I'm having fun with it.
One of the interesting bits is that I have been able to make the Forth code an entirely separate project on Github (https://github.com/Eccentric-Anomalies/Sky-Dart-FMS), with a permissive open-source license. If anyone actually built a real spacecraft like the one in my game, they could use the FMS code in a real computer to run it.
There is one part of the linked article that really speaks to me: "Implement a Forth to understand how it works" and "But be aware of what this will not teach you". Figuring out the implementation just from reading books was a fascinating puzzle. Once I got it running, I realized I had zero experience actually writing Forth code. I am enjoying it, but it is a lot like writing in some weird, abstract assembly language.