Hacker News new | ask | show | jobs
by freyrs3 4271 days ago
Safety as you're using is not the concept that Haskeller's refer to when they talk about the language. "Type safety" is a very precise term that refers to several proofs about the semantics of the language.

See: http://jspha.com/posts/all_you_wanted_to_know_about_types_bu...

1 comments

OK. All I am trying to say is that there are different kinds of strong-typed languages, and neither one is "safer" or superior.
I don't think that's true, though. There are "safer" languages (for the informal notion of safety we're discussing). You're free to argue that the safety you gain in one language is not worth the effort, but you cannot argue that every language is equally safe.
Why no? The technical term "type safety" as described in the link above, implies that each value has a type, this type doesn't change during the evolution of a program, etc. How does it differ from the guarantees we have in so-called strong-typed languages?

The fact that compiler is refusing to compile type-mismatching expression for a simple built-in types doesn't imply that it is "safer". Other languages, notably Lisp and Erlang will catch and signal the same error later, at runtime.

I am not a Haskell guru, but what I see, especially in the case of Monads, is an implicit type-tagging with additional tag - name it State, or IO, or Safe and then type-checking against them.

I cannot see the fundamental difference which gives that "extra safety".

>How does it differ from the guarantees we have in so-called strong-typed languages?

If you mean "dynamically typed" languages, then it differs in that they do not have types.

>The fact that compiler is refusing to compile type-mismatching expression for a simple built-in types doesn't imply that it is "safer"

No, it does not imply that. It means that.

>Other languages, notably Lisp and Erlang will catch and signal the same error later, at runtime.

Precisely. So if that piece of code was not executed, you do not know that it is incorrect. If that branch is only followed rarely, your incorrect code is out there in production waiting to blow up when it finally does run that branch.

>I am not a Haskell guru, but what I see, especially in the case of Monads, is an implicit type-tagging with additional tag

The article in question does a good job of explaining monads.

> The fact that compiler is refusing to compile type-mismatching expression for a simple built-in types doesn't imply that it is "safer".

That's not all a statically typed language does.

Regardless, they are safer. The usual counterargument goes that this safety is too much of a burden, or not worth it, etc. But nobody I know argues they are equally safe.

Because you've defined "safety" to encompass several orthogonal concepts and as such is meaningless. If you look at each axis on it's own ( type safety, memory safety, exceptional safety ) then Haskell will come out as safer than nearly any other available tool.