The advantages of static typing, simply stated
pchiusano.github.io
The advantages of static typing, simply stated
1–10 of 127 posts
Re: The advantages of static typing, simply stated
#2My disagreement starts with the beginning of this:
"A large class of errors are caught, earlier in the development process, closer to the location where they are introduced."
I would re-state this as:
"A large class of errors are introduced, which otherwise would not exist."
Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in the code. Given JSON whose structure changes (because you draw from an API which leaves out fields if they don't have data for that field) your only option is to cast to Object, and then you have to guess your way forward, figuring out what the Object might be.
Consider the Salesforce clone of Java, Apex, which I have had to work in this month.
The if() statements here are the same one's that I would have to write in Ruby or Python or PHP, but meanwhile I've had to do a bunch of other, useless work:
public Object deserializeJson(String sandi_data) {
System.debug(sandi_data);
Object objResponse = JSON.deserializeUntyped(sandi_data);
if (objResponse instanceof Map) {
Map mapResponse = (Map)objResponse;
List dataList = (List)mapResponse.get('data');
if(dataList == null) {
String err = 'The Sandi API field for data was null';
System.debug(err);
ApexPages.Message msgErr = new ApexPages.Message(ApexPages.Severity.ERROR, err);
ApexPages.addmessage(msgErr);
return null;
} else if (dataList.isEmpty()) {
String err = 'The Sandi API field for data was empty';
System.debug(err);
ApexPages.Message msgErr = new ApexPages.Message(ApexPages.Severity.ERROR, err);
ApexPages.addmessage(msgErr);
return null;
} else {
System.debug('dataList:');
System.debug(dataList);
return dataList;
}
}
return sandi_data;
}
List dataList = (List)deserializeJson(sandi_data);
for(Integer i=0; i dataMap = (Map)dataList[i];
System.debug('dataMap:');
System.debug(dataMap);
String response = fetchCompany(dataMap);
SearchResult__c profile = saveProfileResult(response);
cr.add(profile);
}
Again, some of the if() statements need to be made in Ruby or Python or PHP, but the rest of it is just pure bloat. Verbose, unneeded and unhelpful.
In a dynamic language I could simply work with a deeply nested data structure of maps and lists, and I'd handle the casting at the very end of the process. In a dynamic language, I could treat everything as a string till the very end, and then cast to integers or dates or floats or strings as needed. In a dynamic language, I could write the code faster, with less errors, and with less code.
Static typing does not live up to its promises.
[ Edit to add ]
We have no control over the API that we draw from. We are drawing from the API of a different company. I wish they didn't use JSON. If they have to use JSON, I wish they at least enforced a consistent schema. But they don't. And that is why static type checking fails: because the real world is chaotic, and when you have to interact with that real world, you are often forced to do so dynamically, because of the mistakes that other companies have made. The real world is dynamic.
The idea that you can know an external API perfectly is a fantasy. The real world is messy. The real world does not always conform to a strict schema.
The notion that An External API Is Reliable is as stupid as the notion The Network Is Reliable:
https://blog.fogcreek.com/eight-fallacies-of-distributed-com...
[[ Further edit to add ]]
the_af wrote:
"Using dynamic typing will just hide the problems under the rug, and they will explode in your face later on. Static typing just made those problems explicit."
What I wrote was:
"In a dynamic language I could simply work with a deeply nested data structure of maps and lists, and I'd handle the casting at the very end of the process"
I'll simplify this: there are 3 times when we can enforce a schema:
1.) when the API call returns with a string
2.) on every line, scattered through dozens of functions
3.) at the end, when I have the data that I want
In my original comment, I advocated for #3. Here are the reasons I don't like the first 2 options:
#1 - the external API is bloated, so writing a schema for the whole thing would be difficult to justify in terms of business. We only need a tiny slice of the data.
#2 - having casting discovery information scattered through dozens of functions makes the code brittle and refactoring difficult.
With Ruby or Python or PHP or any dynamic language I have the option of #3: grab the data, cast everything as a string, grab the tiny sliver of data I actually need, and then enforce the schema on that tiny sliver. This is the data that I can cast to integers, floats, dates, etc -- whatever is actually needed.
In static-type languages such as Java, I'm forced to go with either #1 or #2, and they are both bad options.
About this, from tigershark:
"it is only the usage of an awful JSON library in a not so nice language"
Bad JSON is part of the real world. If your static-type language can not handle bad JSON, then it can not handle the real world. That is my point: static-type checking is too academic, too pure, for the real world.
As to "not so nice language", you are engaging in the No True Scotsman fallacy, which goes like this: no True statically typed language would be this bad! But following the No True Scotsman illogic, the rest of your unstated assumptions amount to: It's only the statically typed languages that most programmers actually use that are this bad! But somewhere there is a statically-typed language of such unbelievable purity, it overcomes all of these problems!
Re: The advantages of static typing, simply stated
#3My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON libraries offer very easy parsing (e.g. "json_get_int(element, key)") that fails early. I almost don't even think about JSON twice if I have to use it as a data format in a C++ program I'm working on. It's just another library to link against and use almost effortlessly. Doesn't Java, or this Salesforce implementation of it, have something similar?
Furthermore every dynamic language I've used has had tooling spring up, e.g. in the form of linters, that includes at least some basic checking for type mismatch where possible. I'm not so sure static typing leads to problems. It isn't problem free--no programming language or paradigm is--but I do think the lack of it leads to some problems that are easily avoided without too much extra overhead.
Re: The advantages of static typing, simply stated
#4My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…
Yup. The correct solution to this is schemas, not throwing away typing information.
Re: The advantages of static typing, simply stated
#5My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…
We have no control over the API that we draw from. We are drawing from the API of a different company. I wish they didn't use JSON. If they have to use JSON, I wish they at least enforced a consistent schema. But they don't. And that is why static type checking fails: because the real world is chaotic, and when you have to interact with that real world, you are often forced to do so dynamically, because of the mistakes that other companies have made. The real world is dynamic.
Re: The advantages of static typing, simply stated
#6My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…
Meh. A good JSON library for Java can still make it fail fast and fail early, and using Java's reflection it can be pretty concise too.
Re: The advantages of static typing, simply stated
#7My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…
> your only option is to cast to Object
In Java JSON is horrible for serialization because of Java behaviors (your best option is Object). That doesn't mean JSON is horrible for serialization, in general. Fields do have types (int, string, object, array) making it slightly better than arbitrary serialization.
Re: The advantages of static typing, simply stated
#8My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
That Salesforce has a relatively broken variant of a less-than-ideal statically typed language is less a problem with the idea of static typing than with Salesforce's crappy implementation[1].
There are less awful ways to deserialize JSON in other languages. In C# with JSON.Net, you have options ranging from very dynamic-style handling, all the way to fully-typed deserialization into POCOs, for example.
[1] I have no love for Salesforce; it's a mess. Their weird custom dialect of SQL for a REST API query language is also buckets of fun.
Re: The advantages of static typing, simply stated
#9My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…
I think the problem in your example is mostly related to the fact that Java syntax is just horrible for dealing with JSON - not really an issue of typing.
If Java were conceived of today - I think it might look a little different with respect to this.
I'd like to point out that there are many areas wherein fluid typing might help a little bit, especially on the UI.
Have to make a class for 'every little thing' gets cumbersome.
I wish there was a 'lighter typing' opportunity in some cases (schema-ish JSON).
But I agree that in the long run, static typing is really the way to go for the most part.
Re: The advantages of static typing, simply stated
#10Earlier quoted context omitted.
Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…
We have no control over the API that we draw from. We are drawing from the API of a different company. I wish they didn't use JSON. If they have to use JSON, I wish they at least enforced a consistent schema. But they don't. And that is why static type checking fails: because the real world is chaotic, and when you have to interact with that real world, you are often forced to do so dynamically, because of the mistak…
The way you talk about static vs dynamic suggests that you only have a very vague idea of what these mean.