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

[Luke Kenneth Casson Leighton]

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.

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

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

3) time-saving violated: how much effort did it take to add - to type
- these completely unnecessary types?  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 *wastes time* jacob, adding negligeable value, and is in fact
*destroying* value.

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.

l.