Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Good reply, but the benefits you described are already realized by strong typing, which is not the same as static typing.

A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code. Thus, those are bugs that are trivial to solve.

And this, to paraphrase your post, protects your code from changes that introduce subtle bugs.

You can also have a language that is statically typed but that has weak typing! Which language? C. And i think everybody knows the extra effort needed to keep a C program bug free. And this not only due to lack of automatic memory management!

I have been programming for most of my life, that is about 23 years of programming on where 20 of those years were using statically typed languages, including many years programming on large, business-core systems on Java and C#. I since have gone to dynamically typed languages and never looked back. You just need strong typing, that's enough.



A compiler verifying against a static strong type system proves certain properties about your program which provides some assurances about what your program can and cannot do.

You might be able to prove more assuring properties about your program with a test suite.

When the GP said:

> A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types!

I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite.

> A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code.

A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent.


> I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite.

Yes, this is exactly what I meant. Well, I was really arguing for both, static and strong typing, although my argument concentrated more on the "static" part, as that gives you safety and correctness guarantees that cannot be achieved with assertions and unit testing at all.

> A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent.

I relied on type inference a lot when writing OCaml code. However, I noticed that on some places I still want explicit types. (I just don't want to be forced to type them on every variable.) For example, on most function definitions an explicit type helps a lot. Otherwise, the compiler can only tell you that your function call doesn't match your function - but can't tell you whether your function is wrong, or the code using it. With an explicit typing of the function, you know exactly which side is wrong. Also, in case it is the function, you'll note this when writing the function, not later on when trying to use it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: