[chuck32]

  This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language.

This is just not true. The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc. The author seems to be coming from an academic view point and the points he makes really don't translate to the software engineering world.

His analogy about frameworks being package holidays while composing libraries is like independent travel only tells half the story. How do you organise the interaction of libraries? You can do it yourself but you will have to follow some sort of pattern to organise the code in order to make it easy to work with. What happens when another coder joins your project? Are you going to tell them the pattern you have already been using? What if they dont follow it as expected or disagree with it? Frameworks standardise this. Yes you might not always like certain aspects of the framework you're using but its the price you pay for not having a project full of developers who each have their own way of doing things and are constantly argueing over how to organise the codebase.

Also this hyperbolic use of the word "evil" is immature and dorky. Sorry.

[willtim]

> points he makes really don't translate to the software engineering world

His advice is in the context of functional programming languages. F#, Scala and even Haskell and OCaml are now very much part of the software engineering world (albeit a small part).

> How do you organise the interaction of libraries? You can do it yourself but you will have to follow some sort of pattern to organise the code

Because libraries compose, there's nothing to prevent a library on top of all these others libraries to accomplish this. If you have to repeat yourself with "patterns", your language of choice is failing you.

[chuck32]

> His advice is in the context of functional programming languages.

Thats not what he says. He says that these ideas "can be useful in any programming language". Which is the point that I disagree with.

> there's nothing to prevent a library on top of all these others libraries to accomplish this

So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?

[willtim]

I agree that his advice will be difficult to follow in less expressive languages.

> So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?

The domain/purpose does not alter the framework/library distinction according to his definition.

[yen223]

Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework. And it will always be a bad fit, popular frameworks are rarely built to cater to a specific domain.

I've worked with Django applications for years now, and this article definitely resonates with me. I think Python and other object-oriented languages have a bad time with composition, which is why overbearing frameworks rule the land.

[chuck32]

  Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework.

Its a fair argument to make but honestly I've never worked on a web app where I didn't think that using an MVC framework like Django or Rails made sense.. Do you have any examples of web apps that would be better off without a framework than with?

Also there are plenty of PHP codebases that were developed "organically" (i.e. without a framework) that are absolute eye sores to look at because without a structure in place its too easy for developers to write bad code.

[yen223]

Speaking as a Python dev...

Light and simple REST servers can be implemented quicker with Flask - less boilerplate and less setup.

Large complex codebases often have design considerations that don't fit neatly into Django's one-model-per-view, all-models-are-backed-by-a-relational-database opinions - think apps that require immutable datastores or frequent calls to an ML pipeline. Those are often better implemented as a composition of various libraries.

The thing about organic codebases is that, you can impose a better architecture if you so wish. Frameworks often make the architectural decision for you, in which case you're out of luck if that architecture doesn't suit your application.

[mrath]

Can't agree more. Both frameworks and libraries have their place. But arguing framework are evil is immature. If you are not using one, you probably are building one without you being aware of it. Use whatever works.

[erikpukinskis]

> The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc.

Why? I use JavaScript solely, and I agree with the author 100%. The frameworks solve a lot of problems, but by bundling those solutions together they introduce a new problem.

> How do you organise the interaction of libraries?

This is what coding is. Asking this question over and over. You can't escape it. You can make a promise to yourself: "I'll just do it the Rails way" but that doesn't get you off the hook. Now you need to learn what the Rails way is. And that itself is never done. You will need to ask over and over "What is the Rails way?"

> You can do it yourself but you will have to follow some sort of pattern to organise the code in order to make it easy to work with.

Again, that's is what coding is. Patterns. Which pattern do we need now? How about now? How about now? The Rails pattern only takes you so far. And for many problems it will steer you wrong. You can't avoid learning patterns and when to use them, it's part of your job.

> What happens when another coder joins your project?

Part of why this is scary, is because if you use a framework that coder REALLY needs to understand the framework. The framework itself is a big domain of code that you generally don't want to have to debug, and you don't want to have to wonder how it works. You kind of need to know how it works before you start.

But idiomatic code is different. If I write a system in pure, idiomatic Java, with no framework, a new programmer doesn't have to understand any kind of underlying system. They don't need to understand a framework, because there is no framework. All of the code is right there in the repo. They can just go read it. They can place a debugger and walk step by step through the whole interaction, without ever leading their codebase.

> Are you going to tell them the pattern you have already been using?

Yes, usually if they're new we pair program until they get a sense of the layout. But again, they don't need to learn the pattern in the same way that you need to learn the Rails routing pattern, or the Rails ActiveRecord pattern. You don't need to learn the pattern of a bespoke codebase, because you can just go read the code. There's not some separate system which is doing it's own thing in parallel to your application, there's just your application.

> What if they dont follow it as expected or disagree with it?

Great! That's their job too. They should disagree with the architecture, find better ways of doing things, and talk about that with their coworkers.

> Frameworks standardise this. Yes you might not always like certain aspects of the framework you're using but its the price you pay for not having a project full of developers who each have their own way of doing things and are constantly argueing over how to organise the codebase.

Sometimes that standardization is a worthwhile tradeoff for sure. If you need to get up and running quickly, and you want to start with a big team who already has some alignment, you definitely need some standards.

You also probably want a framework if you're building lots of apps that will mostly not be maintained. So, like special event apps for NFL playoffs, or marketing campaigns or something.

But if you're starting with a couple of developers and growing organically, and if you're trying to build a product that you will be actively adapting to your business needs for many years, a framework might get in your way in the long run.