3 ms·

C# is sort of underrated but gets a ridiculously easy ride for actively encouraging bloat and abstraction-ism. What should be "do a thing" is now design a thin

• CharlieDigital 2y ago
  That's a function of the team, not the language.
  • mhh__ 2y ago
    Human behaviour in programming is of course totally independent of language and tools, indeed
    • bigstrat2003 2y ago
      It is, in fact, independent. You can create horrible monstrosities in any language, or create great code in any language.
  • kristopolous 2y ago
    Both. The language can afford that usage through the design decisions. I kind of think the best languages would be those that make creating layers of spaghetti indirection nearly impossible. In practice, it's usually much more specious. Names like "CreatorImplementer", "FactoryAbstrator", "DeviceAccessory" and a half dozen equally amorphous things calling each other as if Thomas Pynchon was writing software. I think I've seen it in all languages I've worked on professionally. Maybe not in Perl.
    • CharlieDigital 2y ago
      I mean, you can do the same in JavaScript and TypeScript as well as any number of other languages.
      • kristopolous 2y ago
        Agreed. There's plenty of obtuse indecipherable JavaScript these days. I keep remembering this code I saw in 2014. It was in ember and used mongodb and some bizarre ember features I've long forgotten to stylize things instead of conventional stylesheets. I had been doing JavaScript since it was called LiveScript in 1995. I knew it very well. This setup was utterly impenetrable. Charging a button color required I think 6 or so different data stores to be manually updated and placed back in alignment because things were validating and cross checking for no good reason other than being a complicated pile of tangled messes. I had to quit the job. I know how incredible this sounds. I can prove it. He does everything like this. Here you go https://github.com/davideschiera/flame-ui/tree/master https://github.com/davideschiera/flame-ui/tree/master ... I'm not quite sure what these 252 files do but I'm pretty sure it could be done in about 25 lines of code in a single function. I had worked with him previously on a C# codebase almost 20 years ago now. I remember him being just as insane but somehow the language successfully encapsulated the insanity so I never had to deal with it. There's this fundamental clash. I think things should work, be maintainable, and have the most minimally complex implementation possible - the Ernest Hemingway approach. Some people prefer James Joyce.
  • sangnoir 2y ago
    Languages bring along a culture. Sone teams buck the culture of the broader language ecosystem, most do not. IMO, the C# culture is closer to enterprise Java than it is to Typescript, for good or for ill.
    • CharlieDigital 2y ago
      > C# culture is closer to enterprise Java than it is to Typescript I mean, this really depends on what you're looking at. Here's a sample from the MongoDB client: https://github.com/mongodb/node-mongodb-native/blob/main/src/operations/command.ts https://github.com/mongodb/node-mongodb-native/blob/main/src... Here's a sample from Storybook: https://github.com/storybookjs/storybook/blob/next/code/core/src/channels/websocket/index.ts https://github.com/storybookjs/storybook/blob/next/code/core... Here's a sample from Prisma: https://github.com/prisma/prisma/blob/main/packages/client/src/runtime/RequestHandler.ts https://github.com/prisma/prisma/blob/main/packages/client/s... Here's a sample from Cal.com: https://github.com/calcom/cal.com/blob/main/packages/core/EventManager.ts#L104 https://github.com/calcom/cal.com/blob/main/packages/core/Ev... These are all fairly mainstream repos so it's not a one off to see "enterprise" style coding in TypeScript. It's rather the specific use case that determines the style of the code that's written. In the examples above, there's no need for the teams to choose JavaScript classes and inheritance to model the logic, yet it likely better fits the programming model of those modules. Look at Nest.js as well: https://github.com/nestjs/nest/blob/master/packages/core/router/routes-resolver.ts https://github.com/nestjs/nest/blob/master/packages/core/rou... The whole codebase of Nest.js looks an awful lot like Spring or ASP.NET (controller syntax) probably because there's a lot of crossover in terms of what APIs need at scale and how to logically organize that logic. It just so happens that most use cases for C# and Java favor applications at a larger scale. Another key difference being object scope and lifecycles -- something that rarely comes into play in the generally single-threaded Node runtime. This being one of the key reasons why dependency injection is a thing in C# and Java land.
    • mhh__ 2y ago
      More than culture, language is a statement of values. There's reflexivity and path dependency but the culture is downstream of the values for the most part.
• jayd16 2y ago
  Its very much a culture thing and not a language thing. C# is very versatile. Go look at Unity code and its a fairly different style. It has its own quirks and there's no such as "the right way" but it doesn't feel like Spring. Also, extension methods are great. LINQ is amazing and that's partly from extension methods.
  • mhh__ 2y ago
    Right, but extension methods are a hack to cover up problems with OOP
    • jayd16 2y ago
      It's just sugar to turn functional style into .Syntax(), but because of that the tooling is very nice and things like LINQ can be a fluent API instead of LISP. You can call it a hack but IMO you get the best of both worlds.
      • mhh__ 2y ago
        Don't get me started on fluent apis lol
    • CharlieDigital 2y ago
      "cover up" feels like the wrong sentiment here. It's adding optionality and in fact, doesn't in any way break OOP at all; it is syntactic sugar.