[Libre-soc-misc] dynamic vs. static type systems

[Luke Kenneth Casson Leighton]

On Friday, January 29, 2021, Jacob Lifshay <programmerjake at gmail.com> wrote:

>
> I'm picking languages because Python is mostly missing a feature I find
> very important in practice. Python programmers try to make up for that by
> writing docs, but, that is a poor substitute for actual types imho.
>
> I'm using Python for Libre-SOC because nmigen, not because I like Python.
>

ok so i've waited for the right events to occur, to be able to pick up on
this.

jacob if you look through the commit history of the past year there is
virtually nothing contributed from you on the implementation side: the
simulator or the HDL.  your (extremely valuable) contributions have been
primarily instead on the SV specification, without which we would not be as
far along as we are.

i know that your primary if not exclusive focus has been on rust, and on
advocating rust.

the project has grown in that time to the size where software engineering
practices are not optional, they are absolutely critical and they are
critical *regardless* of language.

i was therefore very alarmed to see what you wrote above, but refrained
from saying so at the time.

the implications from reading the above are as follows:

1) "making up" for the total lack of types by inserting the missing
information into documentation as a substitute is pointless, or at least
you consider it distasteful

(if you had said, "i consider it a poor substitute but recognise why it is
important" and even better "and therefore will rigorously follow it even
though i find it a pain" that would be a different matter)

2) using nmigen for LibreSOC is distasteful to you and your clear intention
is to do the bare minimum where absolutely necessary.

(such as initially only considering running python_decode.py to be adequate
testing, rather than the much more extensive tests needed to ensure that
code does not break)

the further implications of that are that there is the risk that the
distaste for python you clearly express becomes subconscious sabotage or
resistance to following practices and procedures that are required for a
project of this size and complexity.

in other words: what rust is teaching you, both from its types and its
followers and proponents, is to *lean on the types instead of following
standard software engineering practices*.

the example overnight where you modified the CSV files to suit one small
narrow use of those files is an extremely good one.  the knock-on
implications are absolutely enormous and extend *far* beyond the python
source code files.

once the modifications to the CSV files are made, and the decoder, then not
only do the python unit tests have to be run (simulator and HDL), the litex
simulation also has to be run *and* the FPGA tests have to be run.

the litex simulations also involve running against microwatt's unit tests:
these all need to be done by hand at the moment because we do not have the
same level of extensive automated testing that microwatt has.

then there is running the ASIC GDS-II files where i am still resolving
things for Jean-Paul. coriolis2 takes several hours to run.

this is days of work and is *nothing to do with python*, extending out to
verilator and the use of nextpnr-ecp5 and coriolis2.

where you proposed to only generate the ilang file, this potentially
jeapordised everything including the 180nm tape-out.


as the complexity of the project grows this will become more and more
important to have a respect for the practices which keep the codebase
stable.

these are not things that i knew when i was 25, despite having been trained
for 3 years in software engineering techniques at Imperial.  they gave me
the theory but not the practice.

i was extremely lucky to then land in a company that had exceptional and
rigorous QA procedures due to the safety-critical nature of their products
(Engine Controller and Management embedded software).

unfortunately because nobody else is helping full time on this project, and
i have to also cover getting the documents ready to get funding in place
under time pressure, crucial engineering documentation is entirely missing,
as is automated testing.

now that you've started helping again, almost a year later, there is a huge
amount missing which you'll need to familiarise yourself with and perhaps
could help document (and automate).  there is NLnet budget to do this so it
will be covered.

primarily: *please* try to respect software engineering practices needed
for projects of this size rather than focus on comparative features or lack
thereof of a given language.  we need adequate documentation and to run the
full chain of tests **regardless** of the "fact" that python developers
"use documentation as a poor substitute for types".

even if the entire project was in rust *full documentation would still be
critical* due to its complexity, and consequently this makes it very clear
that the perspective "python is a poor language because documentation is a
poor substitute for types" is entirely moot and, worse, harmful to the
project to continue to maintain.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libre-soc.org/pipermail/libre-soc-misc/attachments/20210318/262ac82a/attachment.html>