<br><br>On Friday, January 29, 2021, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I'm using Python for Libre-SOC because nmigen, not because I like Python.</div></div></blockquote><div><br></div><div>ok so i've waited for the right events to occur, to be able to pick up on this.</div><div><br></div><div>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.</div><div><br></div><div>i know that your primary if not exclusive focus has been on rust, and on advocating rust.</div><div><br></div><div>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.</div><div><br></div><div>i was therefore very alarmed to see what you wrote above, but refrained from saying so at the time.</div><div><br></div><div>the implications from reading the above are as follows:</div><div><br></div><div>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</div><div><br></div><div>(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)</div><div><br></div><div>2) using nmigen for LibreSOC is distasteful to you and your clear intention is to do the bare minimum where absolutely necessary.</div><div><br></div><div>(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)</div><div><br></div><div>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.</div><div><br></div><div>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*.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>then there is running the ASIC GDS-II files where i am still resolving things for Jean-Paul. coriolis2 takes several hours to run.</div><div><br></div><div>this is days of work and is *nothing to do with python*, extending out to verilator and the use of nextpnr-ecp5 and coriolis2.</div><div><br></div><div>where you proposed to only generate the ilang file, this potentially jeapordised everything including the 180nm tape-out.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>l.</div><div><br></div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>