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

221–230 of 338 posts

Re: Write Libraries, Not Frameworks

#221

Post by dTal »

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…

Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function.

(I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)

Re: Write Libraries, Not Frameworks

#222

Post by catern »

gruez wrote: post #215
keanebean86 wrote: post #112

Earlier quoted context omitted.

Even the CPU adds at least one layer of abstraction. Spring JVM Container OS hypervisor x86 Real CPU instructions Electrons Unknown EDIT: formatting

Are hypervisors and containers really abstractions though? All they do is manage access to the underlying resource.

A hypervisor definitely is; the "hardware" interface for a kernel running as a (performant) VM is different from the hardware interface for real hardware.

I think one could argue that containers aren't much of an abstraction for the running program itself, though, as you say. The place where containers provide an abstraction is at deployment time/process management time; the program itself has (essentially) the same API whether it's running in a container or not.

Re: Write Libraries, Not Frameworks

#223

Post by HarHarVeryFunny »

This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the idea is that it can be applied to all sorts of domains, whence it's also associated with Brook's Mythical Man Month about software development.

The association here is that frameworks are "form". One might intuitively think that form/frameworks is/are constraining rather than liberating, but per the sculptural analogy the roughed-out shape provided by the framework liberates you to concentrate on the details rather than suffer from analysis-paralysis when there is too much freedom of approach (just a large block of marble from which you might sculpt literally anything).

But it depends on the scope and nature of what you are trying to do ...

If your problem fits withing the scope/form of the framework, and your value-add is in the details, then using a framework, all else considered, make sense.

Alternatively, when you are trying to do something outside of the norms of gentrified frameworks, then the flexibility of libraries (or ultimately a blank sheet of paper) is what is called for.

Of course, the devil is in the details... a poorly designed framework may be TOO constraining and not provide enough flexibility to be widely applicable, while poorly designed libraries may be overly restrictive due to poorly designed APIs that don't place nice with other libraries or the data structures you'd like to use.

Re: Write Libraries, Not Frameworks

#224

Post by vidarh »

rclayton wrote: post #117
lmm wrote: post #104

Earlier quoted context omitted.

Just use a language where it's possible to implement those things in plain old code. When you have higher-kinded types you don't need any bytecode manipulation, you can just have a type that wraps anything that needs to happen in a transaction, and compose together transactional operations in a visible but type-safe way - and you don't even need the runtime cost. How anyone can look at Java as it's actually used and…

I think you are being completely unfair here. AOP in Java (and .NET) is a metaprogramming facility that has few equivalents in other languages. The closest thing that comes to it is macros, but those are often compile time modifications. More importantly, nothing about standard Java development requires The use of AOP.

AOP is doable in most languages that allows very basic levels of runtime instrospection and manipulation of objects and types, and is easy in a large number of them.

In Ruby, for example, "alias_method", "define_method" and "send" is sufficient to implement cross-cutting in a handful lines of code, and at least one generic gem exists that provides basic cross-cutting in a generic way.

But it's very rarely done because it's generally cleaner to pass down code for the library to explicitly call.

I used to be very excited about AOP, but in effect while AOP can be great as a debugging facility (e.g. ability to inject logging at any point for example), when you have control over the design it tends to be better to explicitly build code so that it is designed to accommodate user provided functionality. In Ruby that tends to involve e.g. the ability to pass in blocks a lot of places.

Re: Write Libraries, Not Frameworks

#225

Post by finnthehuman »

mping wrote: post #151
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…

I remember the Rails people making fun of the Spring stacktraces vs the Rails one (being much shorter). Guess what, a couple of years later Rails has the same layers of abstraction

It was always an argument about fashion. It just wasn't in fashion to admit that out loud at the time.

The conclusion was "the rails-not-java club is best" and then everyone worked backwards to find believable reasons why. At the impromptu pitch meetings "minimalism vs. complexity" took off.

Now that the rails club is out of fashion and the k8 club is in. Well, we'll invent reasons that over-engineering is better than deployment automation that "just" sticks a .jar in a .deb and apt-get upgrades a handful of non-virtualized servers colocated at a local datacenter.

Re: Write Libraries, Not Frameworks

#226

Post by gombosg »

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…

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 queues & components), nothing changed in terms of functionality. Now we're removing more code and switching over to less complex data structures to fix the delays.

Maybe a complete rewrite would have been better after all, who knows.

I'm not a very experienced developer. I like to ship stuff and get projects done in reasonable time and a "YAGNI" attitude. Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope.

On the other hand, I see a tendency that if you give projects (it could be a greenfield project or some maintenance) to a team of, say, 6 developers, then they will just 'create work' for themselves, filling up the todo list with items which may lead to an over-engineered project that could have been easily be done by 3 people within the same timeframe.

If you have some good reads/stories on this topic, patterns to watch for, I'd appreciate if you shared them.

Re: Write Libraries, Not Frameworks

#227

Post by finnthehuman »

ngngngng wrote: post #91
wetmore wrote: post #12

Earlier quoted context omitted.

The repeated joke about killing your ex-girlfriend did not age well.

I hope, one day, that we look back on the "woke" over-analysis of the last few years and say "That didn't age well."

This too shall pass.

Re: Write Libraries, Not Frameworks

#228

Post by Nursie »

chii wrote: post #206
Nursie wrote: post #189

Earlier quoted context omitted.

I agree, things should be straightforward, readable and logical. The Java people are describing here is alien to me, and I code Java for a living at the moment.

> The Java people are describing here is alien to me, and I code Java for a living at the moment. you're looking at enterprise java, not regular java

I'm certainly not! You take that back! Yuck!

I'm writing microservices using a relatively lightweight, straightforward and explicit web framework (sparkjava, which is more of a library than a framework really), modern language features and no AOP...

Enterprise... pah!

(Oh, unless you mean the Spring crowd are enterprisey, in which case I take that all back.)

Re: Write Libraries, Not Frameworks

#229

Post by OJFord »

dTal wrote: post #221
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…

Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function. (I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)

Instead of using something you're quasi-allergic to, you could work on one you're not?

Re: Write Libraries, Not Frameworks

#230

Post by Kye »

stiray wrote: post #130
sidpatil wrote: post #70

Earlier quoted context omitted.

"If you wish to make an apple pie from scratch, you must first invent the universe." —Carl Sagan

... but at the end you get perfect apple pie that is exactly tailored to the ecosystem, doesnt suffer from overdesign, bloat, is baked to perfection and its taste is from heaven. The only question is if you can afford hiring a few gods for the task or you are rather satisfied with whatever falls off a truck and in reality is completely uncapable of inveting universe (or even capable of baking). At the end the custome…

All you have to do is run the simulation forward enough until sentient life develops and becomes the universe. Then you can bake any pie you like.
Post reply on HN