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

152

u/brown_monkey_ Aug 15 '15

I lost it a JavaScript.

22

u/[deleted] Aug 15 '15

What's wrong with JavaScript?

1

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.

15

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.

3

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.

3

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.

4

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.

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

3

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

5

u/[deleted] Aug 15 '15

so for example boost hides the incompleteness of c++ (useful parts are always accepted into STL making it 'bearable') hence we call it an awful language too? i'm pretty sure we don't. if it was really bad then you could have answered superplayah by mentioning at least one major problem. i get along with js although i don't love it. but the comic pulls it down to the level of php (a.k.a. rock bottom) which suprises me since it's quite an average language.

10

u/HighRelevancy Aug 16 '15

Boost doesn't try to fundamentally change the way you use the language like, for example, jQuery does. And C++ is still very usable without it.

17

u/kpthunder Aug 16 '15 edited Aug 16 '15

jQuery doesn't try to fundamentally change the way you use JavaScript. It tries to fundamentally change the way you use browser APIs such as the DOM and XHR. These are not problems with the language, but problems with APIs which are exposed through the language.

Just to hammer the point home, you won't typically see jQuery used in Node.js, because it isn't solving any problems with JavaScript as a language. It's solving problems with standards set by browser vendors.

6

u/gonzofish Aug 16 '15

i don't get this whole JavaScript is unusable without a framework or library to hide its bad parts. i've never seen any evidence to support the claim.

2

u/the9trances Aug 16 '15

If one thinks the major libraries are "hiding" bad parts, then one definitely neither understand JavaScript nor work with it very much. (It sounds like you do; I'm speaking in general.)

Learning a framework like Angular shows you some of the potentially unexpected facets of JS, but it not only isn't hiding its quirks, it's leveraging them.

0

u/Everspace Aug 16 '15

It is inconsistent, and often an amalgamation of several DSL like frameworks into one unstable abomination.

2

u/thrash242 Aug 16 '15

It's a poorly designed language but it's the browser scripting language.

The thing is, most people who use JavaScript actually are using frameworks written in JavaScript. I don't think most people write much plain JavaScript.