Re: My baby text to HTML paragraph converter

[Aryeh Friedman]

On Sat, Dec 16, 2023 at 5:47 PM Steve Litt <slitt@troubleshooters.com> wrote:
>
> Piotr Siupa said on Sat, 16 Dec 2023 02:47:52 +0100
>
> >Hi Steve,
> >
> >Sorry if I'm reading too far into it but from the fact you're using a
> >shell script for building this, I'm assuming that you're pretty new to
> >work with bigger programming projects.
> >Because of that, I'm going to give you some homework. Specifically, I
> >think you should research two things:
> >- Build automation tools - They (similarly to your script) build the
>
> I use make on big projects that take more than 30 seconds to compile
> via a "compile and link everything" script, but at compile times below
> that, I just use "compile and link everything". I make lots of
> mistakes, and find "compile and link everything" makes me less
> mistake prone than make.

If you have problems with Make often repeating steps unnecessarily it
is due to the fact it does
not view the entire build process as one big DAG (directed acyclic
graph).   For more information see the
following older but still very relevant paper:
https://aegis.sourceforge.net/auug97.pdf ("Recursive Make Considered
Harmful", Peter Miller 1997).    If you find the paper helpful you
might want to look into the build system Peter made in response to his
own paper: cook (https://petermiller.work/pmiller/software/cook/)....
Disclaimer: I wrote the official tutorial for it.


> I've never authored anything requiring autoconf, and hope I never have
> to. One of my fundamental beliefs is that I should use as few
> dependancies (especially Other People's Code) as possible, because every
> layer of abstraction complexifies the code and makes troubleshooting
> more difficult. My low use of dependencies lessens the need for
> autoconf. As far as portability, I'd rather #ifdef that into my code
> than use autoconf.
>
> Another thing about me: I try very hard to write my C code such that
> gcc -Wall is silent. Even "harmless" warnings are harmful because they
> disguise the genuinely harmful ones. I also make sure my HTML5 is well
> formed XML and passes an XML parser, and validates via the W3C
> validator. The Troubleshooters.Com web pages I've written in the past 3
> years look identical on all reasonably standards compliant browsers
> that allow Javascript.

Have you considered a language that is more conducive to good software
engineering like Java.   I switched from C to Java about 10 years ago
after using C for 20 years and one too many bugs caused by stray
pointers.   Also C is very hard to unit test except in the most
trivial cases.   If you do switch, the equivalent of Bison in Java is
ANTLR.   As an added bonus there is no need for #ifdef's and other
weirdness needed to make it portable since all implementations of the
JVM follow the same language/standard library standard (unlike C and
the various OS combos).

As far as testing goes see below

>
>
> >- Version control - It tracks all changes you do to your project,
>
> I don't know how you found out I don't use version control, but your
> right, I'm lousy at git and that has to change. I'm OK with git until I
> have to deal with branches, and then I go to pieces. This, and the fact
> that the only human language I speak is English are two of my worst
> flaws.
>
> I'll re-remind myself to try learning more about git. Thanks for your
> reminder.

One of the weakest aspects of traditional mainstream version control
(git, cvs, svn, etc.) is it does not force you to prove that your code
works before it enters the baseline (i.e. pass all of it's own tests).
  Peter Miller's aegis (https://aegis.sourceforge.net/) does this and
thus the combo of cook and aegis is the only thing I trust in my
larger projects like a soft life critical web portal for medical IoT
(remote cardiac monitoring).

This is because any other combo either breaks or makes it easy to
break one of Peter Miller's laws of software construction
(https://en.wikipedia.org/wiki/Peter_Miller_(software_engineer)) which
are:

1. The number of interactions within a development team is O(n!)
without controlled access to the baseline. If the development team
does have controlled access to the baseline, interactions can be
reduced to near O(n), where n is the number of developers and/or files
in the source tree, whichever is larger.
2. The baseline MUST always be in working order.
3. The software build/construction process can be reduced to a
directed, acyclical graph (DAG).
4. It is necessary to build a rigid framework of selected components
(aka the top level aegis design).
5. The framework should not do any real work, and should instead
delegate everything to external components. The external components
should be as interchangeable as possible.
6. The framework should use the Strategy pattern for most complex tasks.


>
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org