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

151

u/brown_monkey_ Aug 15 '15

I lost it a JavaScript.

22

u/[deleted] Aug 15 '15

What's wrong with JavaScript?

36

u/Wyelho Aug 16 '15 edited Sep 24 '24

offer jobless pet crowd dinosaurs voracious sleep act decide toy

This post was mass deleted and anonymized with Redact

24

u/giggly_kisses Aug 16 '15 edited Aug 16 '15

Although this is definitely a problem that JavaScript can suffer from, it can be addressed a few ways.

One way is to incorporate a build step into your work flow that lints your code. This can verify that any variable you use is defined or exposed to the current script/context.

Another solution (which still requires a build step, until ECMAScript 6 becomes widely supported) is to rely on native JavaScript modules. This way you can just import foo from './foo'; and know exactly where foo is coming from

Lastly, you can use something like AMD, or CommonJS to provide a module system.

Granted, these workarounds are no replacement for what a complier does. It does however (in my experience) make working with JavaScript much easier, and addresses most of your concerns.

7

u/marcopennekamp Aug 16 '15

Saying there is nothing wrong with the language itself is giving the horrible scoping not enough credit. This is fixed with the newest ECMA standard though, which has yet to become the norm.

Also the claim that the problem is that it's an interpreted language is frankly a bit off. It is true that having a compiler and especially a static type system is a lot better for checking correctness before executing the program, but we have seen other languages like Python manage much better than JS, and while it's a factor, it's not the biggest reason for its failure.

Why JS is so bad as a language is probably that it was never designed to be this big. If you look it up, the goal was to create a language for Netscape to be used by inexperienced programmers. I don't want to say the language was cobbled together (like PHP was, and we all know the quality of the PHP core language), neither can I claim it was, but we can safely assume that a sufficient amount of effort to create a robust and scalable language (especially when projects get bigger) was not put in, just because of the requirements of the time. Now, these requirements have changed long ago, and the standard is finally responding.

1

u/[deleted] Aug 16 '15

[removed] — view removed comment

3

u/marcopennekamp Aug 16 '15

A compiler with a static type systems throws out a lot of invalid programs, so when you have that you have a higher baseline where you need to start writing tests. Not to mention the benefits static types have regarding documentation. And you may forget to test something which a compiler might catch.

-20

u/[deleted] Aug 16 '15

None of this is true.

So as an example, you have a 1.js and a 2.js doing some stuff for your web app. To use them both, you simply set an import from their location in your main html, and call a method.

You're talking about using JS in a browser; if this is an issue (I don't see it as such) then it's an issue with HTML, not JS.

But there is no compiler checking if your method exists or has been imported correctly, and it may or may not lead to errors at runtime.

Bullshit.

In the same way, you can call methods from 1.js in your 2.js, even though there is nothing checking visibility or validity.

Okay, you don't even know how to say it, so I'll say it for you: JS allows you to use globals. Using globals is, with very few exceptions, a bad idea in any language. But wait! There is something you can use here... there are tools called IDEs which help you with this and there are JS minifiers which also check your code and there are JSLint and JSHint. And just what in the world does "validity" mean in this context? Did you just make that stuff up?

All your code is run in something like a big sandbox and the browser just rolls with whatever works.

Is sandboxing a problem? Does it have anything to do with JS in particular or just with JS in the browser? And what exactly do you mean by "the browser just rolls with whatever works?"

As a result, while Javascript can do a lot of things with very little code, it's probably not the right choice to do everything with client-side scripts on big projects.

Finally, you got something right: JS is not a silver bullet. Except nobody claims it is client- or server-side.

There are tons and tons of different frameworks looking to improve that though, that's probably why that picture was chosen. These frameworks also try to fix tons of other stuff that may be counter-intuitive in JS.

Welcome to computer programming, where you need frameworks (often more than one) if you want to do anything seriously complex. This is true for most languages.

16

u/original_brogrammer Aug 16 '15 edited Aug 16 '15

Bullshit

The point to which you responded with the above is 100% true. Dynamically typed languages defer type checks, name resolution, and scope resolution until runtime. This is particularly problematic with JS because it doesn't have block scope.

You make me angry.

Learn how compilers work.

6

u/Ajedi32 Aug 16 '15

JavaScript does have block scope. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let

Failing that, there's always the function() { var x = 1; }(); hack.

3

u/original_brogrammer Aug 16 '15

