[HN Gopher] Why I Hate Frameworks (2005)
___________________________________________________________________
Why I Hate Frameworks (2005)
Author : jameslk
Score : 172 points
Date : 2023-07-07 20:11 UTC (2 hours ago)
(HTM) web link (factoryfactoryfactory.net)
(TXT) w3m dump (factoryfactoryfactory.net)
| xyst wrote:
| Sounds like a 3d printer
| jokoon wrote:
| I remember following up the Angular tutorial. I was about 15min
| into the tutorial, and I was already editing 8 different files. I
| never got lost so quickly. I lost a job because I could not use
| angular, but never felt bad about it.
|
| I remember somebody commenting here on HN about a developer
| conference, where the speakers were bragging about their software
| being complex.
|
| This is an awful trend with software, and is related to John
| Carmack's "layers of crap", Wirth's Law and developers who want
| to keep their job by writing code only themselves understand.
|
| The quality of any engineering work is highly correlated to how
| simple and approachable it is. Unfortunately sofware developers
| have the unfortunate tendency to have a taste for complexity,
| because they feel complexity is a form of art since they view
| computers are complex things.
|
| It doesn't have to be like that.
| andix wrote:
| That's why angular is hated so much. It makes easy things more
| complicate. In my opinion it's a bad framework. Use a good
| framework instead! Just because some (or a lot of) frameworks
| are bad, it doesn't meant that the concept of a framework is
| bad.
| idlewords wrote:
| This should have ended with the guy giving up in frustration and
| using a 60 year old loaded gun to drive in his nails.
| function_seven wrote:
| Funny coincidence. Just yesterday The Far Side featured this
| comic: https://www.thefarside.com/2023/07/06/1
| mdorazio wrote:
| I want a version of this satire where they only sell hammer
| subscriptions, but to get the hammer the guy actually wants he
| needs to buy an Extended Hand Tools subscription that auto renews
| and costs as much in three months as buying the original hammer
| would have.
| Etheryte wrote:
| Don't forget getting billed for a full year while still losing
| access if you cancel your subscription.
| nerdponx wrote:
| It's not a hammer subscription, it's hammering-as-a-service.
| You ship them the nails and wood, they ship you back the nails
| hammered into the wood. You don't have to worry about the
| complexity of storing or using a hammer anymore, let alone the
| difficulty of selecting the right hammer, it all just works.
| They charge extra to sell you the nails and wood, to avoid the
| complexity of packing and shipping your nails and wood.
| samuellevy wrote:
| They have strict specifications about the types of nails and
| wood that they can hammer, but they're not documented
| anywhere. If you send them the wrong type of nails or wood,
| they'll put them both into an industrial shredder and send
| you back the dust, because technically the nails have now
| been integrated with the wood.
|
| Their free plan will let you hammer in 5 nails per month into
| a single piece of wood, but you can't use a different piece
| of wood each month. For $30/month you get 50 nails, and up to
| 5 pieces of wood, or for $60/month you can get 120 nails and
| unlimited pieces of wood, and two-factor (they'll call you
| before they hammer in the nails, and ask where you actually
| want the nails hammered). If you want to have unlimited
| nails, you have to contact them for enterprise pricing.
|
| They will also sell the measurements of your wood and the
| nail positions to other carpenters.
| selimnairb wrote:
| Maybe you don't want to be a carpenter after all...
| nerdponx wrote:
| Honestly, you probably don't!
|
| If you need to build stuff out of wood, you have three
| options: buy something pre-made, hire someone to build it
| for you, or hire a team of carpenters to build it in house.
| Arguably, the third option should be your last choice.
|
| Stretching the metaphor a bit, sometimes it makes sense to
| hire a team of carpenters, but contract out or buy pre-
| built a few particular parts that are particularly
| difficult or complicated.
|
| That's essentially what these SaaS products are supposed to
| offer. The problem is not that they exist, the problem is
| that it can be difficult to know when you need or don't
| need any particular product.
| travisgriggs wrote:
| This was written in 2005. I feel this ship has so sailed at this
| point. I would love to go back to the world where I had the
| bandwidth to waste on framework hating.
|
| Now days, Framework's mutant offspring ad-order-of-magnitue-
| larger, Platforms, is what I cope with. Why I Hate Platforms
| would be the same general rant writ large.
| jonas21 wrote:
| I don't get it. I assume the author is trying to make it sound
| absurd that you would need all these layers of factories to build
| a simple spice rack and, by analogy, that frameworks are also
| absurd.
|
| But if you were building spice racks at scale, of course you
| would build them in a factory! And you'd use machinery made in
| other factories. And those factories would have tools and
| machines made in yet other factories.
|
| That's why you can go to Amazon or Wayfair or the Container Store
| and find 100 different spice racks for less than $30, and why
| nobody builds a spice rack by hand, except for fun.
| JohnFen wrote:
| Like factories, frameworks are methods of reducing production
| costs, but come at the expense of certain aspects of product
| quality.
|
| Sometimes, that quality/cost tradeoff is desirable, sometimes
| it's not. The trouble comes if using a factory or framework is
| the only, or even main, tool in your toolbox, and it ends up
| getting used for everything.
| andix wrote:
| > the main tool in your toolbox, and it ends up getting used
| for everything.
|
| I you get the work done efficiently this may be a good
| strategy. It may be a worse strategy, to spend a lot of time
| to find the "perfect" framework and a lot of time to master
| it, just because it's a better fit for the problem. "Good
| enough" very often does the trick.
| JohnFen wrote:
| > "Good enough" very often does the trick.
|
| Absolutely. From an engineering standpoint, "good enough"
| is often the right thing. An essential thing engineers do,
| after all, is to select appropriate compromises.
| reillyse wrote:
| Yea it's nonsense. Factories are fantastic. If you want to do
| something as a hobby, sure don't use the most advanced tools
| and do it by hand, but for everyone else especially
| professionals who are charging other people for their time and
| effort using the best possible tooling is essential.
|
| In fact, if somebody didn't use a common library or framework
| and instead "rolled their own" it's downright irresponsible,
| obnoxiously egotistical and just creates a huge maintenance
| burden for whoever has to maintain it when you move on.
|
| Take for example a crud app in ruby. If instead of using rails
| or another framework you instead "rolled your own" for one it
| would take you way longer for two it would never be as battle
| tested as the framework and lastly you are guaranteeing that
| whoever has to maintain it will need to learn the
| idiosyncrasies of your amazing implementation with zero outside
| help. It's a recipe for disaster.
| kristopolous wrote:
| That's a mistake. Imagine you're instead a carpenter.
|
| You're being called up because the problem is specialized.
|
| Now as a carpenter, you go to the container store and then go
| back to your shop to dismantle prebuilt products and glue a
| bunch of different pieces from different containers together
| and present the Frankenstein cabinet as the product back to the
| customer. Also, you're on the hook for maintaining it.
|
| Is it faster then just doing it yourself? Higher quality?
| Cheaper? Maybe...
|
| Competency is the key skill here - someone could claim they're
| competent in both the NIH and framework way and they choose
| frameworks because of their vast power of assessments but
| statistically speaking, they're probably just choosing the
| frameworks because they lack the competency to DIY and are
| Dunning Krugering themselves.
|
| A lot of this depends on the types of jobs you decide to take
| on. The boring ones are pretty easy to do with frameworks but
| the interesting ones are wildly unclear whether you're saving
| or wasting time by choosing one path over another especially if
| you're interested in the product's reliability and longevity.
|
| The amalgamation of frameworks approach makes long term
| upgrading somewhere between very expensive and impossible.
| Dependencies, schemas, templating, test syntax can all change
| in totally incompatible ways as your version gets abandoned and
| you get locked in to whatever was hot 10 years ago. So much for
| security patches.
| Ultimatt wrote:
| The point that flew over your head is every one wants one spice
| rack. There is no scale, no one wants a 1km long spice rack or
| 10,000 small ones either. That you can just buy a ready made
| one is even more to the authors point. Most software shouldnt
| exist! Why even build a spice rack, indeed!
| capableweb wrote:
| By that very analogy, using frameworks for building a service
| is absurd.
|
| A framework you would use in order to pump out a ton of
| services quickly, just like a factory in this case. They'd be
| similar, with similar functionality and such, but you can
| produce them quickly and upgrade things across all of them
| fast. They wouldn't by optimal, but time from development to
| launch would be quicker.
|
| But most startups and companies start with one web service,
| where at that point you don't really need a framework. What you
| need instead is careful deliberation and implementation,
| together with development speed and also enough proper
| architecture to continue to facilitate development speed in the
| future, but not too much as to over-engineer things. A balance
| if you will.
|
| But unless your business/startup is about pumping out 100s of
| websites, a framework will hardly help you achieve your goal
| faster.
| austin-cheney wrote:
| Is the author trying to build themselves a spice rack or many
| spice racks for all the world? In one of those cases, yes, you
| would want a factory, but that isn't this case.
|
| The same is true for code. Are you writing one application or
| are you writing the same application for many different
| customers? In one of those cases you would benefit from some
| sort of template but in the other case it all the extra stuff
| to scale just gets in the way.
|
| If you want your one self-serving spice rack to scale then just
| plan ahead and make it bigger than your current needs so that
| you can add more spice later. Again, that also applies to code.
| If you want your one application to scale then just plan ahead.
| Jumping immediately into a framework only indicates you lack
| the confidence to make appropriate planning decisions.
| inopinatus wrote:
| Joe Armstrong: "but I wanted a banana"
| doitLP wrote:
| With only very slight modification, this essay could be rewritten
| with "dependency" instead of "factory"
| Dudester230602 wrote:
| So, no game engines then.
| justincredible wrote:
| [dead]
| yetanotherloser wrote:
| I do take the point but I feel like the era of the factory
| factory was a while ago and I'm almost nostalgic for it compared
| to the dubious soup that we seem to have to deal with now.
| killthebuddha wrote:
| dubioussoup.ai
|
| Edit: I donno why, but the concept of _dubious soup_ has me
| CRACKING UP right now.
| tempest_ wrote:
| We take your soup and pipe it into chat-gpt 4 and what you
| get is what you get.
|
| The ever growing field of prompt engineering continues to
| grow.
| yetanotherloser wrote:
| I couldn't think of a better phrase, ok? glad if it amused!
| kabdib wrote:
| I once waded into a piece of software that had factories five or
| six levels deep. One memorable code path involved the clipboard.
|
| That was the company where I first heard the term "Train Wreck".
|
| ("Documentation? You're lucky it builds!")
| epiccoleman wrote:
| The worst part of this kind of thing is that young carpenters
| honestly, really, truly, just need to learn to use a hammer. They
| can't even conceive of the problems that are being solved by the
| hammer factory, let alone the factory factory. But in the world
| of the factory factory factory, the apprentice carpenter (who
| really just wanted to drive a few nails) is now faced with trying
| to understand the gargantuan complexity of the factory factory
| factory.
|
| When one of the sub factories breaks down, or when a saw came out
| where a hammer should have, the carpenter might find themselves
| awfully tempted to take a ball peen hammer to someone's face. But
| sadly, they don't know where to get one or how to use it.
| 88913527 wrote:
| Everyone needs to learn to do calculus by hand before advancing
| to the calculator. People picking up frameworks without
| fundamental understanding is a shockingly common fallacy.
| inopinatus wrote:
| Don't do calculus in glass houses.
| hyperthesis wrote:
| Wait, you're saying that _calculators_ now do symbolic
| differentiation and integration (like sympy and mathematica)?
| Kids today...
| TheJoeMan wrote:
| My recent TI-nspire calculator had a track pad mouse built
| in...
| skulk wrote:
| The TI-Nspire CAS (computer algebra system) can do very
| complicated symbolic antidifferentiation, like ones that
| you'd do by hand with repeated integration-by-parts. It can
| even solve many kinds of simple ODEs!
| [deleted]
| lacksconfidence wrote:
| My handheld calculator, a Ti-89, did basic symbolic
| differentiation (and maybe integration, it's been awhile)
| in the late 90's.
| LoganDark wrote:
| Oh hey, I have a TI-89 Titanium. It can emulate the
| gameboy advance playing Pokemon Red at 30FPS. :)
| GuB-42 wrote:
| That's the reason why CS classes and degrees exist. Or at
| least it should be.
|
| No company will pay you for several years just to learn
| complexity theory, write sorting algorithms, study
| schedulers, rewrite UNIX tools, understand hardware
| architectures, etc... They want you to be productive right
| away, and the shortest path is just to follow recipes with
| the latest framework.
|
| That's the point of education, universities teach you what
| you won't learn on the job. So that when you finally get to
| work, you will have a better understanding of what you are
| doing.
| saurik wrote:
| I mean, you certainly should learn _arithmetic_ before using
| a calculator, right? But a calculator is more of a library
| than a framework, anyway, so your attempt at proof-by-analogy
| isn 't at all resonating with me.
|
| (edit: I think I misread the comment I replied to and am now
| in the process of maybe figuring that out downthread.)
| chongli wrote:
| Calculators do a lot more than arithmetic these days.
| Without knowledge of calculus, most people think of a
| calculator as a magic "black box" that outputs square roots
| and cosines.
| saurik wrote:
| FWIW, I am willing to believe that I have misunderstood
| the comment I responded to, and that they are not making
| a sarcastic proof that people should _not_ have to learn
| calculus to merely use a tool like a calculator, but that
| they in fact _should_ do so, and I 'd actually be willing
| to get on board with that? (But, as anti-framework as I
| am, I think that might be going a bit far.)
|
| I frankly still can't tell as that's use of "fallacy" to
| describe "people picking up frameworks without
| fundamental understanding" is apparently extremely
| confusing to me as it isn't in the form of a fallacy--
| like, is the fallacy that this happens? that this is a
| problem? is it the thought which leads people to do that?
| etc.--so I automatically added stuff to the sentence to
| make it work and maybe I did it wrong.
| [deleted]
| spicybright wrote:
| Extremely common, and was one I fell into as a junior dev
| myself (early 2010's).
|
| Some reasons (based on my experience):
|
| - University classes were either very low level, or using
| some new framework to increase your employment prospects
|
| - All the experienced devs would hop jobs every few years,
| leaving less opportunity for mentorship.
|
| - Lack of convenient resources for gaining base knowledge.
| Googling "how to make a todo list webpage tutorial" will
| always have articles using the latest web frameworks, for
| instance.
|
| (Not really anyone's fault, a good engineer has know where to
| go for the right information. But as a junior without that
| skill it's easy not to get good information.)
|
| My personal strat when learning a framework is sometimes
| building what I want without it, running into the common
| problem patterns, and then looking at how a framework solves
| it.
|
| It's very time consuming so I only do that for personal
| projects, but I think I've learned the most base knowledge
| for really groking a framework doing that.
| JohnFen wrote:
| > a good engineer has know where to go for the right
| information
|
| That colleges aren't teaching this as a first-rate topic is
| a real failure. This is, in my opinion, the most important
| skill any engineer should have.
| ljm wrote:
| I would add that intuition and knowing how to question it
| is also vastly important.
|
| My main driver is Ruby - I have a good feeling about code
| that can be refactored to use Enumerable more
| effectively; but I also know that Enumerable offers so
| much that I might be expecting too much of it. So 80% of
| the time I point to a method that solves the exact
| problem and the rest of the time I know how to write it
| differently.
|
| "Why do you know about filter_map?"
|
| "Because people were confused about reduce and
| each_with_object and map and maybe you just want to loop
| through non-nil objects in one pass"
| JohnFen wrote:
| > I would add that intuition and knowing how to question
| it is also vastly important.
|
| I agree. Especially knowing how to question and how to
| break problems down. I'm not sure intuition is a thing
| that can be taught, but it's a thing that emerges as a
| consequence of being curious and learning how to question
| and find answers to those questions.
|
| That aspect is also why I think that being generally
| curious and having a broad base of knowledge makes you a
| better engineer. It's amazing how often apparently
| unrelated knowledge can give you an insight into solving
| programming problems. People who are laser-focused on
| "computer stuff" specifically often miss important
| insights.
| xg15 wrote:
| > _the carpenter might find themselves awfully tempted to take
| a ball peen hammer to someone 's face. But sadly, they don't
| know where to get one or how to use it._
|
| ...and that's how the the factory factory factory also provides
| immediate safety and security benefits!
|
| /s
| erulabs wrote:
| Simplicity is easy to mandate: "just use simple tools!". It's not
| always obvious when the finished product looks wonky and slanted
| and has to be retrofitted several times that the _complexity_ was
| always there, in the world. The complexity in our tools is
| hopefully there to help with some complexity in the world.
|
| In my experience, it's always the junior who shouts "This could
| all be so much simpler!".
| jonahx wrote:
| > In my experience, it's always the junior who shouts "This
| could all be so much simpler!"
|
| Don't have time now to find links of Jonathan Blow, George
| Hotz, Casey Muratori, and many other decidedly non-junior
| programmers complaining about the absurd, _unnecessary_
| complexity of modern software development.
|
| The people who complain are the people who know how much
| simpler it can be.
|
| Now, there is a _separate_ phenomenon of green devs who think
| they can rebuild X only because they can 't fathom the bulk
| beneath the iceberg's tip. That is real too. But it takes
| nothing away from the very real fact that the vast majority of
| software written today is much, much more complex than it needs
| to be.
| mattgreenrocks wrote:
| Hard agree.
|
| Try to discuss this with people and it's endless hand waving
| about resume driven development or not enough time or devs
| aren't good enough or nobody really writes good software.
|
| It's absolutely toxic.
| pharmakom wrote:
| when you land on the right tools and abstractions, your problem
| domain will start to feel simpler than before.
| bluefirebrand wrote:
| > In my experience, it's always the junior who shouts "This
| could all be so much simpler!".
|
| Yeah, this is true. But I often wonder how much of this is
| because the seniors have given up on simplicity and since they
| have internalized the complexity it doesn't bother them
| anymore.
| nerdponx wrote:
| > Yeah, this is true. But I often wonder how much of this is
| because the seniors have given up on simplicity and since
| they have internalized the complexity it doesn't bother them
| anymore.
|
| I've seen this first-hand. It makes for a bad experience and
| a demoralized, ineffective team.
| bluGill wrote:
| As a senior my goal is to write that really complex stuff and
| then hide it behind a simple interface that always works the
| way you expect so you never have to look under the hood.
| jackblemming wrote:
| You don't believe it because you've never seen it. Some of us
| have. And it never comes for free.
| kyralis wrote:
| > In my experience, it's always the junior who shouts "This
| could all be so much simpler!".
|
| Or the _actual_ senior engineer, as opposed to the mid-level
| engineer with a senior title. It 's the ones in the middle that
| really love adding in the complexity - you have to relearn how
| to prune it back out.
| jcpst wrote:
| Yes. My "worst" code was when I was mid-level. Too clever,
| showing off what I learned.
|
| Music was my first career, and there was something that
| really stuck with me while studying music theory- learn as
| much as you can, and then don't think about any of it when
| you go to compose.
| JohnFen wrote:
| > My "worst" code was when I was mid-level. Too clever,
| showing off what I learned.
|
| This was my experience as well, for pretty much the same
| reason. At some point, I gained enough experience that I no
| longer cared about impressing anyone or showing off, and my
| code became substantially better.
| wefteri wrote:
| Steve Jobs beat us to it: There's simplicity before you
| understand complexity, and there's the simplicity after you
| understand complexity.
| rapind wrote:
| > In my experience, it's always the junior who shouts "This
| could all be so much simpler!".
|
| 20+ years later and I'm still saying this. Quite possible I'm
| still the junior in terms of skill though.
| g4zj wrote:
| > Quite possible I'm still the junior in terms of skill
| though.
|
| This is a very "senior" mindset.
| vbezhenar wrote:
| IMO senior understands that simplicity is possible, but
| economically not viable for most projects. So complexity is
| inevitable evil. And true mastery is delivering products,
| keeping complexity at bay. Not spending time to pursue
| ideals and at the same time keeping project from felling
| down to unmaintainable mess.
| calvinmorrison wrote:
| Thats why I want a framework. Let me pick components. If
| at some point I need oauth its one composer install away
| with laravel
| LaGrange wrote:
| I do to, but now it's in a discord channel dedicated to
| venting instead of work.
| mindcrime wrote:
| _In my experience, it 's always the junior who shouts "This
| could all be so much simpler!"._
|
| Vis-a-vis the conversation that has ensued from this statement,
| I'll offer the suggestion that the _real_ seniors are the ones
| who don 't make blanket statements one way or the other, and
| appreciate the distinction between incidental complexity and
| intrinsic complexity. _Some_ times, the problem itself is
| simply complex and requires a complex solution. One should not
| rush to eschew complexity in those cases. Other times, the
| complexity is incidental and is brought in by the choices of
| the developers. In (many|most|all|??) of those cases, we
| _should_ try hard to avoid that complexity.
| Brian_K_White wrote:
| In my experience, juniors almost never shout that. They are
| still living within the managed "website in 0 lines of code!"
| world the framework purports to provide.
|
| And mids just think that's what the job is and nothing to do
| about it. It's not 1985 any more and 1985s tools aren't
| enough to write a cloud db backed ios app.
|
| It's the seniors, and the good ones at all levels even if
| they aren't good at it yet, who object to complexity on a
| pure lack of elegance basis. They value elegant solutions and
| complexity is usually the ugly brute force solution that's
| merely complex when it's claiming to be sophisticated.
|
| Even if they don't have any idea what to do differently, they
| just know that something surely can't be sensible just on the
| face of it. I would hope everyone at least _gets_ the ancient
| "hello world by different levels of programmer" joke, and can
| see when it starts happening for real around them.
| JohnFen wrote:
| > It's the seniors, and the good ones at all levels even if
| they aren't good at it yet, who object to complexity on a
| pure lack of elegance basis.
|
| I actually think the opposite of that. Experienced
| programmers, from my observations, have learned that
| complexity is an inevitability that requires management
| (all nontrivial programming is really an exercise in
| complexity management, after all). They resist adding
| complexity unnecessarily, but also recognize where it can't
| be avoided and opt for managing it instead.
|
| In the real world, "elegance" is an unattainable ideal that
| is to be admired and desired, but experienced devs
| recognize that pushing too hard for it will result in the
| exact opposite of it.
| hayst4ck wrote:
| I'm not a huge fan of these pieces that don't speak to why
| frameworks are created in the first place.
|
| The counter point to this is that the purpose of frameworks is to
| turn O(N) problems into O(k) problems by implementing a seam in
| the code.
|
| The problem a framework ultimately solves is that some teams will
| choose to use screws, some will use a hammer and nails, some will
| use a nail gun, some will use glue, some will carve connecting
| joints, some will use metal and weld, some will take a large
| piece of material and carve it out, etc. etc. and now you have 50
| different ways to perform one task, which is to get the end
| result of joining two objects.
|
| That means 50 different on-boarding processes, and 50 different
| design paradigms to manage, 50 different classes of corner cases,
| 50 different monitoring/operational paradigms, 50 different
| hiring processes, etc. etc.
|
| Sometime between 50-500 engineers it becomes necessary to
| properly framework-ize the unit of business logic that product
| developers work on, like a route, to prevent operational
| overload.
| crdrost wrote:
| Related: "Write libraries, not frameworks," which goes more
| into depth about how frameworks establish precisely such a
| "seam" and the responsibilities it entails.
|
| https://www.brandons.me/blog/libraries-not-frameworks
| hayst4ck wrote:
| > Frameworks' key trait is that they impose limitations on
| the programmer. Rather than providing a set of new things the
| programmer can do, they establish a boundary on the things
| the programmer can do.
|
| Simply stated and very insightful.
|
| This is a way better article than the posted one.
|
| Another way of thinking about this is that a framework is a
| regulating authority on a tragedy of the commons. The commons
| in the case of software is complexity. Too much complexity
| becomes impossible to manage and grinds development to a
| halt.
| sn1de wrote:
| Yes, the state of the industry is a hot mess, but I'm not sure
| this article rings true. Failing to leverage good frameworks is
| as big a problem as over using the bad ones. I would point to
| Rails as an example of an appropriate framework (and Laravel if
| PHP is your jam). The trouble is so many others are bad,
| incomplete or defunct, but I don't think the answer is the golang
| mantra of 'we don't need no stinking frameworks'. Seeing mediocre
| developers reinvent the wheel, slowly and badly, is super painful
| and wastes time and money. If you hate the frameworks available
| to you then perhaps you should consider finding a better
| ecosystem. Relax your bias and follow the happy developers,
| wherever that may lead.
| sbr464 wrote:
| This is getting old.
| projektfu wrote:
| For some reason it called to mind the basic technique of stepwise
| refinement.
|
| https://dl.acm.org/doi/10.1145/362575.362577 (HTML, links to PDF)
|
| A good framework would be one in which you start your solution
| and find that at many locations, your pseudocode gets replaced by
| an equivalent call into the framework. There are, however, some
| other requirements that are not obvious from this specification
| of good framework that make it a great framework.
| Discoverability, testability, debuggability, deployability,
| documentation, readability and, of course, performance.
|
| But, yeah, you start out with one and you lose interest in the
| project because of the difficulty of getting started.
| hardlianotion wrote:
| I like the little joke at the very end.
| revscat wrote:
| Look, if you don't like React just say so.
| hfkwer wrote:
| This piece was written before React even existed. (React is
| from 2013, this is from 2005.) Besides, I can't think of a
| single "factory" oriented concept in React, could you
| elaborate?
| samuellevy wrote:
| Ok.
|
| I don't like React.
| JohnMakin wrote:
| This is taking a shot at Java, and a pretty old "joke" but I've
| heard of this actually being a thing out in the wild:
|
| https://stevenheidel.medium.com/a-factoryfactoryfactory-in-p...
| deepsun wrote:
| Thanks for the source!
|
| Although, frankly speaking, Java libraries are still the most
| convenient to include/extend than most other compiled languages
| I've seen so far. Probably because of that culture of over-
| engineering for abstraction/extensibility.
| cataphract wrote:
| It's rich from someone coming from scala. I frequently see
| lambdas returning lambdas returning lambdas that return a new
| object.
| gottorf wrote:
| Another fun shot:
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
| jameslk wrote:
| Looks like the FactoryFactoryFactory was proposed but a PR
| wasn't ever created sadly: https://github.com/EnterpriseQuali
| tyCoding/FizzBuzzEnterpris...
| gigel82 wrote:
| This must be a Java joke I'm too C++ to understand.
|
| But I was actually hoping for a factory automation online game
| because I feel like I need to sink the next 2 - 14 days of my
| life into a shapez.io or mindustry or something like that...
| TOGoS wrote:
| It is Java's particular set of features and lack of features
| that give programs written in it a tendency towards design
| patterns like the one described.
|
| - Everything's an object -> Let's define lots of nouns!
|
| - Classes cannot be declared to implement interfaces after the
| fact -> Let's write some adapter classes!
|
| - People get tired of writing adapter classes and notice that
| JVM has reflection capabilities -> Let's make a framework that
| generates adapter classes as needed!
|
| - Everything's heap-allocated -> Let's avoid excess allocations
| by re-using objects! Which means you've got a big web of
| interlinked mutable thingamabobs floating around, made possible
| by Java's pretty-good GC.
|
| - 'const'ness ('final'ness in Java-ese) is defined on the type,
| not on where it's used -> Most classes are written assuming
| mutability, and if you want immutability, you need to create an
| entirely separate type hierarchy.
|
| I could go on.
|
| When I want to write a Java program but keep it simple, I
| usually end up writing something that looks more like a C++
| program. Minimal, domain-specific classes with as much setup in
| the constructor and as much `final` as I can get away with. But
| it's not as ergonomic a language for writing programs in that
| style as C++ is. And once a coworker brings in some library
| written in the conventional combinatoric-explosion-of-classes-
| and-pointers-to-mutable-objects-everywhere style, you're pretty
| much stuck with it.
| pharmakom wrote:
| Frameworks are bad because they don't compose. What does compose?
| Simple types and pure functions. If you want to create a
| community with high levels of code reuse, start there.
| skydhash wrote:
| I was listening to a talk (strange loop conf, can't search the
| talk itself) where the speaker claims C languages derived from
| it feel clunky because they are invented, while Lisp, Haskell
| are discovered. The latter are more cohesive and relies on
| simpler truths instead of the amalgam of idioms you can find in
| Java.
|
| I concur with this because programming with Clojure feels
| amazing. Your code is a straight line from input to solution.
| With imperative languages, you see yourself applying the duct
| tape.
| Adamantcheese wrote:
| Should've just used a rock instead. Free and you can argue about
| whether expensive European mountain rocks work better.
| [deleted]
| dang wrote:
| Related:
|
| _Why I Hate Frameworks (2005)_ -
| https://news.ycombinator.com/item?id=28920095 - Oct 2021 (296
| comments)
|
| _Why I hate frameworks (2005)_ -
| https://news.ycombinator.com/item?id=12635142 - Oct 2016 (66
| comments)
|
| _Why I Hate Frameworks (2005)_ -
| https://news.ycombinator.com/item?id=9203959 - March 2015 (63
| comments)
|
| _Why I Hate Frameworks (2005)_ -
| https://news.ycombinator.com/item?id=6542817 - Oct 2013 (37
| comments)
|
| _Why I Hate Frameworks (2005)_ -
| https://news.ycombinator.com/item?id=6283601 - Aug 2013 (118
| comments)
|
| _Why I Hate Frameworks_ -
| https://news.ycombinator.com/item?id=2787525 - July 2011 (100
| comments)
|
| _Why I hate frameworks (2005)_ -
| https://news.ycombinator.com/item?id=1533274 - July 2010 (55
| comments)
|
| _Why I Hate Frameworks_ -
| https://news.ycombinator.com/item?id=431786 - Jan 2009 (125
| comments)
|
| _Why I Hate Frameworks_ -
| https://news.ycombinator.com/item?id=95722 - Jan 2008 (18
| comments)
| briantakita wrote:
| If only there was a framework to locate Why I hate framework
| posts...
| sixstringtheory wrote:
| There must be some metric of the resonance of a particular
| piece by looking at the number of reposts and distribution of
| comments amongst them (plus an analysis of the sentiment of the
| comments and characteristics of the thread trees in each
| separate posting).
|
| Just looking at this listing, without looking at the comments
| in each one, this seems to have a sustained resonance.
|
| Maybe I'm biased-it certainly resonates with me!
| hexage1814 wrote:
| This whole thing reminds me this simpsons joke from S10E03:
|
| https://www.youtube.com/watch?v=LuiK7jcC1fY
| Escapado wrote:
| This reminds me of FizzBuzz Enterprise Edition and I have come
| across software that was pretty much written like this more than
| once.
|
| To be fair: finding the right level of abstraction in a sea of
| uncertainty can be a tricky problem - but sometimes this also
| just happens for very different reasons than out of necessity
| (ivory tower architecture commitees, external companies selling
| the most expensive solution, ego fueled idiocy or just plain old
| ignorance).
___________________________________________________________________
(page generated 2023-07-07 23:00 UTC)