Hacker News Reader

Comment by willtim | Hacker News Reader

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.

View on HN

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.

> it might not happen until weeks into production.

It should never happen in production - there should be a test that proves this.

with declarative or static typing i don't need a test for this case.

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
  *

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.

Reply on news.ycombinator.com