Date: Thu, 28 May 2020 19:39:44 -0400 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Polytropon <freebsd@edvax.de> Cc: Ralf Mardorf <ralf.mardorf@rocketmail.com>, Ralf Mardorf via freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Back to the topic of the original thread: FreeBSD Cert Message-ID: <CAGBxaXn1AFG%2BS79-Dv_rTSL-6NSc94%2BM87-gsDjkwajoBtLyFQ@mail.gmail.com> In-Reply-To: <20200529002155.774696fe.freebsd@edvax.de> References: <CY4PR19MB165585A7D4670DC49DB5523AF9B10@CY4PR19MB1655.namprd19.prod.outlook.com> <CAGBxaXk-yTvN1mCXwSQtjVv4DAkjfMiQP%2BZGfLqExRa7Op6TOw@mail.gmail.com> <CY4PR19MB1655146321E7517E6FC5E7A0F9B10@CY4PR19MB1655.namprd19.prod.outlook.com> <20200527203627.2c9faae5@archlinux> <21722039-a01f-37d3-e035-6be2950485e2@kicp.uchicago.edu> <CAGBxaXm=XtgSvmsgtnqdRZkvOnf_XRo_hV5RCKNy4ApeCtgXMw@mail.gmail.com> <20200528022232.662100a3@archlinux> <0e7aa839-eecf-37f7-4498-4ecc73f44689@kicp.uchicago.edu> <20200528164705.278f3983.freebsd@edvax.de> <20200528162637.73917881c2c395f80a5384fc@sohara.org> <CAGBxaX=oFoSmhQSDZe=DEMpwBcWUeMe7k7yQu%2BxAQje0TDkShA@mail.gmail.com> <20200528170047.d55ed6402f71c9b2558c78bc@sohara.org> <20200528193512.7fcf9192@archlinux> <CAGBxaXkot9McMpVNEmgZgTeowvLstBO1GioZPjXmLXaommUgyw@mail.gmail.com> <20200528204832.7bf83e2b@archlinux> <CAGBxaXmhGEXg2E=H_4X3PWiO_Kps6RT6qKjH9z4DJutBf%2BHaQg@mail.gmail.com> <20200528224701.7cc6f222@archlinux> <20200529002155.774696fe.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 28, 2020 at 6:22 PM Polytropon <freebsd@edvax.de> wrote:
> On Thu, 28 May 2020 22:47:01 +0200, Ralf Mardorf via freebsd-questions
> wrote:
> > It's trivial to _program_ a digital video recorder to automatically
> > record a television programme, [...]
>
> Yes, but only for _old_ people! :-)
>
I wonder? I have no problem debugging a compiler or writing a full web app
(including the HTTP server) but I have never figured out how to program my
DVR (VCR in the old days) to anything except stop flashing 12:00 (and I am
one of the pioneers of streaming media ;-))
>
>
> > [...] but it's not trivial to translate data
> > into _code_.
>
> It's not just data - it's concepts (of behaviour, of data, of
> calculations, of interactions, of data exchange, of communications,
> of hardware control, etc.).
>
>
That is just the tip of the iceberg. You start with what problem (or even
if there is a problem) to solve, this involves getting good solid answers
to the five journalistic questions for the current process/system, the
ideal one the end-users really want (not the one they will get) as well as
the quick and dirty solution and the "done right solution". Note here
that many times the best solutions don't even involve a computer (they just
are nothing more then refactoring the current manual process and leaving it
manual). Of the solutions that do involve using a computer the ones that
involve writing any code (including scripts) at all are almost always the
last option you should consider on how to solve the problem. Coding is
slow, tedious and very error prone even in the hands of the most seasoned
developers. The reason for this is what I (and as far I know only me)
consider to be the there laws of software engineering:
1. Bugs are a fact of life, get used to it! (The goal of software
engineering is to not get rid of them but make catching and fixing them
easier)
2. Anyone who claims to fully understand software engineering,
computing or computer science (or any major subarea of them) is full of
crap (non-PC version full of <bleep>)
3. There are no laws to software engineering only recommendations based
on very costly (personally and organizationally) F'ups from thinking law 2
doesn't apply to the recommender and/or their organization. All such
recommendations make no sense outside of the (narrow) context they are made
from.
Corollary 1: There are no silver bullets, white knights and
Merlin is a myth!
Corollary 2: If the recommendation doesn't include references to
"Alice in Wonderland" the recommender didn't pay a high enough cost to gain
any real wisdom.
All this needs to be done before deciding to write any code and then comes
the easy part (writing/debugging the code if there is any at all). But
before we write any code we need to make decisions about what
tools/languages to use, what is the over all system architecture, what
should the I/O look like in detail, what algorithms/data structures to use
(pick the right algorithm and the data structure will pick it self, pick
the right data structure and the algorithm will write it self, pick either
one wrong and you will be jealous of how easy Alice had it in Wonderland!),
decide on the quality/reliability requirements (including what automated
tests to make to make sure once it works it stays working), make sure your
design is portable and maintainable, etc.
Finally we can start writing some code but where to start? Should we do
the riskiest part first or the easiest part, should we do the UI first or
the guts, etc.? How can I make sure my code is actually testable, etc.
Do I use library classes/methods or do I do roll my own? Etc.
Now I get to write the fun and easy part:
for(int i=0;i<10;i++)
print i;
Of course real code is more complex then this ;-)
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXn1AFG%2BS79-Dv_rTSL-6NSc94%2BM87-gsDjkwajoBtLyFQ>