3 ms·

Looking forward to someone writing the Spring equivalent this on the JVM

by srvaroa 1y ago

brabel 1y ago
Why? It would be nearly identical, just changing the names of the frameworks.
delusional 1y ago
[flagged]
- TeMPOraL 1y ago
  Or maybe they just don't have oversized egos. The key to using a framework effectively, whether it's Spring in Java or SAP for your business, is to accept that the framework knows better than you - especially when it objectively does not- and when there's a difference between how you or your business think of things, vs. how the framework frames them, it's your thoughts and your business that must change. Otherwise, you're fighting the framework, and that's worse than just not using it.
  - delusional 1y ago
    Do you not think I've heard that line before? The framework knows nothing. It's made by a bunch of children that make CRUD apps wrapping an SQL query behind an HTTP server over and over again. They don't make any applications that do anything commercially or technically interesting, resorting themselves to infinitely copying data structures with increasingly complex annotations, a practice they call "business logic", to trick themselves into feeling like they're doing something. I've been there. I've seen it. It doesn't lead anywhere. The abstractions that spring (and other heavyweight JavaEE-style frameworks) provide is razor thin, and usually implemented in the most trivial possible way. The frameworks, like the applications often built on them, do nothing interesting. EDIT: I realize this is a pretty unkind way to put it. I hope readers can understand the argument along with the indignation I express. I do believe very strongly in these points, but wish I could express them without quite as much anger. I can't tough. Parse out what useful stuff you can glean, and leave the rest along with the knowledge that you don't have to impress me.
    - deleted 1y ago
      [deleted]
    - TeMPOraL 1y ago
      I'm sorry too, I realize I didn't make my point clear. Yes, frameworks are stupid. Their designs are likely suboptimal from the start, and only get worse over time, accumulating hacks to address biggest issue while they double down on going the wrong direction. A competent engineer will easily come up with better ways of doing any individual thing a framework offers, and they have a good shot at designing a framework much better for the needs of their team and their business. Which is why I brought up SAP. It's well-known that adopting SAP usually ends up burning untold millions of dollars on getting expensive consultants to customize it for specific needs of the company, until it either gets written off and abandoned, or results in a "successful" adoption that everyone hates. It's less well-known that the key to adopting SAP effectively and getting the promised value out of it is to change your business process to fit SAP. Yes, whatever processes a business had originally were likely much smarter and better for their specific situation and domain, but if they really want the benefits that come with SAP, abandoning wisdom of your old ways is the price of admission. I say the same is true of software frameworks. Most businesses don't do anything interesting or deep either; you don't integrate with SAP to handle novel challenges, you do it to scale and streamline your business, which actually involves making most work more mindless and boring, so it can be reliably and consistently done by average employees. Software frameworks, too, aren't there to help you with novel technical challenges; they're there to allow businesses to be more efficient at doing the same boring shit every other business is doing. I personally hate those frameworks, but that's because they're not meant for people like me; it doesn't mean they don't work. They're just another form of bureaucracy - they suck all life and fun and individuality from work, but by doing that, they enable it to scale.

Looking forward to someone writing the Spring equivalent this on the JVM

brabel 1y ago

Why? It would be nearly identical, just changing the names of the frameworks.

delusional 1y ago

[flagged]

TeMPOraL 1y ago
Or maybe they just don't have oversized egos. The key to using a framework effectively, whether it's Spring in Java or SAP for your business, is to accept that the framework knows better than you - especially when it objectively does not- and when there's a difference between how you or your business think of things, vs. how the framework frames them, it's your thoughts and your business that must change. Otherwise, you're fighting the framework, and that's worse than just not using it.
- delusional 1y ago
  Do you not think I've heard that line before? The framework knows nothing. It's made by a bunch of children that make CRUD apps wrapping an SQL query behind an HTTP server over and over again. They don't make any applications that do anything commercially or technically interesting, resorting themselves to infinitely copying data structures with increasingly complex annotations, a practice they call "business logic", to trick themselves into feeling like they're doing something. I've been there. I've seen it. It doesn't lead anywhere. The abstractions that spring (and other heavyweight JavaEE-style frameworks) provide is razor thin, and usually implemented in the most trivial possible way. The frameworks, like the applications often built on them, do nothing interesting. EDIT: I realize this is a pretty unkind way to put it. I hope readers can understand the argument along with the indignation I express. I do believe very strongly in these points, but wish I could express them without quite as much anger. I can't tough. Parse out what useful stuff you can glean, and leave the rest along with the knowledge that you don't have to impress me.
  - deleted 1y ago
    [deleted]
  - TeMPOraL 1y ago
    I'm sorry too, I realize I didn't make my point clear. Yes, frameworks are stupid. Their designs are likely suboptimal from the start, and only get worse over time, accumulating hacks to address biggest issue while they double down on going the wrong direction. A competent engineer will easily come up with better ways of doing any individual thing a framework offers, and they have a good shot at designing a framework much better for the needs of their team and their business. Which is why I brought up SAP. It's well-known that adopting SAP usually ends up burning untold millions of dollars on getting expensive consultants to customize it for specific needs of the company, until it either gets written off and abandoned, or results in a "successful" adoption that everyone hates. It's less well-known that the key to adopting SAP effectively and getting the promised value out of it is to change your business process to fit SAP. Yes, whatever processes a business had originally were likely much smarter and better for their specific situation and domain, but if they really want the benefits that come with SAP, abandoning wisdom of your old ways is the price of admission. I say the same is true of software frameworks. Most businesses don't do anything interesting or deep either; you don't integrate with SAP to handle novel challenges, you do it to scale and streamline your business, which actually involves making most work more mindless and boring, so it can be reliably and consistently done by average employees. Software frameworks, too, aren't there to help you with novel technical challenges; they're there to allow businesses to be more efficient at doing the same boring shit every other business is doing. I personally hate those frameworks, but that's because they're not meant for people like me; it doesn't mean they don't work. They're just another form of bureaucracy - they suck all life and fun and individuality from work, but by doing that, they enable it to scale.