

Ask HN: Strong vs. weak typing - bendmorris

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.<p>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.<p>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?<p>(For reference, the language I'm working on is Scotch: https://github.com/bendmorris/scotch)
======
groby_b
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.

~~~
bendmorris
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.

------
duckinator
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.

