<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 05:11 Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net">lkcl@lkcl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jan 28, 2021 at 9:43 PM Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" target="_blank" rel="noreferrer">programmerjake@gmail.com</a>> wrote:<br>
<br>
> however, that is only the first half of the article, the last half's argument still applies even without type confusion.<br>
<br>
(bear in mind that i am a c/c++ programmer before learning python)</blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
there is no confusion, only a complete fundamental blindspot.  i<br>
stopped reading at that "second strike".  the "first strike" was the<br>
denigration and devaluing of unit tests.<br>
<br>
this article is fundamentally and deeply flawed, written by someone<br>
with a massive blindspot as to why python exists, why it is popular,<br>
and why it is successful despite multiple repeated efforts to say it<br>
"cannot be because it doesn't have strong types".<br>
<br>
the FUNDAMENTAL basis of python is the fact that +, > and other<br>
operators call __add__, __gt__ and so on, in combination with coerce.<br>
if you do not know about type-coercion and its ordering you need to<br>
look it up, urgently.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Python is far from the only language with type coercion and operator overloading, Rust and C++ have that too.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
i know you keep trying to add types into code written in python: i<br>
keep telling you and one day it will sink in that this fundamentally<br>
goes against CRITICALLY important aspects of python:<br>
<br>
1) compactness<br>
2) readability<br>
3) time-saving<br>
<br>
look at the following example:<br>
<br>
def fn(a,b,c,d,e,f,g,h,i,j,k):<br>
  (l,m,n.o,p,q,r) = (0,1,2,3,4,5,6)<br>
<br>
now expand that out with the (i have to say this: stupid, irritating)<br>
forced type-checking.<br>
<br>
now count the number of lines of code.<br>
<br>
2 lines of code became.. what... 25?  and for what??<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1) compactness violated: it spreads the function out, forcing the<br>
reader to scroll down, doesn't it?  the "bang-per-buck" - information<br>
conveyed per page - is greatly reduced.<br>
<br>
2) readability violated: did it *actually* improve readability?  you<br>
KNOW what the types are of l thru r because ON ONE LINE they're right<br>
there: ints.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  and because you are keeping code SHORT, the same logical<br>
inference and/or "reading the docstring" tells you exactly what the<br>
type is... not that you care because you know the Liskov Substitution<br>
Principle *and apply it*.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) time-saving violated: how much effort did it take to add - to type<br>
- these completely unnecessary types?</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and how much effort did you<br>
impose on people not familiar with the (irritating) type-declarations,<br>
by increasing the amount of time it takes them to parse the unfamiliar<br>
format?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
it *wastes time* jacob, adding negligeable value, and is in fact<br>
*destroying* value.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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<span style="font-family:sans-serif"> as a commonly used technique</span> (where the APIs are designed to be very hard to misuse intentionally/accidentally, which is defacto standard in Rust).</div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote></div></div><div dir="auto"><br></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 dir="auto"><br></div><div dir="auto">Jacob</div></div>