The bootstrapping part ignores all the other stuff Forth leaves out, like all the analysis and optimization a C compiler does.
An attempt to articulate Forth's practical strengths and eternal usefulness
51–60 of 68 posts
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#52Earlier quoted context omitted.
Do you have any references to a quick and powerful Forth examples of responding to a web request or manipulating text; you know, typical stuff we deal with every day
https://8th-dev.com/words.html https://8th-dev.com/manual.html Not sure if that is the best example, but go to the "network" section and you can see plenty of examples of connection stuff. Also cool things in the map, graph, console, hardware, DB (database), and nuklear (GUI) sections. It is commercial though (albeit with a free tier iirc), so that may or may not be attractive for you if you wanted to see all source.…
Thank you.
PS. Didn't realize the existence of 8th, looks cool
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#53What... what are those "development effort estimates"? They seem to assume an average rate of approximately 11 lines of code written per day which seems a bit too low if you ask me. Besides, once a C compiler is written for one platform, porting it to another one takes significantly less time than writing from scratch (especially if the compiler is written with portability in mind).
Yes, 11 lines of debugged, delivered source lines of code written per day is within the normal range. The basic COCOMO model used by David A. Wheeler's "SLOCCount" estimates person-months as 2.4 * (KSLOC**1.05), which was calibrated with painfully-won experience on a variety of software projects in the 80s. If you approximate that as 2.4 months per kSLOC, it works out to 13.7 lines of code per calendar day, or 18.5 lines of code per workday. Other studies found lower speeds. Like 10: https://softwareengineering.stackexchange.com/questions/4506...
Every programmer thinks this is stupid the first time they see it, because we can all remember times we wrote 50 or 100 or 200 or 300 lines of code in a day, and that code worked. But other days we write zero lines of code, because we spend them in meetings, or debugging code, or arguing about the protocol design, or testing hardware we need to support, or testing our code. And sometimes we'll spend a week refactoring the codebase to reduce the number of lines of code (https://www.folklore.org/Negative_2000_Lines_Of_Code.html) so those 200 or 300 lines of code may not end up in the delivered product—if they were ever intended to, since test stubs and test scripts also don't count as delivered code.
And that's how we get to Peter Naur's "Programming as Theory Building": https://ratfactor.com/papers/naur1 because writing the code clearly isn't the bottleneck. It's figuring out how things have to work that bottlenecks us. It's more like proving a theorem than writing a novel. The code is a product of the process, but it's more like the exhaust of an engine than its power output.
And that's why the exponent of kSLOC is 1.05 instead of 1: bigger systems are harder to add to.
We had a discussion of this here 17 years ago https://news.ycombinator.com/item?id=333650 and maybe see also Forth authority Phil Koopman's take at https://betterembsw.blogspot.com/2010/05/only-10-lines-of-co... and Brian's take at https://blog.ndepend.com/mythical-man-month-10-lines-per-dev....
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#54What I like about Forth is that it can be expressed at the lowest level of computation, and that it can be used to bridge that to the highest level of computation. For example, Forth only requires about 12 opcodes to run, which can be implemented in a few dozen chips. But now that you have that, since it's Turing-complete, you can now pull across a lisp or C compiler, and build a working operating system from there.…
As anthk points out at https://news.ycombinator.com/item?id=46272791, you really only need one opcode for any program...
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#55Earlier quoted context omitted.
From what I can tell chibicc, unlike tcc, is not a complete c compiler in and of itself. Looking at its source code, it relies upon external tools for both x86_64 code gen and linking: https://github.com/rui314/chibicc/blob/90d1f7f199cc55b13c7fd...
It does rely on binutils, but by this standard GCC is not a complete C compiler either.
Relying on binutils and an assembler is fine. I don't think it really affects the internal complexity of the compiler much, but having textual assembly to look at can be handy for debugging the compiler, so it might reduce the human effort to get it working.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#56Earlier quoted context omitted.
Do you have any references to a quick and powerful Forth examples of responding to a web request or manipulating text; you know, typical stuff we deal with every day
https://8th-dev.com/words.html https://8th-dev.com/manual.html Not sure if that is the best example, but go to the "network" section and you can see plenty of examples of connection stuff. Also cool things in the map, graph, console, hardware, DB (database), and nuklear (GUI) sections. It is commercial though (albeit with a free tier iirc), so that may or may not be attractive for you if you wanted to see all source.…
"Ch. 1 What is 8th?" - and nothing in the chapter explains what it is
some CLI program
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#57Earlier quoted context omitted.
https://8th-dev.com/words.html https://8th-dev.com/manual.html Not sure if that is the best example, but go to the "network" section and you can see plenty of examples of connection stuff. Also cool things in the map, graph, console, hardware, DB (database), and nuklear (GUI) sections. It is commercial though (albeit with a free tier iirc), so that may or may not be attractive for you if you wanted to see all source.…
"Ch. 1 What is 8th?" - and nothing in the chapter explains what it is some CLI program
All that is shown here:
As for the manual's omission, I'm guessing it's a typo. I want to say it used to be there, but haven't looked in a long time.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#58Article is lame in multiple ways, and also eForth was written by Bill Muench. Dr Ting adopted Muench's version to use assembly language bootstrapping instead of metacompilation. Bootstrapping is possibly easier for beginners to understand, but metacompilation is part of Forth's fiendish cleverness and it's a shame for an aficionado to miss out on it.
Oh, I'll have to correct this! I've only seen eForth mentioned with Dr Ting's name all over. Thank you. The metacompilation part is really nice. Did the self-modification section of the essay not convey that to you? Because that's what it was :s I'll have to revise it. I really want this essay to be definitive, so even after 4 revisions there is still some way to go. All the comments have been extremely helpful to fu…
You should also look at how cmForth's metacompilation worked. It's even more fiendish, but relied on cmForth's separate interpreter and compiler dictionaries, which apparently was annoying to use. https://dl.acm.org/doi/10.1145/382125.382916
I didn't notice anything in the article that made me think of metacompilation, but maybe I missed it and should re-read.
Added: you should also look at Bill Muench's version of eForth including its metacompiler. I'm not that big a fan of eForth for practical use (it's TOO minimal) but wow it is simple.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#59EForth running under Subleq: https://howerj.github.io/subleq.htm https://howerj.github.io/subleq.htm The same, but multiplexing instructions (it runs much faster): https://howerj.github.io/muxleq.htm
The last link is broken. GitHub repo: https://github.com/howerj/muxleq