On 12/31/2013 08:06 AM, Carter Schonwald wrote:
as a counter point, in strongly typed languages (of which rust is one), the
type checker is a great aid in fixing breaking changes :). In fact it makes
addressing such breakages quite easy.
This is pretty notable in other strongly typed langs like haskell, when
theres been breaking changes, its usually less than 30 minutes of work to
fix any breakages in an entire code base, with the exception of libraries
that (ab)use exotic experimental features in ways that are tricky to write
otherwise. IN fact, one breaking change that is scheduled for next year in
haskell actually had the most vocal support from industrial users,
including several organizations that have financial trading systems using
the language.
point being, in a strongly statically typed language, when making (small/
thoughtful) breaking changes to core apis or type system details, its quite
manageable to identify all the points of breakage in client code, and the
main issue is moreso the quality of the error messages. (and theres always
room for better error messages :) ).
admittedly its always ideal to get the design right the first time, but
sometimes its worth it to improve a tool at the expense of its users
(happily) spending half an hour or so placating the type checker after the
language update.
happy new year!
-Carter
While I seriously doubt about "30 minutes" for an entire code base (even small)
(if only because one does not always maintain one's own code, or it's several
people's code, or one has switched to other projects in the meantime), I do
otherwise agree because I often break my own code intentionnally after
rethinking, rewriting or just cleaning low-level utilities (an app's inner lib
so to say). Usually a quick and easy fix, actually even in dynamically-typed
langs (even with rather weak typing like Lua).
I also share the last point "sometimes it's worth it to improve". I would not
count backward compatibility as important as, less so having precedence over,
language quality (same about libs and tools). Either an envisioned improvement
makes a significant difference in quality and we _ought to_ do it; or not. In
any case, this does not prevent making the life of maintainers of existing code
as nice and easy as possible, but let us not engrave design error in marble ;-)
as if they were natural laws. [*]
I know this is a very unpopular position thought ;-)
Denis
[*] Not to speak of design errors propagating from "successful" (lol!) languages
to others. "=" for assignment and "==" for equality is still the source of my
favorite syntactic mistake, after decades of programming mostly in mainstream
languages that all implement that funny convention (let's use, say, "if" instead
of "try", and then have, say, "switch" or "altern" [or "iff"!] mean "if" as a
replacement).
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
