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

[Jacob Lifshay]

On Fri, Jan 29, 2021, 05:11 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Thu, Jan 28, 2021 at 9:43 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > however, that is only the first half of the article, the last half's
> argument still applies even without type confusion.
>
> (bear in mind that i am a c/c++ programmer before learning python)

there is no confusion, only a complete fundamental blindspot.  i
> stopped reading at that "second strike".  the "first strike" was the
> denigration and devaluing of unit tests.
>
> this article is fundamentally and deeply flawed, written by someone
> with a massive blindspot as to why python exists, why it is popular,
> and why it is successful despite multiple repeated efforts to say it
> "cannot be because it doesn't have strong types".
>
> the FUNDAMENTAL basis of python is the fact that +, > and other
> operators call __add__, __gt__ and so on, in combination with coerce.
> if you do not know about type-coercion and its ordering you need to
> look it up, urgently.
>

Python is far from the only language with type coercion and operator
overloading, Rust and C++ have that too.

>
> i know you keep trying to add types into code written in python: i
> keep telling you and one day it will sink in that this fundamentally
> goes against CRITICALLY important aspects of python:
>
> 1) compactness
> 2) readability
> 3) time-saving
>
> look at the following example:
>
> def fn(a,b,c,d,e,f,g,h,i,j,k):
>   (l,m,n.o,p,q,r) = (0,1,2,3,4,5,6)
>
> now expand that out with the (i have to say this: stupid, irritating)
> forced type-checking.
>
> now count the number of lines of code.
>
> 2 lines of code became.. what... 25?  and for what??
>

to improve readability since now you also know what types are expected for
a...k rather than just that the function takes that many arguments.
Remember, typing is *also* documentation.

>
> 1) compactness violated: it spreads the function out, forcing the
> reader to scroll down, doesn't it?  the "bang-per-buck" - information
> conveyed per page - is greatly reduced.
>
> 2) readability violated: did it *actually* improve readability?  you
> KNOW what the types are of l thru r because ON ONE LINE they're right
> there: ints.


yes, and neither Python + typing nor Rust nor modern C++ require you to say
what types l...r are since they can be deduced from their definition. If
their definition is sufficiently opaque that types should have been added
as a comment anyway, then it's appropriate to state their types in the
definition, but that is otherwise unneeded.

  and because you are keeping code SHORT, the same logical
> inference and/or "reading the docstring" tells you exactly what the
> type is... not that you care because you know the Liskov Substitution
> Principle *and apply it*.
>

type annotations *can* and often should be abstract types that represent
all types with certain properties, Rust excels at this with Traits, far
ahead of most other programming languages (though C++20 is catching up
somewhat with Concepts).

>
> 3) time-saving violated: how much effort did it take to add - to type
> - these completely unnecessary types?


assuming you use a decent IDE that can autocomplete types, probably 3-10s.
I'd argue that if it takes much longer than that, either you're using a bad
IDE or the types are complicated enough that leaving them out of the actual
code or at least documentation is a poor decision. You shouldn't have to
look throughout tens of function's implementations just to figure out what
types are used, that impedes readability wasting time later far more than
the small amount of time you might have saved when you initially wrote it.

and how much effort did you
> impose on people not familiar with the (irritating) type-declarations,
> by increasing the amount of time it takes them to parse the unfamiliar
> format?
>

it may not have the highest familiarity for Python due to usage being not
very common, but in Rust and C++ any beginner can read types -- they're
required in most function signatures. Remember, I'm arguing for Rust and
C++, not really arguing for type annotations in Python, which I recognize
is already somewhat of a lost cause.

>
> it *wastes time* jacob, adding negligeable value, and is in fact
> *destroying* value.


Having type checking is one of the major ways that Rust is actually a
language where if your code compiles, it is completely correct a
surprisingly high amount of the time (easily >95% of the time for me,
though tests are still definitely useful). Most other programming languages
don't have that feature.

Rust is still surprisingly fast to write (comparable to Python without type
annotations in my experience -- faster than C++) because it has a good IDE
(when using rust-analyzer), and also because inside functions it deduces
types both forward and backward (unlike C++), reducing the need for type
annotations where the types are obvious.

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

>
> 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'm using Python for Libre-SOC because nmigen, not because I like Python.

Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libre-soc.org/pipermail/libre-soc-misc/attachments/20210129/615e957d/attachment.html>