- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Is this meant to read 80286 CPU?
Admin
Froth?
Admin
One who comments on a language that was created in the 1960's and publicized in the early 1970's (and still in use 50+ years latter), really needs to have been involved with computers back in that time frame to understand why things were done.
I do not see a single WTF in this material. (and I may even remember the specific program - I have done quite a bit in the medical field ;) )
Admin
I do. Describing what the code does in the comment block. No indentation in the code block. That's some WTF right there.
Admin
I've parsed "floppy disk" the first time I've read that sentence and just wondered that I've never heard of half-height floppies rather about the floppy-thing itself.
Admin
Naked machine code opcode bytes rather that assembler-level mnemonics also scores pretty highly...
Admin
\Why is banning comments in line in the code blocks not a WTF? Forth allows them. In fact, it's practically mandatory to annotate each word definition with a comment that documents at least the effect on the data stack.
Admin
Remy pretty well summarized half the WTFery on the site, and all the WTFery of today's entry right here:
It is now, was then, and probably always will, be mostly bad management that creates WTFs, or creates the environment that creates and perpetuates WTFs.
All the rest is just details. Sometime fun, juicy, salacious details. For very nerdly values of "salacious".
Admin
Ah, the joys of OS-free programming and crazy-restrictive standards. I worked on a project like that once upon a time. Except this one was safety-critical -- control of a cargo locking mechanism for an aircraft -- and the bureaucracy, overhead, and micromanagement associated with that was insane. For instance, we were using C (not C++, because we couldn't have any of that new-fangled polymorphism nonsense; copy-pasted structs with slight differences were so much better), and basic language features like pointers were outlawed by the coding standard. Imagine pass-by-value semantics on every single method in the program, some of which used rather large data structures in tight loops, and you can get a pretty good idea of why they had a terrible time trying to hit their performance targets.
I left the company before the project finished, but as far as I know that program was perfectly safe. Because they lost the contract before they ever got it to a deployable state.
Admin
From what I read, "classic Forth" blocks are literally blocks of file system storage. I can somewhat understand not mixing executable instructions and comments in the same block. It seems like you wouldn't want to leave portions of the block open to having arbitrary instructions inserted within.
Admin
The printed-out source control reminded me of my days at Honeywell right after college (mid-90s). I worked at the Home & Building Control location, with a group that was working on smart, interconnected home thermostats for a time. When a project was completed (or a milestone reached), they would print out a hex-dump of the compiled code, and that would be locked away in some fireproof vault or something. The theory was that if there was some Smoking Crater event and they needed to be able to get the ROM back to make more of some device, some poor intern would have to hand-type all the bytes in, and they'd reconstruct from that.
To my knowledge nobody ever had to, and I hope by now they have other methods of backing up their development work.
Admin
I don't remember much about FORTH, except that BUILDS and DOES were important somehow.
Addendum 2021-01-20 13:57: One of my buddies was a FORTH expert. Apparently one kind of the army tanks used "adjacent tank" awareness over a wireless network, and he was instrumental in coding that... in FORTH. The first time he saw a bunch of tanks all make the same turn at the same time, he exclaimed "I wrote that!" rather proudly.
Admin
I remember putting FORTH on my MS-DOS clone. The first thing I did was add the more-or-less standard full screen editor so I could get some real work done. Then I wrote some machine code (embedded in FORTH) so I could call BIOS and DOS interrupts. With that, I was able to convert it to write to actual DOS files instead of to raw disk sectors. With FORTH you could do all that because you could have FORTH modify its own code.
After all this I had a pretty usable FORTH system running under DOS... except that it ran slower than FORTH had on my 2 MHz Z80 CPM computer. Fun days back then!
Admin
I wish more modern languages were designed around the idea of self modifying code. Like you can do a little bit of that with stuff like reflection but really it's just not the design intent. And that's a shame. I'd love to like write a single giant function that works just to reshufle every other functions insides based on parameters.
Admin
You're insane.
Admin
I actually implemented a FORTH once, just for fun, using a book from Byte. ("Threaded Interpretive Languages", with the obligatory Robert Tinney cover art.) Almost every page had typos or bugs, and I had a hand-written sheet of notes about all the bugs. Then I loaned it to a friend who moved to California without returning it, and I was angry to lose that sheet. A few years back I was able to get a used copy.
I even bought a TRS-80 Color Computer just to play with 6809 code. It was a great instruction set for a classic threaded FORTH interpreter. The entire "inner interpreter" was literally two instructions thanks to all the indirection and post-increment tricks that the 6809 could do. And it had an extra index register that could be used as the data stack pointer.
But really, the last gasp of FORTH was in the boot loader used by Sun, and by Apple's Power-PC systems. People who complain about Perl have never been introduced to FORTH or its descendants. At least Perl code can be made readable with moderate effort.
Admin
Thank you.
Admin
If you will allow me to indulge in some pseuco C++ I was thinking of something like this: Class - Each class is simply a shell that contains a set of pointers. Two vectors in particular. Properties - pointers to the memory location of the values of each member. Only it's not even void* but just integers. Methods - pointers to the memory location of the code for each method. Only it's not even void* but just integers.
There is a "main" class that actually contains all the methods and also serves as a factory initializing each class and giving it initial values for these. It also only has the two arrays. So basically every variable instance and every method instance (yes, method instance) have their own instance in the main class and all the other classes are just shells with pointers to it.
The main class only has two methods. One is the factory constructor and the other is called "Call" Call takes two parameters, a pointer to an array of integers and an integer. The second parameter is, as you might expect the ID of the method in the main method array. And the other is the stuff you want to pass to it again as indices only for the property array.
Now here is the fun part. As the method "call" is called it executes the code and writes the output directly into both arrays. Yes both. You can have a method that upon execution changes what method is bound to an instance of the same or other class with that nominal name.
So like you might have 3 objects of the "number" class. But when "add" is called on "number 1" and "number 2" they change it so that on "number 3" "subtract" now actually refers to "multiply" instead. And this would be entirely valid code and something you would be expected to regularly do.
The ideal being that after instantiation no two instances of the same class can be expected to behave identically.
And this of course would not be a program in its own right but the starting framework from which future projects would start. What do you guys think? Yes, yes or hell yes?
Admin
Lots of comments here from people who have clearly no idea what they talking about as they are so used to modern languages, tooling and abstractions so far removed.
That Babbage bloke? WTF! You mean he had use to use a screwdriver to programme that computer thing of his? And what's that he had to write it on paper first and the backup was done with chalk and a slate pad?
Admin
You've never head of 1/2 height floppy cos you are YOUNG! The original IBM PC had a full height (casing height) drive. Later machines let you have two floppy drives in the space of the full height - hence half height.
Admin
Banning comments in the FORTH code is not a WTF because you have exactly 1K page to put your actual code. That is incredibly small so if you start putting comments in there you lose space for code. Start doing all the frilly indenting and line spacing and you'll fit nothing on a block. The editors for FORTH in this environment is non-existent. No easy refactoring by copy pasting etc. by swish of a mouse.
Admin
Thanks! I hate it!
Admin
I don't know FORTH, but it certainly was common back in those days to be extremely frugal with comments and even the length of procedure and variable names because space was such a problem and compilers didn't necessarily optimise that stuff away.
Seems a bit of a non-issue anyway. Even tersely coded 1k is not that big a lump to document separately. I mean if they actually cared to make it understandable they could have printed it out and annotated it (even by hand) and filed it somewhere, or a hundred other solutions. Then as now, code didn't end up an incomprehensible tangled lump with no explanation by complete accident.
Admin
Bare metal Forth "Screen Based" systems used a built in editor , the IDE of its day, that knew how to switch between code and comment "shadow" screens. (Mid 80s use case for machine control applications using CP/M Z80 and bare metal control using PDP11)) Later Forths that typically ran under an OS like CP/M, Windows or SunOS provided host file system support for Forth source and also offered a legacy "Screen" editor and mode that combined multiple screens into a single host OS file. Of the internecine Forth convention battles native host OS files seemed to prevail over screens though even in the late 80s projects like the original post likely stuck with the original / old approaches influences/influencers. I have followed a few more recent MCU Forth projects on Hackaday.com like Jeelabs and Mecrisp and the language still sparks both interest and outrage. As the OpenFirmware/OpenBoot creator/ advocate observed, often the hardest part for Forth devotees is explaining its usage to the uninitiated, while detractors cite past project failures, legibility, available talent, and standardization.
Admin
Also Forth best practices in the early 80s disavowed inline hex codes and recommended instead invoking a defined machine code Forth word. However the inventor of Forth implied that everyone should have a standard, and nothing prohibits in-line hex machine code perhaps just for rare special cases like a BIOS call, Interrupt handler, change from 80286 Real Mode to Protected Mode, or a Forth inner interpreter. In any event dubious and idiosyncratic conventions can sour newcomers to a programming language, project , or an entire organization.
Admin
BUILDS/DOES or CREATE/DOES support Forthy idioms like Custom Defining Words, Data Directed Programming ,and Vectored Execution. A creative use of the techniques from years past included a string pattern match Forth environment modelled on Snobol (instead of Regular Expressions )from another (former) Google principal. P.S. Guessing you're a co-author of Learning Perl, it's literally on my desk right now with Chromatic and Friedl.