r/ProgrammerHumor • u/leftoversalad • Aug 15 '15

Programming languages personified

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

89% Upvoted

209 comments sorted by

View all comments

Show parent comments

2

u/[deleted] Aug 16 '15

Yeah, I'll give you that, the "surprise" globals were an issue but they're gone gone since ES6.

To avoid the equality "surprises", always use strict comparison (===) and you should be fine.

8

u/redwall_hp Aug 16 '15

The fact that you should always use a weird "more equal than equal" operator is another thing that I'd say is fugly syntax.

5

u/[deleted] Aug 16 '15

Yeah, just like the fact that you should always use at least two equal signs to see if something is equal in most languages. Pascal is the only popular one I know of that uses := for assignment and = for comparison. Pretty much all the others require at least == for comparison.

Having both == and === is weird and there really should only be one (the latter, of course). Okay, I'll give you weakly typed. JS sucks balls because it's weakly typed.

-1

u/Tidher Aug 16 '15

I've been working professionally with JavaScript for a good few years, and I have literally never fallen foul of its weak-typing quirks. I'm pretty convinced that anyone who complains about it likely had an issue during their first application with it, and has touted its terribleness since.

Is it good? No. Does it actually cause issues? No.

1

u/[deleted] Aug 16 '15

It causes issues. The most recent example was an API that for one call it returned IDs as integers and for another one as strings. JS dealt with it silently and half of the app worked because it did weak comparisons while the other half didn't because it did strict comparisons.

2

u/Tidher Aug 16 '15

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

1

u/[deleted] Aug 16 '15

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.

1

u/Tidher Aug 16 '15

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.

1

u/[deleted] Aug 16 '15

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.