<br><br>On Friday, January 29, 2021, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br><br>> For Python, if it parses, you still commonly have a bug somewhere due to type checks being dynamic and Python not having correctness by API design as a commonly used technique (where the APIs are designed to be very hard to misuse intentionally/accidentally, which is defacto standard in Rust).<br><br>so what? this just means that you failed, as a software engineer, to write adequate unit tests (and in the case of the author, fundamentally failed to understand their multiple benefits by dismissing them derogatively in about 5 words).<br><br>substituting the compiler and typechecking for unit tests is an excuse for not doing an adequate job.<br><br>unit tests are often the only way to properly understane code, not the code itself!<br><br>this was why i stopped reading that article because it is clear that the person who wrote it has never been properly trained as a software engineer, worked with a team of diverse people with different levels of abilities, or worked on radically different tasks.<br><br><br>>><br>>> now, should such code be deployed in high-security high-performance<br>>> mission-critical environments?  OF COURSE NOT.<br>>><br>>> and this is where blinkered people such as that author once again<br>>> entirely miss the point.  languages are chosen based on their<br>>> *purpose* and use-case.<br>>><br>>> bottom line is: if you are picking a language for a language's sake,<br>>> because you "like one of its features" you are in for a world of pain.<br>><br>> 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.<br><br>i spoke about this with Alain the other day.  he pointed out that code comments - the thoughts in your head at the time - are far more important than anything else.<br><br>i have had the same experience that he has: the one that he told me was of some FORTRAN code he wrote when first learning programming.<br><br>six months later he was literally unable to understand the purpose and workings of his own code.  he had no memory of the decisions he had made, and because it had no comments there were no reminders.<br><br>this rude shock graphically illustrated to him how critical comments and documentation are.<br><br>everything that you say Jacob about how "types are everything, far more important than documentation or unit tests", this is only true *for you*.<br><br>if you are able to do something but others cannot understand it, cannot read it, cannot improve it, cannot help you with it, this is... well, it's lonely and it's not what Libre-SOC is about.<br><br>we're developing something that's for the world, and that means proper documentation, proper code comments, proper unit tests (which even i resist writing, frequently).<br><br>> I'm using Python for Libre-SOC because nmigen, not because I like Python.<br><br>i know, and that "distaste" is going to adversely affect the resultant nmigen code that you write.<br><br>i have to say this: it's very obvious in the way that, over the past 18 months, you resist helping with tasks that involve using python, using anything but python to do so if you do so, and it is quite a hindrance to the project as a whole, given that we have so few people.<br><br>remember that up until age 29 i was a c/c++ programmer *only*.  it took martin pool *5 months* to get me to use python.<br><br>... so with that strong resistance, which stemmed from using strong data types, why did i like python so much?  what did it allow me to do which c++ did not?<br><br>given that i also loved strong data types from c++, what is it that you are missing which makes you consider python to be so "distasteful"?<br><br>l.<br><br><br><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>