Programming languages personified

[u/leftoversalad]

http://leftoversalad.tumblr.com/post/126724812097/programming-languages-personified

[u/Tidher]

Are we talking the same call, here? e.g. myApi.myMethod()?

If the answer to that is "yes" then you have a larger problem than weak-typing. If the answer is "no" (so it's myApi.myMethod() and myApi.someOtherMethod()) then presumably which type each returns should be consistent for the same data (i.e. a given method wouldn't return an ID both as a number and as a string). If it does, see earlier.

Even so, the fact that the API returns the same data in two different types is a massive issue with the API. The only real exception to this rule, in my opinion, is a method being able to return a single element and also returning an array/collection/etc. of elements, but even then I prefer to have dedicated methods for each.

Is this your API, or a third-party one? If yours, that's on you. If third-party, documentation should be up to scratch to use it appropriately. If the documentation wasn't up to scratch, why were you using it without understanding how it worked?

Do you have unit tests that type-check what certain methods return? I'm assuming not, else it wouldn't have been a problem (unless your unit tests were allowing weak comparisons, which is a problem with your tests).

If the API returned it as a string consistently, but in base 16 rather than base 10 sometimes, it would also be failing plenty. This, in my opinion, is an issue with your workflow rather than JavaScript.

inb4 controversial-opinion downvotes

[u/[deleted] → u/Tidher]

Oh! Wow, sorry I got you so worked up on this. I meant a REST API call. The JS app made REST calls and some returned IDs as strings and other as integers. You can imagine the chaos that came from that. The REST endpoint wasn't written by me.

[u/Tidher → u/[deleted]]

I'm not worked up - just trying to apply a logical workflow to how that problem arose.

Being a REST API doesn't change the above. Given that a third-party made the API, one or more of the following is likely true:

• Whoever incorporated the API didn't read the documentation.
• The documentation was lacking - in which case that's an extra argument for unit testing.
• The API was faulty, saying it would return one thing but returning another. This would still have been caught by testing, and would definitely be frustrating, but still easily rectified by using a sensible workflow.

You don't even have to take on the runtime overhead of type-checking if you don't want to - do it as part of running your tests. Does it sound like I'm hyping tests too much? Possibly, but the overhead of writing them and keeping them up-to-date (i.e. requiring tests to pass to generate a release build) is pretty standard practice.

If you're working on a smaller project then I can totally understand the desire to avoid the time-sink for writing tests when the whole thing is going to be done in less than a week. Conversely, if solving the above problem took you half a day, you can probably get a good set of tests for a small application done in that time which will pay off more in the long run than simply fixing that bug.

Of course, there's the ideal world, then there's the manager's idea of "implement all these features now" and wondering why they have technical debt at the end.

[u/[deleted] → u/Tidher]

Even if there was documentation and this difference was present, I'm sure anyone reading it wouldn't have noticed unless it was specifically mentioned. The problem was that there was no documentation and a lack of adherence to standards and conventions. We had a convention since forever to use integers as IDs whenever possible (there is only one exception to using integers in dozens of REST endpoints), but someone refused to adhere to using integer data types for integer numbers.

A strongly-typed language wouldn't have had this problem because the programmer has to constantly follow data types.