"What if...
- your programming language required you to write useful docs,
- using those docs, it checked your program for mistakes,
- it even used the docs to speed up your program,
- this feature already exists!
And what if it was called static typing."
Because of the above, types really don't seem like "useful docs" to me. I get extremely irritated when a library links to its API documentation and it's all just autogenerated lists of methods which proudly state their parameter and return types but say absolutely nothing about what they do.
That's one major thing I've always appreciated about the Ruby and Javascript ecosystems: because they can't rely on type information, most libraries go out of their way to describe how they work in depth.
I'm willing to grant that I didn't have a ton of experience with Java before moving on to other languages, and so I could very well be wrong... but one thing that definitely worries me about Typescript is the increasing Java-fication of browser languages.
Now, all that being said, I gave Crystal [0] a spin the other day and it's a freaking dream. Ruby, but with types, and compiled to LLVM? YES PLEASE.
There's a certain argument that this is the sign of an inadequate type system: you're getting the overhead but it's not rich enough to be self-documenting or provide really rich analysis tools.
This means that the trade-off Crystal give could be way better than the one Ruby gives, despite Ruby giving a better trade-off compared to Java (for some use cases). For other problems Rust, Go or C could give a better trade-off.
It is not a discussion about if types, all other things equal, are good or not. The reason behind this is simple: Not all other things are equal and not all type systems are equal.
There is better out there. Sadly, for the longest time, the best examples didn't receive much interest outside of academia, on account of languages like Java being so entrenched. But it is worth spending some time with a member of the ML family to get a taste of what static typing could have been like.
C, golang
Scala gets around this by attempting to extend the type system in deeply incompatible ways. Which mostly works, as long as you don't care about compatibility.
Clojure gets around this through a combination of dynamic typing and Rich Hickey including a section titled "I Don't Need Any Sour Grapes" in every lecture he delivers in public.
Of the three, TBH, I think Clojure has the best approach. You can't build proper static typing on top of the JVM without breaking compatibility with the rest of the Java ecosystem. At which point, why bother with the JVM at all?
Not nearly as C or golang.
So are C and golang, even more so arguably.
I don't think that's fair.
I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it.
Java can be programmed as lightly as Python or as a full-on J2EE monstrosity. The difference is cultural ("idiomatic") not brought about by types.
I wish I had the money to burn to buy a billboard in Silicon Valley to broadcast this.
I find that the extreme majority of the hate Java gets isn't really about Java itself, but the extreme adherence to the worst paradigms and idioms I've ever seen in the programming world.
Stop writing so many classes. I'm sure everyone here has seen FizzBuzz Enterprise Edition [0]. Sure, it's a parody, but a lot of truth is said in jest. There's too much Java code that looks like FizzBuzz EE, and there's no damn reason for it.
> I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it.
I really wish I could understand why so many Java programmers feel like you can't just write a class. Nope, you have to make an Interface, with an abstract class that implements it, followed by your Implementation class that extends the abstract. But directly calling that constructor is verboten! You need to create a Factory class (With associated abstract class and interface, of course!) that returns instances!
[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Nothing in Java prevents a Java network lib from doing it in one line. In fact many third party network libs do just that.
(And Python had more or less a similar unwieldy network lib, which is why they now say "Requests is suggested" on their own standard lib documentation: https://docs.python.org/2.7/library/urllib.html ).
So again it's not the language (syntax + semantics), it's what's considered "idiomatic" and what's prevalent.
I have it seen done in Clipper, C, C++ and I bet even Go will one day have its Go2EE, it just needs a bit more enterprise love.
Right. The difference is that for some reason, writing Java in the J2EE style seems to be the default, and rather than stopping the practice, people choose to hate the language instead, as if they think the J2EE style is required by the language.
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.
Type inference takes away the main argument against static typing: That static typing requires you type in a bunch of useless obvious types.
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...
The IDE and the compiler will both scream if you try something like
var x = “John Smith”;
x = 5;
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.