4 ms·

"JavaScript has the better object model" This might get downvoted and all but ... I'm not sure how someone who has written C# for 8 years would think this. I'

"JavaScript has the better object model" This might get downvoted and all but ... I'm not sure how someone who has written C# for 8 years would think this. I'm not even talking complicated things. Just OO basics like interfaces and abstract classes (with compile time enforcement) are pretty helpful as you evolve a code base.

talles 11y ago
Oversimplifying things (with a little bias): JavaScript object model is Linq/delegates/reflection (the very best parts of C#) without the hassle. IMO: In the lower level architecture it's just more powerful designing functions and data structures to play with each other as you wish (but power is not necessarily a good thing, you can shoot yourself in the foot). You just do it, no need to define all those fancy interfaces, abstract methods, base classes... In the higher level architecture, sure, you really miss those securities that interfaces and such enforces, JavaScript is amazingly breakable. But, fortunately, JavaScript/Node community modularizes so often (and well), that this is practically not an issue. The modules are well done, tested, there's community input, etc.
- recursive 11y ago
  without the hassle? I've never experienced the hassle gradient favoring javascript in that regard. Here's one difference. `objects.Sum(x => x.Width)` is C#. Javascript is... `objects.map(function(x) { return x.Width; }).???`
  - talles 11y ago
    What about returning a dynamic object? You see a method returning "object" (unless it's yours) you immediately starts to feel awkward (should I cast it to something?). Or what if I want to check if a property exists in a dynamic object? Catch the exception? Use the ExpandoObject? Will this affect performance? What about local delegates? And I just won't start with reflection. Have you seem those snippets on SO? Now compare the same with JavaScript. Don't get me wrong, I've been developing in C# for some good years in a row and I really like the language. C# traditional OO way of doing things kinda gets you by the hand when design your application. JavaScript is more on your shoulders. It's a tradeoff, you have to be more careful but you also have more power.
    - recursive 11y ago
      If you're writing idiomatic c#, using dynamic objects is rarely (never) the right thing to do. The reason dynamic exists is mostly for interop with other languages or environments. What about local delegates? Func<int, int> localDelegate = x => x + 1; You don't need to use reflection as often in c# as you would in javascript.
      - talles 11y ago
        Exactly. You can do it, but it doesn't feel right.
        recursive 11y ago
        And furthermore, you have less reason to do it in the first place.
        moron4hire 11y ago
        I find more and more uses for C#'s reflection all the time. I have a project that is built almost 100% on it. Tagging things with attributes, reflecting over them, slicing and dicing all of the available data in all kinds of different ways. I can't imagine trying to do such a thing in JS, which provides so little information about exactly what I'm reflecting over. And it's so clunky. Some things you can typeof, some you have to instanceOf, such that you basically end up doing both all the time. With JS, I know that I have a bag full of things named something. I have to do my own work from there to find out if they are methods or properties or fields. In C#, I can just ask it to give me all of the properties. Oh, but stick to just the public ones. Or skip any that have an attribute named "Exclude" tagged to them. Yeah, I have no idea what people are talking about that JS is better for reflection. That's just bonkers.
Touche 11y ago
C#'s object model is so good they created dynamic so that people don't have to use it...
- moron4hire 11y ago
  Only people who don't use C# regularly think `dynamic` is something C# programmers use regularly.
  - earlz 11y ago
    This is true, but I've seen libraries that lazily use dynamic in their API instead of properly implementing things with generics to accomplish things. Also, the way the various Microsoft frameworks use strings to specify property and type names drives me insane. It's just like.. "Hey, we have a really nice type and generics system... but here lets hop around that and instead use strings that we hope you never need to refactor, as well as magic method names (ie, RegisterRoutes, Application_Start)". This seems to be getting a little better, but it's still way too prevalent. It's almost like the people responsible for writing C# frameworks had a disagreement over strict typing and decided to just contaminate a ton of APIs to spite the type system.
    - moron4hire 11y ago
      Well, to be fair, a lot of those got started back in the pre-generics 1.1 era, and the rest are designed to have a similar interface.
- deleted 11y ago
  [deleted]
- Zergy 11y ago
  Adding a new tool to swiss army knife doesn't indicate the other tools are dysfunctional, it just means that additional functionality was needed.
- SneakerXZ 11y ago
  They created dynamic to improve COM interfaces and bridging to other languages.

talles 11y ago

Oversimplifying things (with a little bias): JavaScript object model is Linq/delegates/reflection (the very best parts of C#) without the hassle. IMO: In the lower level architecture it's just more powerful designing functions and data structures to play with each other as you wish (but power is not necessarily a good thing, you can shoot yourself in the foot). You just do it, no need to define all those fancy interfaces, abstract methods, base classes... In the higher level architecture, sure, you really miss those securities that interfaces and such enforces, JavaScript is amazingly breakable. But, fortunately, JavaScript/Node community modularizes so often (and well), that this is practically not an issue. The modules are well done, tested, there's community input, etc.

recursive 11y ago
without the hassle? I've never experienced the hassle gradient favoring javascript in that regard. Here's one difference. `objects.Sum(x => x.Width)` is C#. Javascript is... `objects.map(function(x) { return x.Width; }).???`
- talles 11y ago
  What about returning a dynamic object? You see a method returning "object" (unless it's yours) you immediately starts to feel awkward (should I cast it to something?). Or what if I want to check if a property exists in a dynamic object? Catch the exception? Use the ExpandoObject? Will this affect performance? What about local delegates? And I just won't start with reflection. Have you seem those snippets on SO? Now compare the same with JavaScript. Don't get me wrong, I've been developing in C# for some good years in a row and I really like the language. C# traditional OO way of doing things kinda gets you by the hand when design your application. JavaScript is more on your shoulders. It's a tradeoff, you have to be more careful but you also have more power.
  - recursive 11y ago
    If you're writing idiomatic c#, using dynamic objects is rarely (never) the right thing to do. The reason dynamic exists is mostly for interop with other languages or environments. What about local delegates? Func<int, int> localDelegate = x => x + 1; You don't need to use reflection as often in c# as you would in javascript.
    - talles 11y ago
      Exactly. You can do it, but it doesn't feel right.
      - recursive 11y ago
        And furthermore, you have less reason to do it in the first place.
        moron4hire 11y ago
        I find more and more uses for C#'s reflection all the time. I have a project that is built almost 100% on it. Tagging things with attributes, reflecting over them, slicing and dicing all of the available data in all kinds of different ways. I can't imagine trying to do such a thing in JS, which provides so little information about exactly what I'm reflecting over. And it's so clunky. Some things you can typeof, some you have to instanceOf, such that you basically end up doing both all the time. With JS, I know that I have a bag full of things named something. I have to do my own work from there to find out if they are methods or properties or fields. In C#, I can just ask it to give me all of the properties. Oh, but stick to just the public ones. Or skip any that have an attribute named "Exclude" tagged to them. Yeah, I have no idea what people are talking about that JS is better for reflection. That's just bonkers.

Touche 11y ago

C#'s object model is so good they created dynamic so that people don't have to use it...

moron4hire 11y ago
Only people who don't use C# regularly think `dynamic` is something C# programmers use regularly.
- earlz 11y ago
  This is true, but I've seen libraries that lazily use dynamic in their API instead of properly implementing things with generics to accomplish things. Also, the way the various Microsoft frameworks use strings to specify property and type names drives me insane. It's just like.. "Hey, we have a really nice type and generics system... but here lets hop around that and instead use strings that we hope you never need to refactor, as well as magic method names (ie, RegisterRoutes, Application_Start)". This seems to be getting a little better, but it's still way too prevalent. It's almost like the people responsible for writing C# frameworks had a disagreement over strict typing and decided to just contaminate a ton of APIs to spite the type system.
  - moron4hire 11y ago
    Well, to be fair, a lot of those got started back in the pre-generics 1.1 era, and the rest are designed to have a similar interface.
deleted 11y ago
[deleted]
Zergy 11y ago
Adding a new tool to swiss army knife doesn't indicate the other tools are dysfunctional, it just means that additional functionality was needed.
SneakerXZ 11y ago
They created dynamic to improve COM interfaces and bridging to other languages.