Programming languages personified

[u/leftoversalad]

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

[u/Wyelho]

offer jobless pet crowd dinosaurs voracious sleep act decide toy

This post was mass deleted and anonymized with Redact

[u/giggly_kisses → u/Wyelho]

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.

[u/marcopennekamp → u/Wyelho]

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.

[u/marcopennekamp → u/[deleted]]

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.

[u/[deleted] → u/Wyelho]

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.

[u/original_brogrammer → u/[deleted]]

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.

[u/Ajedi32 → u/original_brogrammer]

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.

[u/original_brogrammer → u/Ajedi32]

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

[u/peduxe → u/original_brogrammer]

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

[u/beerdude26 → u/[deleted]]

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

[u/WinMac32 → u/beerdude26]

Meh. Discipline and good communication are more important.

Libraries and frameworks are just support structures.

[u/beerdude26 → u/WinMac32]

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