3 ms·

It's a nice error message, but it's a runtime error, it might not happen until weeks into production. It's technically just a crash with a useful error message.

It's a nice error message, but it's a runtime error, it might not happen until weeks into production. It's technically just a crash with a useful error message. "strict typing that enforces type declarations" is generally called static typing, and does not necessarily always require annotations or declarations. It spots such errors at compile time using static analysis.

F-0X 7y ago
> it might not happen until weeks into production. It should never happen in production - there should be a test that proves this.
- em-bee 7y ago
  with declarative or static typing i don't need a test for this case.
  - lispm 7y ago
    That's where a dynamically typed language with optional typing gets handy, when a compiler supports it... In Common Lisp, the SBCL compiler would be such an example: * (defun foo () (let ((i 10) (s "20")) (concatenate 'string s i))) ; in: DEFUN FOO ; (CONCATENATE 'STRING S I) ; ; caught WARNING: ; Derived type of I is ; (VALUES (INTEGER 10 10) &OPTIONAL), ; conflicting with its asserted type ; SEQUENCE. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition FOO *
- willtim 7y ago
  To quote Dijkstra, testing shows the presence, not the absence of bugs. If you want to actually prove the absence of these classes of bugs then you need a static type system.
em-bee 7y ago
correct, and i am a fan of that too, but the poster above was conflating weak typing with dynamic typing, which are entirely different things. my preferred language is pike, which is a strong and declarative typed language (declarative typing is the term i prefer since not everyone defines static typing the same way, and some statically typed languages are weak, like this example here) pike does catch type errors at compile time, but behaves like a strong dynamic typed language at runtime. i understand that python and rubys optional types now allow for something similar.

F-0X 7y ago

> it might not happen until weeks into production. It should never happen in production - there should be a test that proves this.

em-bee 7y ago
with declarative or static typing i don't need a test for this case.
- lispm 7y ago
  That's where a dynamically typed language with optional typing gets handy, when a compiler supports it... In Common Lisp, the SBCL compiler would be such an example: * (defun foo () (let ((i 10) (s "20")) (concatenate 'string s i))) ; in: DEFUN FOO ; (CONCATENATE 'STRING S I) ; ; caught WARNING: ; Derived type of I is ; (VALUES (INTEGER 10 10) &OPTIONAL), ; conflicting with its asserted type ; SEQUENCE. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition FOO *
willtim 7y ago
To quote Dijkstra, testing shows the presence, not the absence of bugs. If you want to actually prove the absence of these classes of bugs then you need a static type system.

em-bee 7y ago

correct, and i am a fan of that too, but the poster above was conflating weak typing with dynamic typing, which are entirely different things. my preferred language is pike, which is a strong and declarative typed language (declarative typing is the term i prefer since not everyone defines static typing the same way, and some statically typed languages are weak, like this example here) pike does catch type errors at compile time, but behaves like a strong dynamic typed language at runtime. i understand that python and rubys optional types now allow for something similar.