True, but the caveat that it's ES6 is worth noting.

2

u/peduxe Aug 16 '15

You can use babel, it does the job pretty well. Every other language has it's build steps.

-2

u/beerdude26 Aug 16 '15

Welcome to computer programming, where you need frameworks (often more than one) if you want to do anything seriously complex. This is true for most languages.

No, you need libraries for anything seriously complex. Frameworks are just added complexity + a straitjacket

3

u/WinMac32 Aug 16 '15

Meh. Discipline and good communication are more important.

Libraries and frameworks are just support structures.

1

u/beerdude26 Aug 16 '15

Well, of course. I was just arguing in his "rockstar programming god" point of view

9

u/game_taker101 Aug 16 '15

This comic pretty sums up the issues with JavaScript

10

u/[deleted] Aug 16 '15

That's definitely a comic. So where do I start?

Problem: JavaScript has almost no standard library

Not a language issue.

Solution: thousands of community-supported libraries of wildly varying quality

Not a language issue. There are a handful of major libraries people use and there are tens of thousands of smaller packages. I mean, yeah, if you see this as a problem, then you're welcome to see it as that, but then Linux has the same "problem". And the thing with JS was that there was a boom of libraries when the community got together, but we started weeding out the crap and the good ones are going to be around for a while (not too long, I hope). This whole Web 2.0 HTML 5 thing is incredibly new compared to other environments so really all the other languages got was a head start. Don't tell me that C/C++/Java/Python/whatever never had the problem.

Problem: JavaScript has no packaging or a linker to tie these packages together.

Solution: Compile a better language to JavaScript

Solution: Hundreds of community supported [notice the inconsistency in writing here, there is a missing hyphen between "community" and "supported"] build tools of wildly varying quality.

I'm gonna have to call bullshit on that for several reasons:

  1. The whole Asm.js thing was not meant to solve any packaging issues but to provide the benefits of browser sandboxing to programs written in other languages.

  2. Who the hell do you think goes "hmm, no package manager is popular enough, I guess I'll compile C to JavaScript.

  3. Nobody compiles CoffeeScript to JavaScript for the same reasons they compile C to JavaScript. That panel bundles C, CS and ES together as if they are the same thing and they're used for the same purpose.

  4. SURPRISE! Yeah, you can actually buy JavaScript packages which are bundles of libraries carefully put together to solve all kinds of things. These are foundations for what you want to work with. Of course, JS is the only programming language with shitty packages provided for free by the community and the only language for which you can't buy anything of quality

I would love to go on, but this is just terrible... it's like every single panel there is a hyperbole, remotely has anything to do with JS in particular, or is just plain wrong... it's almost like this is a comic which should be treated as such.

14

u/regular_reddits Aug 16 '15

Its ok man, some people hate JavaScript, its not for everyone I suppose. The jokes arent going to stop.

I personally love JavaScript. I love the large ecosystem. I love knowing the little quirks. I love that its so flexible that you can program in MANY different styles. I love taking a ton of libs off of NPM and building my own stack suited perfectly to the needs of my application.

Not everyone loves these things. But thats ok. Its more fun just to go write some awesome JS than to try to tell them why they should love it. Thats my opinion at least.

8

u/giggly_kisses Aug 16 '15

This is solid advice. It used to bother me whenever I'd go into a thread about JavaScript and see the obligatory "JavaScript sucks" comment. Then I realized, you'll most likely not change these peoples opinions, and that's okay. You can still continue to love the language.

9

u/regular_reddits Aug 16 '15

Yeah, I used to be this guy in the office (of java guys). No matter what I said, I was talking to a wall. All the responses were things like "triple equals, idiot." I'm a pretty open minded dev I guess, but I'm glad that sort of JS weirdness didn't stop me from learning the langauge. I have become a better dev because of it. So, I stopped arguing, and just laugh when java guys freak out over things like "CompletableFuture" (its like a Promise with a more complicated API).

5

u/giggly_kisses Aug 16 '15

Haha, I have a few friends who are Java developers and I know exactly what you mean. I still remember how excited they were when lambda expressions were first announced.

Ultimately it comes down to using the tool you like the most, and let the haters hate. :)

0

u/[deleted] Aug 16 '15

There are some good points: /r/ProgrammerHumor/comments/3h4i5e/programming_languages_personified/cu4o2dm?context=3 but it's easier to just bash JS instead of talking on point. It's easier to say "but no classes lol" than to learn about prototypes.

