Live data from Hacker News

Ask HN: Strong vs. weak typing

news.ycombinator.com

1–4 of 4 posts

Ask HN: Strong vs. weak typing

#1
I'm working on a functional programming language and debating the issue of strong vs. weak typing. This is a dynamically typed, interpreted language, so it seems to me that some of the benefits of strong typing (i.e., catching type errors at compile time) are irrelevant.

Currently, for example, ("abc" + 5) will return "abc5", and ([1,2,3] + 4) will return [1,2,3,4]. The necessary conversions are done implicitly.

What I generally hear, however, is that strong typing is preferred. So, I'd like to know: what are some pros/cons of strong and weak typing? Is strong typing always the correct choice?

(For reference, the language I'm working on is Scotch: https://github.com/bendmorris/scotch)

Re: Ask HN: Strong vs. weak typing

#2
Strong typing makes it easier to reason about the correctness of your program. So even if you don't compile, you can reason about it (i.e. check your code). If that is important to you, strong might be the better choice. (Keep in mind it also carries an implementation cost)

If the point of the language is to enable rapid prototyping, you want to be forgiving of errors. They're usually a simple oversight that doesn't significantly impact the outcome of the prototype.

I've oversimplified about a gazillion times. But ultimately, it boils down to "what is the point of your language". There is no absolute "better" for this argument.

Re: Ask HN: Strong vs. weak typing

#3
post #2

Strong typing makes it easier to reason about the correctness of your program. So even if you don't compile, you can reason about it (i.e. check your code). If that is important to you, strong might be the better choice. (Keep in mind it also carries an implementation cost) If the point of the language is to enable rapid prototyping, you want to be forgiving of errors. They're usually a simple oversight that doesn't…

The goal is rapid prototyping. I'd also say that these types of operations can be considered features and not necessarily errors. While string + number is probably usually an error (who hasn't done that at least once), in Scotch, the + operator represents not only addition but list construction and concatenation - so Scotch's + is equal to +, ++, and : from Haskell.

Re: Ask HN: Strong vs. weak typing

#4
I don't think there's a clear-cut winner - it's mostly choice. Strong typing generally allows more solid, less-breakable code; weak typing generally allows quick prototyping and small scripts to be done at a faster pace.

This is why I suggested a -strict flag (https://github.com/bendmorris/scotch/issues/3): if you decide that you're done prototyping, and would like to make what you're doing more explicit.

Another method could possibly be being able to specify in-code that it's strict, perhaps something along the lines of "#flags: strict " for flags always applied to that file? (Yes, that's ugly. I'm talking about the idea, not that particular incarnation of the idea)

This would allow the best of both worlds, without trying to force them to play nice with each other in one file.

However, even while avoiding mixing them in one file, that still raises other issues. For instance, if non-strict file "a" imports strict file "b", is "a" strict? I'd vote not (this would allow the entire standard library to be strict for clarity, and not cause any issues elsewhere), but I'm curious what other people's opinions are.