4 ms·

> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. > ES6 isn't statically typed. It might be better for you , it is not for me. So you

> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. > ES6 isn't statically typed. It might be better for you , it is not for me. So you are saying that because it isn't statically typed it's inherently worse in terms of expressiveness? There's a valid argument that static typing has big advantages (navigation, refactoring) but it worries me when people write off dynamic code entirely.

seanmcdirmid 11y ago
Also performance, don't forget how effective unboxing is in many applications.
azth 11y ago
OP (aikah) didn't mention anything regarding expresiveness. The post that replied to that one brought up the expresiveness issue. That being said, yes, it has been shown that, for large projects, statically typed languages are strictly superior than dynamically typed ones.
- colin_jack 11y ago
  OK but he quoted the expressiveness in his reply which I thought meant that was the point he was addressing.
  - bibabo 11y ago
    More like the point you wanted him to address so you could add a snarky reply.
    - colin_jack 11y ago
      Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness. [1] ES6 isn't statically typed. It might be better for you , it is not for me.
tracker1 11y ago
It's more expressive in that it's more easily testable... To write testable code in C# you generally need to introduce complex classes, interfaces and IoC/DI into a project. JS allows you to work around this with generally less complexity of code. For the most part node/es6-style modules can be far more simple and easy to reason about than C# projects tend to be. Don't get me wrong here, I like a LOT about C# but expressiveness compared to JS doesn't even come close, when you include the pending ES7 stuff via Babel.
- sharpercoder 11y ago
  Besides reflection, do you have examples of this?
  - moron4hire 11y ago
    Having done a lot of reflection in both JS and C# (well, .NET really, it's a library and runtime feature, not a language feature), I think I can confidently say that .NET is light years ahead of JS when it comes to reflection. I don't think I've seen a system better than .NET's. Because of the way it is built, you can still write type safe code. That's impossible to do in JS. I think people forget that, in JS, the types still exist. Just because it's not statically typed doesn't mean you don't have to think about types and what types are appropriate for given scenarios. With JS, it's impossible to tell just from inspecting a reference to a function what it expects from you and what you can expect to give back. You have the length property to tell you the number of arguments and that's it. Of course, that's assuming it's not using a variadric arguments pattern, in which case the length value only tells you the minimum number of parameters expected, but not that more are possible. Even if you can make reasonable assumption about the number of parameters, you won't be able to tell at all what types the function expects for those parameters. Want to list all the functions in a class that take two numbers and return a different number? Can't do it. But still, if you could make reasonable assumptions about the type of things that go in and out of the function, you won't know how to even call the function. Does the function expect to be called as a method of a class? Does it expect to be called as a static function? The best you can hope for is to toString the function and check if the source includes the word "this". Here's hoping it's one written in JS itself and not one that is implemented internally in the browser. Now before anyone says "why would you ever need anything like that?", it's an absolute necessity for building any sort of user-driven or data-driven reporting system. You need to be able to tell when your data set matches the functions you want to apply to them, at run-time, because the data isn't available at design-time. It's the classic reflection use case. As far as I'm concerned, safety-guaranteed reflection is impossible in JS, unless you throw away JS functions almost completely and create your own Functor class with all the extra type information that you would need.

seanmcdirmid 11y ago

Also performance, don't forget how effective unboxing is in many applications.

azth 11y ago

OP (aikah) didn't mention anything regarding expresiveness. The post that replied to that one brought up the expresiveness issue. That being said, yes, it has been shown that, for large projects, statically typed languages are strictly superior than dynamically typed ones.

colin_jack 11y ago
OK but he quoted the expressiveness in his reply which I thought meant that was the point he was addressing.
- bibabo 11y ago
  More like the point you wanted him to address so you could add a snarky reply.
  - colin_jack 11y ago
    Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness. [1] ES6 isn't statically typed. It might be better for you , it is not for me.

tracker1 11y ago

It's more expressive in that it's more easily testable... To write testable code in C# you generally need to introduce complex classes, interfaces and IoC/DI into a project. JS allows you to work around this with generally less complexity of code. For the most part node/es6-style modules can be far more simple and easy to reason about than C# projects tend to be. Don't get me wrong here, I like a LOT about C# but expressiveness compared to JS doesn't even come close, when you include the pending ES7 stuff via Babel.

sharpercoder 11y ago
Besides reflection, do you have examples of this?
- moron4hire 11y ago
  Having done a lot of reflection in both JS and C# (well, .NET really, it's a library and runtime feature, not a language feature), I think I can confidently say that .NET is light years ahead of JS when it comes to reflection. I don't think I've seen a system better than .NET's. Because of the way it is built, you can still write type safe code. That's impossible to do in JS. I think people forget that, in JS, the types still exist. Just because it's not statically typed doesn't mean you don't have to think about types and what types are appropriate for given scenarios. With JS, it's impossible to tell just from inspecting a reference to a function what it expects from you and what you can expect to give back. You have the length property to tell you the number of arguments and that's it. Of course, that's assuming it's not using a variadric arguments pattern, in which case the length value only tells you the minimum number of parameters expected, but not that more are possible. Even if you can make reasonable assumption about the number of parameters, you won't be able to tell at all what types the function expects for those parameters. Want to list all the functions in a class that take two numbers and return a different number? Can't do it. But still, if you could make reasonable assumptions about the type of things that go in and out of the function, you won't know how to even call the function. Does the function expect to be called as a method of a class? Does it expect to be called as a static function? The best you can hope for is to toString the function and check if the source includes the word "this". Here's hoping it's one written in JS itself and not one that is implemented internally in the browser. Now before anyone says "why would you ever need anything like that?", it's an absolute necessity for building any sort of user-driven or data-driven reporting system. You need to be able to tell when your data set matches the functions you want to apply to them, at run-time, because the data isn't available at design-time. It's the classic reflection use case. As far as I'm concerned, safety-guaranteed reflection is impossible in JS, unless you throw away JS functions almost completely and create your own Functor class with all the extra type information that you would need.