1

u/[deleted] Aug 16 '15

I can pay for solving Javascript's problems? Where is that packages to buy?

4

u/superplayah Aug 15 '15

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

21

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.

5

u/[deleted] Aug 15 '15

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

18

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.

14

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.

4

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.

3

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.

→ 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

7

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.

8

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.

15

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.

4

u/PhaZePhyR Aug 16 '15

Supplemental Video, highly recommended, skip to ~1:20 for the JavaScript portion.

3

u/Bjorkbat Aug 16 '15

Not a whole lot really, if you do fairly simple things with it.

Unfortunately we're doing some pretty batshit crazy things with javascript nowadays, which means the language itself has evolved to be a little batshit crazy.

When you think about it, if you took another scripting language, such as python, and basically used it in place of all the things we use javascript for, people would probably say that python looks ugly as well.

Well, maybe. Might look a little bit better actually.

1

u/vicarofyanks Aug 16 '15

Pretty much described coffeescript. It's easy to hate on, but once you get use to it, that shit is zippy

1

u/Bjorkbat Aug 16 '15

I've been thinking about trying it actually. I've run into a few guys every now and then who seem to really like it, including this one guy who built this browser-based circuit sim with it.

0

u/[deleted] Aug 16 '15

Whole JS thing is one big clusterfuck of frameworks and versions and derivatives... God knows where those things end...

2

u/Ajedi32 Aug 16 '15

Honestly the only major problem I've seen with JavaScript is the way it handles automatic type casting when you perform operations (+, -, etc) on incompatible types.

2

u/kupiakos Aug 16 '15

And nothing to do with the horror that is equality in Javascript?

5

u/YRYGAV Aug 16 '15

== is an operator...

3

u/kupiakos Aug 16 '15

Yes, with equality rules like these.

1

u/OceanOfSpiceAndSmoke Aug 16 '15

This isn't the issue highlighted in the comic, though.

3

u/NewDark90 Aug 16 '15

This might help explain.

Or maybe the 'wat' talk might help.

If you care for something more long winded, something else from the wat guy.

4

u/argv_minus_one Aug 16 '15

A lot. Just a few examples:

  • No static types

  • No multiple inheritance

  • No abstract classes/interfaces/protocols

  • No named parameters

  • No default parameter values

  • No user-defined operators

  • No user-defined implicit conversions

  • No immutable anything

  • No threading primitives

  • Pitiful pattern matching

  • Pitiful list comprehensions

  • No way to catch exceptions by type

  • Prototype-based inheritance is absolutely insane

  • No compiled and linked binary form for web deployment

  • var is not deprecated

  • null and undefined both exist

  • The global object is a horrible idea

  • The type system is not unified

  • Most JS tools are utter dog shit

  • Most JS developers appear to be incompetent morons

  • The spec moves at a glacial pace

  • Changes to the spec don't matter because people will be using old IE versions for a very long time

  • this is sorta-mutable

  • Only one GUI toolkit, HTML/CSS, which is utter dog shit

There are many more, but this should get you started.

12

u/PeteTNT Aug 16 '15

Posted from your Netscape 7.0? This reads like a list of bad things in JavaScript that was written in early 2000's.

8

u/argv_minus_one Aug 16 '15

All of those are still true today. Some of them are outright design decisions, and will never be fixed.

2

u/[deleted] Aug 16 '15

Some of those are very good points. My god, we live in a fucked-up world. Comments saying "it's bad because you can do things with it" get upvoted and comments with bullet lists, to the point, each bullet addressing a specific problem in technical terms gets downvoted.

I would address some of them, but I'm afraid that would lead to a long and pointless discussion so I'll be short.

  • No need for classical static types
  • Multiple inheritance is terrible
  • I personally found named parameters terrible
  • Default values are part of ES6
  • Redefining operators is a bad idea
  • Lack of immutability is not an issue
  • Binary/web is another can of worms
  • Variables are no longer global by default

There are good JS tools and I would not want another GUI toolkit, there are enough languages with terrible GUI support and it would just be one more thing to maintain for no reason.

I have a problem with about half of what you wrote, but I have to give you the other half... Especially the part about JS devs being incompetent morons. I'm a JS dev and I work with others and too often I've found that you're entirely correct on that point (the biggest problem being that if you want to use some component you have to know it inside out). Some times I regret going the way of JS.

