5 ms·
You're wrong. It is a battle. Look at how quickly the swords come out when anyone brings up C# and Java or Python and Ruby or Backbone and Angular. Any discussi
by JustSomeNobody 11y ago
You're wrong. It is a battle. Look at how quickly the swords come out when anyone brings up C# and Java or Python and Ruby or Backbone and Angular. Any discussion involving developers and the tech they use quickly devolves into all out verbal conflict. People LOVE to argue about this stuff because it gives them something to do besides actually doing anything productive.
It's all rather sickening, really.
- mahouse 11y agoHow do you dare living your life doing something entertaining rather than doing something productive? To the gas chamber with you!
- JustSomeNobody 11y agoHAHA! I see what you did there! But you missed my point.
- Echoic 11y agoWith your comment, I would think the correct course of action would be not commenting at all in the discussion. But, I guess you don't have anything 'productive' to do.
- JustSomeNobody 11y agoBeing able to have an objective discussion of the appropriate uses of one technology over another is very productive. I, in no way, said anything contrary to that. But meaningful discussions are rare because they devolve so quickly.
- Roboprog 11y agoJava: the expressiveness of an Algol subset with the performance of a Lisp. :-) C#/.NET being a slightly improved Java and all. I love interpreters with automatic memory management. I love assembler (sort of). It's painful when the wrong one gets put in the wrong place, though.
- AshleysBrain 11y agoWell, technologies don't battle (except in the marketplace, which often shows the success of both), but some engineers battle over them. Meanwhile, wiser engineers are calmly choosing their technologies based on their suitability to the task at hand, instead of starting arguments over an all-or-nothing mentality.
- bunderbunder 11y agoThere's the rub, I think. Historically the big managed platforms have offered some real advantages. JIT compilation has been a part of that, since it helps to some of the reflective features that have in turn supported some useful tools for increasing developer productivity such as aspect-oriented programming, object-relational mapping and mocking. These gains may have come at the cost of raw execution times, but most of the core consumers of the technology measure their success in terms of dollars, and are in the privileged position of being able to offset the performance losses by upgrading their servers. For them this is a perfectly sensible decision. Developers are much more expensive than computers, so they were simply being pound wise and penny foolish. In other environments the calculus has been different. Console games have always had constrained resources, a homogeneous target environment, and high performance demands. Correspondingly, AOT's always been how things are done int hat domain. Sometimes it's even changed over time. Bytecode made a lot of sense for mobile development a decade ago, back when there were relatively many competing hardware platforms and people interacted with their phones differently. Nowadays there are fewer more homogeneous platforms and do more task switching, so the cost of AOT compilation has gone down and the potential benefits have gone up. Hence this shift in .NET, which perhaps seems even more sudden since .NET itself was primarily targeted at enterprise development until relatively recently.
- fyolnish 11y agoConsole games use interpreted (not even JITed) Lua quite a lot for the areas where iteration time is of most importance. As the parent said, wiser engineers just choose the best tech for the task.