Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

261–270 of 338 posts

Re: Write Libraries, Not Frameworks

#261

Post by choward »

cageface wrote: post #197
skohan wrote: post #141

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functi…

I’ve been working in some largish Rails codebases lately and this is exactly the problem I have. When I’m looking at a screenful of code I have no idea who is calling what, what’s in scope and from where, and what the shape of any of my data is. In my opinion the productivity benefits of these kinds of frameworks evaporate and go negative pretty quickly once you move very far beyond what they provide out of the box.

I think a lot of that has to do with Ruby not having real modules and everything being global.

Re: Write Libraries, Not Frameworks

#262

Post by ljm »

delusional wrote: post #232
nickbauman wrote: post #209

Earlier quoted context omitted.

DI/IoC is just another way of expressing global variables. The global variables exist because of the constraint of class-orientation getting in the way, among other things. Spring exists because of the relative weakness of the Java language. You won't see this kind of technology emerging in more powerful languages.

This is very often the case. So often you see these stateless "service" classes injected everywhere. It's not an object at all, it just free functions packaged in a namespace with a vtable in front of it that now need to be allocated. A language with free function support alleviates that problem.

I'm having to do a lot of this now and I cannot imagine having to write any code, in any language, this way without depending on a magic IDE and other magic libaries.

To be fair, at least Spring and Lombok don't require me to maintain loads of yaml/XML files to describe the DI stuff, but annotations in java aren't always the most intuitive thing.

Requiring a class representation of literally everything is a huge limitation, and I wish there were other alternatives to this style of DDD that abstracts everything to an absurd degree.

Re: Write Libraries, Not Frameworks

#263

Post by ljm »

majewsky wrote: post #234
gombosg wrote: post #226

Earlier quoted context omitted.

The problem with over-engineered projects... our team inherited a project that was designed by some architects in an ivory tower and implemented by some other engineers. It was quite complex (message queues, multi-threading, async etc.) so that it would be 'scalable' yet crushed under the slightest load, customers were experiencing delays during peak hours. We removed about a quarter of the code (some intermittent qu…

> Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope. This is a very good attitude, but I would like to tack on a second part to it: Instead of designing your code to be infinitely extensible in all directions, make it easily replaceable instead. It's impossible to anticipate every future requirement, but certain choices will make it easier to deal with a new re…

I'm a strong proponent of this attitude. The most maintainable code is that you can easily delete.

It does require a lot more thought and discipline, because it's not just a case of constructing an epic hierarchy of abstractions, or stubbing/mocking the hell out of your code in the tests to swap things around.

Re: Write Libraries, Not Frameworks

#264

Post by hinkley »

skohan wrote: post #141

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functi…

In a similar vein: boilerplate code is fine in the main control flow. It’s okay if it takes twenty lines of code to set up your library, as long as it’s not the same 20 lines for everybody in production.

Frameworks tend to avoid any boilerplate in the imperative core but then multiply I throughout the rest of the project. Possibly due to chronology.

Re: Write Libraries, Not Frameworks

#265

Post by sidlls »

A common objection to this is the proposition that eventually engineering will produce a framework, even if it's not intentional, so why not just choose an existing one and adapt/patch as necessary?

I tend to agree that good engineering teams will produce a useful framework, eventually--but this framework will be very specific to the domain of the problem it solves. It will be extensible and flexible to add new features to. It won't be something that can be generalized well to other problems, though.

Re: Write Libraries, Not Frameworks

#266

Post by ljm »

ivalm wrote: post #149
pfarrell wrote: post #121

Earlier quoted context omitted.

Everybody nowadays is inplementing HumorSensorFactoryFactory to define their own rules for what’s inbounds.

No, real people use EmotionSensorFactoryFactoryFactory. Why limit yourself only to HumorSensorFactory objects?

You really need the MaybeEmotionSensorFactoryFactoryFactory to avoid getting NullPointerExceptions when applying to psychopaths.

An AbstractEmotionSensorSensorFactory would be required to unwrap that.

Re: Write Libraries, Not Frameworks

#267

Post by bane »

arethuza wrote: post #201
userbinator wrote: post #9

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…

My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work! I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - req…

Similar experience here. About 6 months ago I inherited a team of 30 that had spent 4 years building some monstrous microservice "thing" that didn't work and never seemed to build reliably and barely worked even if it could be deployed. Lots and lots of late nights trying to "deploy to testing" and wasted weekends restarting things.

I stopped the work, broke the team up (and let a few of them go), re-assigned the goals of the project to 3 people who, working half-time, from scratch, and in Python, rebuilt the entire thing in 3 months, delivered it and it worked (and continues to work). "Builds" are now an scp to a VM, and a restart of a flask application.

My wife recalls a similar experience where a complex application she worked on (and ran reliably on very little infrastructure and with an entire team of 4), and serviced thousands of simultaneous users, was replaced (when a new CTO came in) by a giant, consultant driven Java project that required approximately 6x the infrastructure, 3x the staff to keep it going, and at launch could only serve 9 to 12 users at once. It was a debacle. But sunk cost fallacy forced her company to throw millions of dollars of consultants at it until it achieved some minimal level of barely available service. She and her boss left around that time.

She heard that a couple years later the CTO was let go, the consultants fired and it was all replaced by a team of 5 rewriting it all again from scratch (in Java) but like you also without all the architecture barf dropped in from orbit, and immediately went back to servicing the thousands of users again.

I'm convinced that this is the fault of some kind of consultant industry that seems to infest enterprise software circles that is really only good at inventing ways of designing systems that require more of their services, but never seem to actually deliver working systems.

Re: Write Libraries, Not Frameworks

#268

Post by lhorie »

strogonoff wrote: post #214
lhorie wrote: post #55

Earlier quoted context omitted.

I would argue React is actually a great example why the article title is on point. Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year. Now consider tools like Redis or Postgresql. You can interface with…

This thread is peculiar. Framework library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library. The re…

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form.

FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React)

Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written.

Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL)

[1] https://medium.com/@balramchavan/integrate-import-angular-v6...

Re: Write Libraries, Not Frameworks

#269

Post by teddyh »

mperham wrote: post #258
teddyh wrote: post #240

Earlier quoted context omitted.

> What's that, standup comedy for psychos? You’ve got it backwards. No “psycho” would consider it funny; they would just consider murder something normal one could conceivably do with a hammer. There is nothing funny about it, to them; it’s just normal. The murder joke was only funny to those people who consider murder something utterly unthinkable. It is its very outlandishness which creates the humor. If it is no l…

There are lots of edgy, ironic white supremacists these days. Masking aggression with humor is an age-old tactic.

You can only mask outrageous things as humor if they are so utterly outrageous as to be virtually unthinkable. If they become only slightly plausible, they become no longer funny. Therefore, if jokes about murder are no longer funny, it’s because people no longer believe that murder is as likely to be unthinkable as it used to be.

This is why I think that masking outrageous things as humor is a losing strategy. Either it is funny, in which case the thing being masked with humor is so outrageous as to be completely niche, making the secret signal irrelevant, since so few people recieve it. Or, the thing is such a relatively common stance to make it no longer absolutely unthinkable, which makes it no longer funny, which removes the mask.

(Also, how do “white supremacists” fit into this? The original joke was about murdering an ex-girlfriend. This might possibly be generalized into misogyny, but I fail to see the connection to white supremacy. Please don’t fall into thinking that all people who hold opinions which you don’t like also hold all other opinions which you don’t like.)

Post reply on HN