The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.
Type inference takes away the main argument against static typing: That static typing requires you type in a bunch of useless obvious types.
Like, type inference is pretty widely regarded as a definite good. Additionally, technologies like row polymorphism make it possible to have statically typed and inferred duck typing. To me it's hard to hear this as anything other than mission accomplished. We made a static language that looks and feels like a dynamic one.
If you don't like type inference, you'll need to offer additional explanation as to why it is bad. Because otherwise you're statement only sounds like the one I made above. It sounds weird because one doesn't necessitate the other AND because they're both widely considered good.
Nearly all the type errors I see are things like
var foo = "Hello World";
bar = foo + 10;
You could imagine it having built-in rules for JS' coercions:
string + number -> string
number + string -> string
At which point it's similar to languages with `Int + Float -> Float` and `Short + Long -> Long` in that perhaps you wish those operators weren't defined but it's at least consistent. And you'd find the error once you've passed those results to a function that expected Int or Short.
Maybe it was this.
function suffixWith10(s: string) { return s + 10; }
But if the intent can be discovered by analysis of usages of the variable later in the code, then TS will scream loudly.
var foo = 5;
var bar = 100;
baz = foo + bar;
Appending an integer to a string is comparatively sensible next to adding age in years to pixels from edge.
Appending a number to a string is a perfectly sensible thing to do when you're displaying information to a user, yet adding two numbers or concatenating two strings could be completely senseless and proof that the development process has gone off the rails.
My dream type system is strict about semantics and only handles representation in specific circumstances. The simplest way to talk about this is in terms of units of measure: Height is a type. Whether it's in inches or centimeters is a representation. Whether that representation is a number or a string is another representation. Keeping track of whether you're showing height-in-inches or height-in-centimeters to a user is useful, but burdening your mind with whether this height-in-inches is a string or a number right now when the runtime can just as easily convert between the two is senseless, and fretting over height-in-inches versus height-in-centimeters adding person-height to shoe-sole-height to get height-in-shoes is similarly senseless.
I've yet to see a strictly/strongly typed language that makes this easy to do. Through some combination of plugins, esoteric languages, macros, or boilerplate, sure.
We're decades behind what is possible due to the practical.
You know because you should be using sensible variable names that make it obvious.
The IDE and the compiler will both scream if you try something like
var x = “John Smith”;
x = 5;
var foo = {bar = 1, baz = “Hello”, boo = “World”};
You get auto complete help and compile time type checking.
foo.bar = “Goodbye”;
Won’t compile. What would it buy you to not use ‘var’ and create a one time use class/struct?
var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age}
foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); }
Why would I create a class/struct for that use case?
Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory List, a Sql table or a MongoDB collection and the LINQ expression will be translated appropriately to the underlying query syntax.
The “ORM” is integrated into the language and yes anyone can write a LINQ provider.
How do you feel about deconstructuring that is available in most languages?
If I had to review the code and saw an explicit type I would recommend an anonymous type.
Changing select new {...} to Select new SeniorPeople {...} wouldn’t give you any more information. At most if I was writing that as part of a repository class I would be sending you back an IEnumerable<SeniorPeople>.
If you were to send me an expression to use in the where clause you would send me an
<Expression<Func<SeniorPeople,bool>>
You have no idea what that expression is going to be translated to until runtime.
Either way, you are just working with non concrete Expression Trees that could be transformed into IL, SQL, a MongoQuery etc. All of the constrainsts would be handled by your data store.
You don’t even know before hand whether you are iterating over an in memory list, or streaming from an external data source.
I could switch out Sql Server for Mongo and you as the client wouldn’t be any the wiser.
And we haven’t even gotten to the complication if the result set was the result of a LINQ grouping operation.
Yet, any code using its result will contain implicit assumptions about that data. Therefore, in order to maintain type safety, the expected type of the return value must he stated.
That type must also be independent from whatever LINQ does internally to produce that return value. Otherwise, the LINQ providers wouldn't be as exchangeable as you claim.
class Foo {
public uint Bar { get; set; }
private char[] _baz;
public char[] Baz { get { return _baz;} }
public Foo() { _baz = new char[5]; }
}
If your environment is so relaxed that aspects like signedness of an integer don't matter, so be it. But then you are also far removed from a domain where software correctness is non-negotiable.
Are you really trying to go back to the bad old days with Microsoft C/MFC/WIN32/COM where you had over a dozen ways to represent a string that you had to convert to and from depending on which API you were using?
for (auto it = s.begin(); it != s.end(); it++) {
is much easier to write than
for (vector<int>::iterator it = s.begin(); it!=s.end(); it++) {
Templates (template metaprogramming) help to avoid exceptions. You can check invariants first and jump into efficient code.
for (auto &element: s){
even better with structured bindings:
for (auto [key, value]: map){
auto is not a code smell on the contrary, it is used when your type system is easy enough to reason about that you don't need to write the actual type.
If you're worried about spending time changing type names during a refactor, look at it instead as an opportunity to evaluate the correctness of the code in the context of your replacement type. Use of the auto keyword avoids doing that and as a result enables you to create new and exciting bugs in your code.
because : - easy to reason about and easy to type are two differents things - naming everything increases mental load
> Use of the auto keyword avoids doing that and as a result enables you to create new and exciting bugs in your code.
to the contrary, porting a lot of my code to use almost-always-auto did actually remove bugs in the form of silent type conversions happening - e.g. std::pair<std::string, int> instead of std::pair<const std::string, int> (yay memory allocations), bad fp conversions...