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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Jan 29 22:31:42 GMT 2021

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

> 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

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).

substituting the compiler and typechecking for unit tests is an excuse for
not doing an adequate job.

unit tests are often the only way to properly understane code, not the code

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.

>> now, should such code be deployed in high-security high-performance
>> mission-critical environments?  OF COURSE NOT.
>> and this is where blinkered people such as that author once again
>> entirely miss the point.  languages are chosen based on their
>> *purpose* and use-case.
>> bottom line is: if you are picking a language for a language's sake,
>> because you "like one of its features" you are in for a world of pain.
> 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 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.

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.

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.

this rude shock graphically illustrated to him how critical comments and
documentation are.

everything that you say Jacob about how "types are everything, far more
important than documentation or unit tests", this is only true *for you*.

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.

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).

> I'm using Python for Libre-SOC because nmigen, not because I like Python.

i know, and that "distaste" is going to adversely affect the resultant
nmigen code that you write.

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.

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.

... 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?

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"?


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/20210129/f4ffc0af/attachment-0001.html>

More information about the Libre-soc-misc mailing list