News for hackers. Stuff that matters.
Re:We don't need runtime type checks by raxxorrax on Thursday March 03, 2022 @03:48AM (#30538697)
I often think people don't have a problem with static types and instead would miss the implicit type conversion dynamic typing provides.
Re:We don't need runtime type checks by DonaldPShimoda on Thursday March 03, 2022 @02:27PM (#30545535)
> miss the implicit type conversion dynamic typing provides

Implicit type conversion is not an inherent property of dynamic typing. For example, Python does not do implicit type conversion except in arithmetic. You can't do, e.g., `4 + "hello"`.

Leaving that aside, though... I'm actually not convinced implicit type conversions are much of a win, especially when it comes to types other than the simple arithmetic ones (and those can often be handled in explicit type-checking anyway, through a numerical type hierarchy). I would rather be forced to handle explicit conversion everywhere I want it than accidentally forget about some edge case and end up with an unintended implicit conversion that causes unexpected behavior at run time.

Re:We don't need runtime type checks by chriswarbo on Thursday March 03, 2022 @02:50PM (#30545864)
> Python does not do implicit type conversion except in arithmetic. You can't do, e.g., `4 + "hello"`

Interestingly, PHP uses separate operators for numerical addition (+) and string concatenation (.), so it's actually a bit more explicit than e.g. Javascript (where 'x + y' could result in normal numerical addition, or normal string concatenation, or implicit conversion to a numerical addition, or implicit conversion to a string concatenation!)

Re:We don't need runtime type checks by throw_m239339 on Thursday March 03, 2022 @03:13PM (#30546238)
> Interestingly, PHP uses separate operators for numerical addition (+) and string concatenation (.), so it's actually a bit more explicit than e.g. Javascript (where 'x + y' could result in normal numerical addition, or normal string concatenation, or implicit conversion to a numerical addition, or implicit conversion to a string concatenation!)

Only because Rasmus didn't know how to design and implement a "proper" programming language. This isn't a intended feature, it just made parsing easier for him.

Re:We don't need runtime type checks by onaworkcomputer on Thursday March 03, 2022 @03:32PM (#30546544)
Rasmus borrowed this distinction from Larry Wall, since PHP was originally implemented in Perl (which also uses + for addition and . for string concatenation).

The neat thing about PHP and the + operator is that you can sometimes trick the interpreter into doing math on the underlying bytes of the string: http://dominic-mulligan.co.uk/wp-content/uploads/2015/05/SRE...

Re:We don't need runtime type checks by TazeTSchnitzel on Thursday March 03, 2022 @03:36PM (#30546596)
There's nothing improper about having a separate operator for concatenation.
Re:We don't need runtime type checks by throw_m239339 on Thursday March 03, 2022 @03:45PM (#30546721)
> There's nothing improper about having a separate operator for concatenation.

Only to monopolize that operator to then have to use "->" for method call. C/C++ do that because of dereferencing. There is no need for that in PHP OO, all objects are passed by pointer to functions or methods.

Re:We don't need runtime type checks by giaour on Thursday March 03, 2022 @05:57PM (#30548180)
Meh, other languages manage to assign multiple meanings to single tokens and depend on context to resolve ambiguity. PHP's issue here is that it refuses to do so, which is how we ended up with the backslash as a namespace delimiter.
Re:We don't need runtime type checks by paskozdilar on Thursday March 03, 2022 @03:23PM (#30546432)
I love Python because you can just do

    foo = "bar"
and be done with it. The interpreter knows it's a string variable. But I don't really care about runtime dynamic typing - I can't wait for Go to get parametric polymorphism, interfaces and runtime type dispatching can be quite clumsy. I would be perfectly fine with typed function arguments in a Pythonic language and being able to only call functions that fit the variable type (which is what I end up doing anyway with typehints and mypy).

I think Go made a right decision there - they kept the static typing but added a walrus := operator for automatic type inference. Every function has a type signature so the type inference algorithm is pretty trivial, and the language still feels like Python:

    result, err := FunctionThatMayFail()
Re:We don't need runtime type checks by kaba0 on Friday March 04, 2022 @04:26AM (#30552460)
Basic type inference has been around for decades, Go isn’t responsible for it. Haskell, scala, etc had it for a long time.
Re:We don't need runtime type checks by paskozdilar on Friday March 04, 2022 @01:23PM (#30558415)
>Basic type inference has been around for decades, Go isn’t responsible for it.

I never said it was.

Re:We don't need runtime type checks by 89vision on Thursday March 03, 2022 @02:31PM (#30545600)
I think scala strikes a pretty good balance here. It's statically typed, but the compiler will attempt to infer types if not explicitly defined. If you want an implicit type conversion the type conversion function needs to be defined and in scope
Re:We don't need runtime type checks by convolvatron on Thursday March 03, 2022 @02:41PM (#30545727)
those a pretty orthogonal issues, you can make a system arbitrarily static or dynamic with or without implicit conversion
Re:We don't need runtime type checks by david422 on Thursday March 03, 2022 @02:38PM (#30545687)
Do you mean something like passing a string to a function and later passing a number and have it still act appropriately?
Re:We don't need runtime type checks by dboreham on Thursday March 03, 2022 @03:44PM (#30546710)
Welcome to JavaScript.