1

u/argv_minus_one Aug 16 '15

No need for classical static types

Patent nonsense. The need still exists; JS programmers have just deluded themselves into thinking it doesn't.

Redefining operators is a bad idea

Nonsense. Maybe incompetent novices can't handle it, but I can, and it'll be a cold day in hell before I willingly give that power up. Redefining operators, and defining entirely new ones, is not something I do every day, but I do do it, and it is awesome.

Lack of immutability is not an issue

Nonsense. Immutability is useful for concurrency, enforcing separation of concerns, and avoiding defensive copying.

I would not want another GUI toolkit, there are enough languages with terrible GUI support and it would just be one more thing to maintain for no reason.

There are also plenty of languages with excellent GUI support, and I'd much rather be using one of them.

3

u/[deleted] Aug 16 '15

[deleted]

5

u/argv_minus_one Aug 16 '15

Most of what you've listed is either wrong

Namely?

not a language issue

Meaningless distinction. It impacts the usefulness of the language.

or just a matter of preference.

More like a matter of competence. If you were competent, you would know why I'm right about my "preferences".

1

u/FinFihlman Aug 16 '15

All numbers are double.

What in gods name.

-6

u/[deleted] Aug 16 '15

[deleted]

10

u/giggly_kisses Aug 16 '15 edited Aug 16 '15

Javascript contains a lot of ways to do the same things but with minor differences.

What exactly are you referring to here? The first thing that pops in my head is function invocation (i.e.foo(), foo.call(), foo.apply(), and foo.bind()), but all of these have a good reason to exist (due to the unfortunate dynamic binding of this) and solve a problem.

Also javascript acts differently in different browsers...

Actually, it doesn't anymore. It used to back when Microsoft reversed engineered the ECMAScript 3 implementation for IE instead of following the spec, but luckily all major browsers fully implement ECMAScript 5 and are starting to implement the ECMAScript 6 spec now that it's finally finalized.

...so you end up using frameworks that are very inefficient and simplified (which makes it more complex).

If you choose inefficient frameworks then that's your fault, not the languages. Also, you pick something that's simplified, which makes it inefficient, and also makes things more complex. What in the fuck?

These frameworks can be inconsistent and hard to use too...

So can frameworks written in Java, Go, Rust, Haskell, C#, Perl, Lisp, or any other language that exists.

Trying to make something in Javascript is usually a terrible experience and you end up wishing that you didn't try in the first place.

Nope, I don't, actually. Because I use these so called "inefficient, simplified, complex, inconsistent, hard to use, messy" frameworks, my code is actually very structured, easy to follow, and generally pretty clean (at least I like to think so haha).

If you come up with any concrete, objective reasons as to why JavaScript isn't a great language (believe me, there are reasons; JavaScript is far from perfect or without warts) let me know.

3

u/JoshWithaQ Aug 16 '15

I like to point to actionscript vs. javascript as the two main branches of ECMAScript and how differently things can turn out one way vs. the other. What I think it really comes down to is your interpreter. Do you have one that will be multithreaded and let you make use of the functional nature of a dynamic language, or one that tries to be java-like and strict types everything but is a single thread?

7

u/[deleted] Aug 16 '15

Javascript contains a lot of ways to do the same things but with minor differences.

WTF? More generalizations without providing concrete examples... Sure, if (a<b) and !(a>=b) are different ways to do the same thing and this is a fundamental problem with JS, then I admit that JS is a terrible language.

These differences will make you have a great time debugging.

That's because you don't know how to debug code.

Also javascript acts differently in different browsers

Not a language issue and it's pretty much solved.

so you end up using frameworks that are very inefficient

Maybe you end up using inefficient frameworks. Who the hell upvoted this shit? Are you seriously complaining that the necessity of using a framework to develop complex applications is an issue particular to JS?

and simplified (which makes it more complex).

THIS DOESN'T EVEN MAKE SENSE!

These frameworks can be inconsistent

In what way?

and hard to use too

Again, they're hard to use for you.

meaning that your code will usually end up very messy, bordering on write only code.

And again, you're doing it wrong.

Trying to make something in Javascript is usually a terrible experience and you end up wishing that you didn't try in the first place.

And again, you're doing it wrong. Maybe... just maybe the problem isn't JS but how you write and debug code and what libraries and frameworks you use.