An attempt to articulate Forth's practical strengths and eternal usefulness
1–10 of 68 posts
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#2Considerably better than most such articles that I have read on this but I think if the Forth community wants to get people into Forth it really needs to stop talking about how it can fit in a boot sector and the REPL; the former is not of interest or use to most programmers and the latter is probably a major cause of the misconception of Forth code being impossible to read.
What I see as the real strength of Forth is that if you write your program in source files, there is no abstraction. You stick your word definitions in those source files and let the application you are writing dictate the words you define instead of relying on the dictionary you built up on REPL and things quickly start becoming easy and the code remains readable. It might seem like a lot of work and endlessly reinventing the wheel but if you start with a featureful Forth like gforth it does not take that much time or effort once you have the basics down; you can build complex applications with gforth as easily as you can build up a full Forth with that minimal Forth that fits in your boot sector.
The main thing is learning that application development with Forth is top down design and bottom up writing. You break the application up into its major functions, break those into smaller functions, break those into words and then break those words into those simple sort words that everyone in the Forth community says you should write. Then you start writing code. I am just starting to get the hang of Forth and it is surprisingly quick and powerful once you start getting the sense of it.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#3This is a pretty good explanation. I think it maybe undersells the importance of the REPL a bit. (I'm not a Forth expert, but I did write StoneKnifeForth, a self-compiling compiler in a Forth subset, and I've frequently complained about the quality of Forth explainers.)
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#4I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list.
Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#5I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list. Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
That's a good point, thanks. How complete is it?
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#6I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list. Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
Came here to say exactly that, cc<< blows these numbers out of the water. Strange choice from the author.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#7I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list. Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
That's a good point, thanks. How complete is it?
It's complete in sofar as being capable of compiling C programs, but it has a few quirks.
https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#8I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list. Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
That's a good point, thanks. How complete is it?
By design, it's not a fully compliant ANSI C compiler, so it's never going to be complete, but it's complete enough to, for example, successfully compile Plan 9's driver for the Raspberry Pi USB controller with a minimal porting effort.
So, Dusk's compiler is not apple-to-apple comparable to the other, but comparable enough to give a ballpark idea that its code density compares very, very favorably.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#9Earlier quoted context omitted.
That's a good point, thanks. How complete is it?
It's complete in sofar as being capable of compiling C programs, but it has a few quirks. https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...
Possibly this is why it wasn't mentioned? There are enough differences in that list that I can't imagine any existing C library would compile unchanged.
Re: An attempt to articulate Forth's practical strengths and eternal usefulness
#10Earlier quoted context omitted.
That's a good point, thanks. How complete is it?
By design, it's not a fully compliant ANSI C compiler, so it's never going to be complete, but it's complete enough to, for example, successfully compile Plan 9's driver for the Raspberry Pi USB controller with a minimal porting effort. So, Dusk's compiler is not apple-to-apple comparable to the other, but comparable enough to give a ballpark idea that its code density compares very, very favorably.
It can be hard to tell how much extra complexity would be introduced by unimplemented features.