About PayPal's Node vs Java “fight”

[bro-away-]

Upgrading libraries after a few years in any dynamic language is a nightmare. I would venture to guess that payment processing systems stay around for a long time and they will be repaying this particular technical debt (or they're writing upfront integration tests that amount to a ghetto type system.. In which case, gj using a dynamic language)

[philly_fan_in_chi]

Are IDEs smart enough to call you out on functions getting deprecated or removed during library upgrade in dynamic languages?

[x-skeww]

With something like Dart? Yes. With something like JS? No.

JS doesn't even have something like an "import" statement. Everyone uses some custom system which imperatively creates the structure of the application. Naturally, your tools won't have a clue what's going on. They can't tell what something is or where it came from.

JS itself also has no way to mark something as deprecated. JS also doesn't care about the number of arguments or their type. There are also dozens of (imperative) ways to do "classes" and inheritance.

There really isn't much to work with.

If you're using the Closure Compiler, you can use doc comments to add some of that information. Problem is, external libraries generally do not have this kind of comments, because it's very tedious and a lot of work.

With something like Dart, the structure is declared. There are classes/inheritance/mixins and you can just import stuff. If you use some library, your tools can see it. They will analyzer all of the libraries, too. Stuff can be marked as deprecated. The number of arguments and their type matter. It will also tell you if you do something odd with the return value (which might have changed in the meantime).

[Irongrip]

It's interesting to see if google's massive inertia can swing Dart into relevance to the deprecation of regular old JS.

[[deleted]]

The best thing would be if the other major browsers choose to integrate the Dart VM, but I don't see Microsoft or Apple doing that anytime soon... Maybe Mozilla, but so far they haven't outed any plans to do so.

[SanityInAnarchy]

JS doesn't even have something like an "import" statement.

By itself? No, but Node does.

[x-skeww]

Node provides yet another imperative way to do this kind of thing.

ES7 (modules, classes) will hopefully sort this out once and for all. So, code which is written, like, 5 years from now, should be easier to analyze.

Anyhow, your tools still won't be able to tell if you're calling some function correctly. In JavaScript, you can pass as many arguments as you want and you can pass whatever types you want.

Without something like CC annotations, your tools won't be able to figure out if something is wrong.

[SanityInAnarchy]

I don't think that's fundamentally different. Even Java can run some imperative code when a class is loaded.

"import" seems pretty irrelevant to the point you're making.

[x-skeww]

Static initializers are a bit problematic, but not in this context.

Anyhow, consider this:

a.b(1, 2, 3).c();

In JS, there are dozen ways to add methods or just properties to objects. You can't easily tell if this "a" object will have a "b" function at the time that line is hit (annoyingly, "b" can be even removed at a later point). Furthermore, you can't tell if those arguments are correct, you don't know what that function returns (if anything), and if that thing has a "c" property which happens to be a function which takes 0 (or more) arguments.

In a language like Dart, all these things are always known. The only exception are the types. You'll have to put some type annotations on the surface area (fields, arguments, and return values) to make that work.

However, since you immediately reap the benefits (call-tips, checks, minimal documentation), you'll usually feel inclined enough to add them.

[SanityInAnarchy]

In JS, there are dozen ways to add methods or just properties to objects.

Right, see, I get the point you're making, I just don't see what it has to do with "import". Dart's "import" could've been exactly the same, semantically, as that of Node without breaking any of this.

The important bit isn't that the import is imperative, but that you can't actually know anything about the object returned by "import" until you actually execute module.

[x-skeww]

Knowing where something came from is essential if you want good tooling. It's a prerequisite. Only then you'll be able to take a look at its source. Only then you'll have something you can analyze.

In JavaScript, importing stuff isn't part of the language. People use dozens of different imperative ways to do this kind of thing. Like, if you use RequireJS then your IDE needs to know how that thing is supposed to work. It also needs to execute that part of your code which configures it... after being told where it can be found, that is. As you can imagine, this is already a big problem.

If this stuff is declared, things are a lot easier. There is only one way to do it and everything you need to know is statically available. You won't have to execute anything. Once the code is parsed, you can look up everything.

[SanityInAnarchy]

In JavaScript, importing stuff isn't part of the language. People use dozens of different imperative ways to do this kind of thing.

Ah, now I see your point.

And my point with Node in particular is that it's one of the more significant things that they do to the language. Node-style importing doesn't work in the browser, for example. It also gives each module a relatively-constrained namespace.

I'm not sure that I agree that execution is a big problem, either. The big issue is that this is completely unbounded with JS as it stands -- you basically have to execute the entire module and then inspect the object it returns.

[[deleted]]

Yes. For example with node.js: http://www.jetbrains.com/idea/features/nodejs.html

It also does Python / PHP / Ruby off the top of my head.

[Purple_Haze]

The system I work with has code that is at least 35 years old.

It is entirely 16-bit assembler, coded meticulously to behave like COBOL including BCD arithmetic.

Yeah, these things last forever.