Show HN: I Wrote a Book on Java

Re:Show HN: I Wrote a Book on Java by lelanthran on Tuesday September 24, 2024 @12:18PM (#41638154)

> You'll get a runtime TypeError if you try to add a number to a string, for example,

A popular but nonsensical myth:

    $ cat t.py
    def foo(myval):
       return myval * 12
    
    print (foo("a"))
    $ python3 t.py
    aaaaaaaaaaaa

In real-world usage, Python's "typing" is about as helpful as Javascript's "typing". Plain old C has stronger typing guarantees than Python/PHP/etc.

[ Parent | on HN ]

Re:Show HN: I Wrote a Book on Java by zahlman on Tuesday September 24, 2024 @02:35PM (#41639580)

Defining an operation between two different types is not at all the same thing as enabling implicit conversions. Notice for example that "1" * 2 gives "11", and not "2" nor 2. Interpreting multiplication of a string by an integer as "repeat the string that many times" doesn't require any kind of conversion (the integer is simply a counter for a repeated concatenation process). Interpreting addition as "append the base-10 representation of the integer" certainly does. (Consider: why base 10?)

You have a point that strong vs weak typing is not a binary and that different languages can enable a varying amount of implicit conversions in whatever context (not to mention reinterpretation of the underlying memory). But from ~20 years of experience, Python's type system is nothing like JavaScript's - and it's definitely helpful to those who understand it and don't fight against it.

In my experience it's typically people from languages like Haskell that can't see the difference.

[ Parent | on HN ]

Re:Show HN: I Wrote a Book on Java by Tainnor on Tuesday September 24, 2024 @06:02PM (#41641438)

that's just operator overloading and it exists in many statically typed languages too

[ Parent | on HN ]

Re:Show HN: I Wrote a Book on Java by lelanthran on Wednesday September 25, 2024 @01:48AM (#41644075)

> that's just operator overloading and it exists in many statically typed languages too

My point is that Python's "typing" guarantees allow a caller to call a function with the wrong type, and get back a wrong answer and/or silently lose data.

Strong typing is pointless if the language is unable to actually prevent common footguns, like passing in the incorrect type.

I'm moving more and more to the opinion that arguing about the spectrum of strong <-> weak typing is stupid, because type utility is on the spectrum of static <-> dynamic, with dynamic being full of footguns.

[ Parent | on HN ]