On 23 Mar 2024 at 10:30:31 CET, "mhx" <mhx> wrote:
My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.
This all in my humble opinion, but I have been around for a while.
I have been involved in Forth projects of up to 30 programmers
from several companies in several countries. For my sins, I
have even been the project manager for a project involving
five organisations in four countries.
It's a management problem. If you are the only programmer, then
the problems are mainly to do with your approach to management.
There are two primary factors, project lifetime and project size.
Both are intimately intertwined with the project documentation.
If you do not document the design and the code, you are building
problems for the future.
The MPE cross compiler has evolved over 40+ years. Most
compilers compile between 30k and 45k source lines of code
(SLOC) to produce a compiler. The 30k figure is for AMD64
and includes assembler, code generator and dissassembler..
The 45k figure is for ARM32 including both ARM32 and
Thumb2 instruction sets. Design documentation is skimpy
and I have wanted to rewrite the compiler chassis for over
a decade. This may be one of my retirement projects.
A client application has evolved over a similar period to the
cross compiler and now exceeds 1M SLOC. It is managed,
maintained and developed by a small team managed by
a very determined person, from whom I have learned a
great deal.
The key document to orient your thinking about larger
projects is from Joel Spolsky:
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
If you have not read it, do it now.
The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs.
These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also
prevent me from documenting sub-tools, and giving such tools
their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]
If you have decided that the code cannot be documented
then it's time to throw one away.
With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?
Choosing an editor is somewhat like choosing a religion.
After a few years the editor is part of muscle memory.
I have always let programmers choose their own
editors, subject to a few simple rules such as setting
hard tabs to 8.
Spolsky says to use the best tools. Hence, you have
to be prepared to pay for tools.
All our bugs are in our source code. Debugging is
an application of Formal Scientific Method, and I
have written about it several times, e.g.
https://jacobfilipp.com/DrDobbs/2008webarticles/printa982.html
The article is entitled modern Forth (from 2008) and I quote
from it
"
Debugging consists of two nested loops. How fast you can
go around the inner loop determines how fast you can
debug a system. Interactive debugging is the fastest route
I have found. The stages of debugging are:
1) Make the problem repeatable. This usually involves
finding out which inputs cause the problem.
2) Gather data about the problem. Observation is crucial,
so take this stage slowly and carefully. I have seen people
immediately dismiss exception displays and crash-dumps
which contain vital clues.
3) From the data, form a hypothesis as to what caused the problem.
4) Design an experiment which tests the hypothesis. The
important part in designing the experiment is to ensure
that it gives a yes/no answer.
5) Run the experiment. If the hypothesis is incorrect, go
back to stage 2.
6) Fix the problem.
7) If you have more bugs to fix, go back to stage 1 for the next problem.
Programmers are very rarely taught how to debug. The
problems they face are almost always in their source code.
So why don't they read it more carefully? In particular, why
don't they write a line or two describing the whats and whys
of of a routine before they write the code? The poor relation
who maintains your code for the next 10 years costs your
employer a fortune because you could not be bothered.
As a sidenote to this potential rant, my company has been
using literate programming for 10 years and we believe
that it has increased the quality of our code. Whenever
we incorporate third-pary code into our code bases we
document it to our house standards. This process nearly
always reveals bugs. To produce stable software the golden
rule is to fix the bugs first. A second rule is not to write clever
code. Although this upsets people trying to achieve alpha-male
guru status, you should remember the aphorism attibuted to
Brian Kernighan:
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it.
Forth is a wonderful tool for debugging systems and their software. Since we spend most of our time debugging and testing, it astounds me how our industry accepts mediocre tools for critical activities. "
I am thinking of introducing *.finc (forth include) files
alongside the existing *.frt ones. One of them will hold
all (?) the variables needed by all (?) of the subtools.
This will waste data space in some cases. A *.finc file is
loaded at an arbitrary spot inside the calling subtool(s).
Sounds like a very second order issue.
I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?') Did this go anywhere? Win32forth
seems to be as dead as a doornail and I am not even sure where to
get a decent source distribution of its tools?
It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency. Are there equivalent open
source projects that I should consider?
I know of one Forth company that is rewriting its development
IDE in Visual Studio because it's known by the "children" and
is therefore cheaper in the long term.
Sorry, that turned into something of a diatribe, but the importance
of project management and debugging is one of my buttons.
Stephen
--
Stephen Pelc,
stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)