An interesting thread by Kristian Köhntopp last year:
[Archive.is] Kristian Köhntopp on Twitter: “Python: >>> print(1+2+” = “+2+1) Traceback (most recent call last): File “”, line 1, in TypeError: unsupported operand type(s) for +: ‘int’ and ‘str’ Java: System.out.println(1+2+” = “+1+2); 3=12”
The examples from him and others in the thread:
Python: >>> print(1+2+" = "+2+1) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' Java: System.out.println(1+2+" = "+1+2); 3=12 php8.1 -r 'print 1+2+" = "+2+1;' PHP Fatal error: Uncaught TypeError: Unsupported operand types: int + string in Command line code:1 Stack trace: #0 {main} thrown in Command line code on line 1 php7.3 -r 'print 1+2+" = "+2+1;' PHP Warning: A non-numeric value encountered in Command line code on line 1 Node? Chrome & FF dev console: window.alert(1+2+" = "+1+2) 3 = 12 Sind ja immerhin verschiedene Sprachen. SELECT Wert1 FROM table1 WHERE Wert1 < AVG(Wert1); DB2 vs. Oracle vs. MSSQL vs. ....
The joke is that Python actually does better than Java.
But in practice, this is a problem on many platforms, so it deserves constant attention, that’s why Kristian pointed to [Archive] Anna “Legacy Archaeologist” Filina on Twitter: “My annotated slides “Fantastic Bugs and How to Avoid Them” from @LonghornPHP: #LonghornPHP”
[Wayback/Archive] Fantastic Bugs and How to Avoid Them – Speaker Deck
I’ve expanded the examples from the thread below. The results are interesting and consistent over versions of the various languages.
–jeroen
PS: Some interesting Twitter comments below (edited 20221008)
- [Wayback/Archive] Jan Walzer on Twitter: “@jpluimers These dimensions (compiled/interpreted and typesafety) are quite orthagonal and independent. For typesafety to be useful, you also need a rich type hierarchy. I mean, you can of course have “I only have a type Integer” and be fully type safe, but thats without much use.”
- [Wayback/Archive] Reinier on Twitter: “@jpluimers Which category does TypeScript fit in?”
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@Pwuts1337 I’m still contemplating about that. What’s your opinion @isotopp?”
- [Wayback/Archive] Kris on Twitter: “@jpluimers @Pwuts1337 That’s at least three things. There is a spectrum of execution between interpretation and compilation, a spectrum of type safety that is independent of execution and a selection of type annotation systems.”
- [Wayback/Archive] Thread by @Pwuts1337 on Thread Reader App
In the most common configuration, were TypeScript is transpiled and then executed as JS, type safety is only as good as the type definitions used. The typedefs of libraries can be lacking or outdated and you’ll only find out when your application throws errors at runtime.
This won’t happen with libraries that are written natively in TS, so the prevalence of bad typedefs is declining afaik.
That TS also supports dynamic types can be an advantage and a disadvantage, but in any case I’d discourage using it when not necessary.
Overall, when the typedefs can be trusted, then TS is a great tool that keeps getting better and provides type safety and assistance while developing, and which underneath still harnesses the flexibility of JS.
Start tweet if you prefer TWitter: [Wayback/Archive] “@jpluimers @isotopp In the most common configuration, were TypeScript is transpiled and then executed as JS, type safety is only as good as the type definitions used. The typedefs of libraries can be lacking or outdated and you’ll only find out when your application throws errors at runtime.”