Live data from Hacker News

Frameworks are for hacks, libraries for seeds

sencjw.com

31–40 of 50 posts

Re: Frameworks are for hacks, libraries for seeds

#31
The first few truly complicated frameworks I learned were very useful. IIRC, they were Borland's OWL, MFC, Win32/kernal stuff, and .NET internals.

They were useful because learning them and walking through code while debugging showed me all sorts of best practices (and worst practices). When I wanted to use the GDI I grabbed a handle, basically a hash in a lookup table somewhere. This made sense. When I was programming custom VBX controls, I used the USER part of the WM_ space and sent messages back and forth. Loved the message loop paradigm.

But then something funny happened. Frameworks no longer helped me complete a complex project, they actually got in the way of doing it, by adding a lot of intellectual overhead for very little return. I started seeing new programmers pick up some training, start using a framework, and then get completely lost when their work took them anywhere off the "happy path". People would spend a hell of a lot of time learning framework X, only to eventually realize that the next job required framework Y.

As I got older, my recall isn't what it used to be, which actually turns out to be a good thing -- it forces me to focus on important things instead of minutiae. I got much more radical about web apps. I'm happy with static web pages that are interactive for most everything. I don't code things that do deep-dives into the guts of the stack. I'm looking to provide the most value in the least amount of time (and cognitive overhead). I moved to pure FP.

So now my order is: 1) Code it myself, 2) Use a precanned library, 3) Use a framework

The frameworks I use are very small: JQuery, .NET, maybe one of two others. I like it that way.

Re: Frameworks are for hacks, libraries for seeds

#33
post #14

The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. It gets especially tricky if one library uses a garbage collector, and another library uses a different one. You could get cycles between objects managed by different libraries, which w…

The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. This is a real problem, certainly. In very bad cases (anyone remember programming COM from C++?) the burden of making a simple function call from one part of your code to another can be…

This is the idea of my current language I'm brainstorming: modules as the central unit of design. I want to figure out how to encourage developers to write software as a collection of loosely coupled modules, rather than monolithic blobs. I hope that a module-centric design would let us make assertions about types, purity, and other FP-esque things.

Right now it's just in the "I'd like this and this" stage, but I hope to work on it more this year.

Re: Frameworks are for hacks, libraries for seeds

#34

It depends what you're developing. If you develop a product (startup) that will change the world, you spend a lot of time, you put your heart into this product, you should understand every line of code, so you develop a product not framework. If you create site by site every week or day for your clients, you need a framework.

Or, what you are building requires somewhat complex components, but you'd rather focus on something else? Many frameworks have their own component libraries.

I'm not talking simple tooltips, I'm talking about real components. Sencha's tree.Panel comes first to my mind: http://docs.sencha.com/extjs/5.0/5.0.1-apidocs/#!/api/Ext.tr...

It has extremely powerful feature set (based on the other features of the framework) out of the box and you can very fast switch your focus on other things besides re-implementing the wheel.

I simply haven't found some of these things as simple libraries. They nearly always come within complete frameworks, because they have had to implement a lot of stuff that really just requires other features from frameworks. And, no, I'd rather not spend a year implementing that feature set.

Re: Frameworks are for hacks, libraries for seeds

#35
I agree with the sentiment of the of the article. Dependencies should be isolated and not spread out all across your application. Even though both don't have tight definition, I think it's fair to say that a framework is usually larger in scope and API surface area than a library and usually impose a certain way of coding (and toolchain) on you. Isolating your dependencies (gui, persistence, ...) is a lot easier when you use a small library than using a framework that pretends to have all the answers.

It is true that you have to lay out more infrastructure yourself working this way but I feel that this is a really good thing because it makes you really think about the problem you are trying to solve, and don't just think in terms of the patterns your framework offers (e.g. MVC: "I have some logic, so I'll put it into a controller!"). This usually leads to code that is a lot easier to understand and is easier to test. Also, every application is different and with the framework way of doing will always end up having to shoe-horn things.

Re: Frameworks are for hacks, libraries for seeds

#36
post #5

When you're using libraries, you're actually making your own custom framework. Because a framework is basically a set of libraries that work together to help you get to a certain goal. If there's already a framework that helps you get to a certain goal, it can save you a lot of work to use that existing framework instead of making your own. It can also save you a lot of security issues. But if your requirements don't…

A framework is a set of decisions that have already been made for you - which might include 'we should use these libraries', but could also be 'we'll put our CSS files here' or 'all URLs will look like this'. That can be a huge help - unless any of the decisions are wrong for your use case.

Deciding to use a library might, of course, also force some other decisions, because the library has dependencies, but the decisions should be more constrained than they are for a framework.

Re: Frameworks are for hacks, libraries for seeds

#37

Earlier quoted context omitted.

The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. This is a real problem, certainly. In very bad cases (anyone remember programming COM from C++?) the burden of making a simple function call from one part of your code to another can be…

This is the idea of my current language I'm brainstorming: modules as the central unit of design. I want to figure out how to encourage developers to write software as a collection of loosely coupled modules, rather than monolithic blobs. I hope that a module-centric design would let us make assertions about types, purity, and other FP-esque things. Right now it's just in the "I'd like this and this" stage, but I hop…

Sounds interesting, and I wish you luck. I think if we had more and better options for gluing together good quality modules, some of the related arguments that push towards frameworks over libraries today would also be diminished. Then we could make decisions based on the fundamental frameworks vs. libraries question of you-call-us or we-call-you, without any bias from what should ideally be independent questions of consistency and interoperability.

Re: Frameworks are for hacks, libraries for seeds

#38
post #5

When you're using libraries, you're actually making your own custom framework. Because a framework is basically a set of libraries that work together to help you get to a certain goal. If there's already a framework that helps you get to a certain goal, it can save you a lot of work to use that existing framework instead of making your own. It can also save you a lot of security issues. But if your requirements don't…

If you're going to not use a framework, then end up creating a framework, then you've defeated the point of not using a framework and you might as well have used an existing framework and saved yourself the effort.

It's entirely possible to build applications without infecting it with anything that looks like a framework if you resist the urge to create unnecessary abstractions and keep coupling to an absolute bare minimum. Keep it simple and focus on the task at hand.

Re: Frameworks are for hacks, libraries for seeds

#39

If indeed that's the case, then welcome to the era of the quick hack. From the nanosecond the user hits the power button on their little box, and the BIOS loads 0x7c00 and executes it (loosely defined, frameworks call your code), we're in framework world. You want your browser loaded? Better hope that the user clicks it, and the OS calls your code, because otherwise you're malware (and you were still loaded by the OS…

loosely defined, frameworks call your code You're interpreting the poster by pulling the definition past the breaking point of any utility to this conversation. Either air your grievances with the word "framework", or try and read what the author meant.

Alright, to be more strict, let me quote the definition per Wikipedia:

> In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. [1]

I fail to see how I'm stretching this definition at all, especially if you read further into the wikipedia article. I believe it's critical that I acknowledge when I'm wrong, lest I stay stagnant in my understanding, but I don't think I'm wrong here, unless somebody wants to point out a specific area.

Userland software customizes and reuses default behavior of the OS for application-specific purposes. Web pages customize and reuse default behavior defined by the HTML, CSS, and JavaScript specifications. Same goes for Operating Systems on top of the BIOS and on top of the hardware itself.

Frameworks are useful, basically unavoidable, and critical to take the time to understand if we're going to be effective at any level, be it consuming them or providing them.

[1] http://en.wikipedia.org/wiki/Software_framework

Post reply on HN