3 ms·
Regardless the merits of the language itself, the culture of Forth has some serious issues that cause me to doubt that a skilled Forth programmer truly has a de
by KaeseEs 16y ago
Regardless the merits of the language itself, the culture of Forth has some serious issues that cause me to doubt that a skilled Forth programmer truly has a development speed that is a multiple of that of a skilled C programmer. Cf. this advice from Thinking Forth:
"Some Forth practitioners advocate storing source code in variable-length, named text files, deliberately emulating the approach used in traditional compilers and text editors. This approach may become more and more common, but its usefulness is still controversial.
Sure it's nice not to have to worry about running out of room in a screen, but the hassle of writing in a restricted area is compensated for by retaining control of discrete chunks of code. In developing an application, you spend a lot more time loading and reloading screens than rearranging their contents.
"Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition."
(from page 144 of the 2004 edition)
- coliveira 16y agoThere are some developers that prefer the block-oriented approach of creating Forth code. Remember that Forth is a dynamic language, so there is a tradition of viewing the system as an image (similar to Smalltalk), instead of a bunch of static files saved on a file system. They achieve this by creating small blocks of code that are dynamically loaded as necessary. This doesn't mean you can't create Forth programs from standard text files. All modern Forths work this way, providing blocks only as an additional feature.
- KaeseEs 16y agoMy main beef was with the last bit - ""Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition." This reeks of Stackholm Syndrome, where having toiled under the limitations of a system for some time and developed workarounds and jerry-rigs* to get by them, one begins to view them as strengths for no other reason than their familiarity. If nobody thinks like this any more though, congrats on escaping what is normally a sure route to smug weenie-ism. *Eg. later in the same section, Brodie suggests defining constants associated with block numbers as a sort of ersatz filenames
- randallsquared 16y agoStackholm Syndrome Nice.
- pietrofmaggi 16y agoIIRC the 2004 is simply a retyping of the 1984 edition, so all the content is nearly thirty years old (Thinking Forth Project http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/). So this kind of information is a bit dated. If you look at current forth implementations (gforth, Forth inc and MPE comes to mind) none of them is screen based; you can decide if is good or bad ;-)
- joe_the_user 16y agoI was just scanning 40K c++ header I'd written.. 1K block limit seems like it could be a useful device for making functions understandable at a glance. As I remember, Steve McConnell said studies have shown the most bugs can be found in very long and very short functions...