5 ms·
> Not according to static-typing fundamentalists Not in production software, no. Because even the shittiest dynamic language software still gets run once or tw
by saosebastiao 10y ago
> Not according to static-typing fundamentalists
Not in production software, no. Because even the shittiest dynamic language software still gets run once or twice before it gets put into production.
Type errors are extremely common during development, and that is where static types shine.
> Exactly, and dynamic languages tend to be highly interactive, whereas most languages with highly evolved static type systems tend to have very slow compilers. So the idea that the compiler for that language gives you useful feedback before your dynamic system gives you feedback from actually running the code is at best dubious.
My extremely slow scala compiler can compile 50k lines from scratch faster than a boilerplate rails project can even start up. And I never compile from scratch during development, because I have incremental compilation. Even as slow as the compiler is, it is never as slow as compiling+running code of similar complexity in a repl, and it's not even close.
> I think you are confusing type errors with modeling errors, but that's very common.
Nope. Type errors. Just because they aren't called type errors in one language doesn't mean they are not type errors in another language with a different type system.
- mpweiher 10y ago> Nope. Type errors. I see your "nope" and raise you a "nope, not at all". A lot of these errors have relevant information modeled as strings. Your static type checker is only going to tell you that these are two strings, and yes, they happen to be compatible. Congratulations! Oh, you meant that these things (like SQL statements) should not be represented as strings? And that that modeling should include semantically distinct entities for user strings (need quoting) and SQL syntax (not quotes)? That's modeling, whether you do static type checking or not.
- saosebastiao 10y agoYou mean it's impossible to have compile time type safety of sql queries, and that the compiler can't tell the difference between an SQL string and any other string? You're wrong. http://underscore.io/blog/posts/2015/05/28/typechecking-sql.html http://underscore.io/blog/posts/2015/05/28/typechecking-sql....
- mpweiher 10y agoNo, I most emphatically did not say (or mean) that it is impossible to check this statically. I am saying that this is first a modeling problem, you need to have a model for your SQL. You know, things like SqlStreamingAction[Vector[(String, Int)],(String, Int),Effect] After you have that model for your SQL you can decide whether you want to check it statically or not, but first you need the model. And yes, some languages allow you to decompose compile-time strings into model objects. Still requires you to have a model first, and I have to admit I prefer not having magic strings, but rather have polymorphic identifiers: http://objective.st/URIs http://objective.st/URIs