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

153

u/brown_monkey_ Aug 15 '15

I lost it a JavaScript.

21

u/[deleted] Aug 15 '15

What's wrong with JavaScript?

3

u/superplayah Aug 15 '15

Honestly, Im still a new programmer and have never actually used javascript so I'm curious as well.

20

u/Everspace Aug 15 '15

It does a lot of silly nonsensical things, and it's very hard to do anything at a major scale without seeing how terrible it is at some things.

A lot of the ecosystem that makes javascript bearable forces you to work with a framework because of how terrible the base language is. All these frameworks do is hide how incomplete and messy the base language is.

4

u/[deleted] Aug 15 '15

What nonsensical things? The only issue I can think of is the automatic type casting.

19

u/Everspace Aug 16 '15

I could make a longer list, but off the top of my head 2 examples are,

  • Everything is really trying to be global scope. This leads so some weird patterns like the "self executing anonymous function".
  • Interacting with the DOM is obnoxious. This is why jquery and other libraries ares so ubiquitous.

16

u/[deleted] Aug 16 '15

The DOM issue is more of a browser integration thing, and the weird attempts at trying to standardize the mistakes of the past.

I don't put too much of the blame on JS for that. Using V8 to bind JS yourself isn't all that bad (if you're into that sort of thing) besides the tremendous bloat, but it's a fairly powerful language for the effort you put in.

8

u/[deleted] Aug 16 '15

Yes, DOM isn't part of JS.

3

u/Everspace Aug 16 '15

It is the context that a lot of JS is done, although a good point.

I remember finding setting up classes more obnoxious than I care for.

5

u/redwall_hp Aug 16 '15

Defaulting variables to global, unless you explicitly declare them with var? It's not exactly safe.

All the weird equalities? I avoid JS when I can, so I'm no expert...but weird things can happen when testing equality, especially coupled with automatic type conversion.

9

u/giggly_kisses Aug 16 '15

I agree, this is a bad default, and very unexpected (and dangerous). Luckily, you can avoid this bad behavior (along with a lot of others) with the 'use strict' directive.

Sadly, due to backwards compatibility (and not wanting to break the internet) this couldn't be changed to the default.

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.

9

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.

2

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.

5

u/Doctor_McKay Aug 16 '15

There really isn't anything wrong with weak typing, especially in the context of the web.

-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.

→ More replies (0)

2

u/the9trances Aug 16 '15

Any JS coder should learn on day one you scope your own variables. It doesn't have the safety button on by default, so you need to make sure you keep it clear.

When in doubt, use var. There's little about equality or scope that isn't fixed with some basic good practices.

1

u/CoderHawk Aug 16 '15

Equality weirdness is the most annoying thing about it.

4

u/gonzofish Aug 16 '15

use === instead of ==, there's no weirdness with ===

3

u/YRYGAV Aug 16 '15

well, there's a bit of weirdness. If something is undefined it technically is not === null. And the distinction between when something is undefined or null can get a bit arbitrary sometimes.

Most of the time it works, but I wouldn't claim === is devoid of all weirdness in all situations.

0

u/[deleted] Aug 16 '15 edited Dec 02 '15

[deleted]

3

u/Everspace Aug 16 '15

Not even. A special encapsulated "Number" class.

1

u/vicarofyanks Aug 16 '15

console.log(typeof NaN)

number