Hacker News Reader

Comment by CraigJPerry | Hacker News Reader

>> I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts.

I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point.

Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all.

I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!”

>> Can you name

Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.

View on HN

(going with the definition that frameworks are "your code gets called into by the community code" where libraries are "you call into the community code", please correct me if I'm wrong)

There are some very nice FP frameworks, for example Phoenix LiveView, or phoenix in general. Elixir has lots of mini-frameworks (like the Enum and Access protocols). They're a joy to work with and pretty easy to understand. I'm not really sure what constitutes a plugin, but I've written what I would consider "plugins" for the BEAM vm (loaded at runtime, with an exposed API behaviour called into by the system), and they're pretty smooth and easy to handle.

Arguably all of the BEAM OTP (std lib) and the patterns that packages expose for building persistent services are FP frameworks. If I may be permitted to make a more apples-to-apples comparison between the Erlang BEAM framework, to the BeOS C++ framework (both highly concurrent message-passing, actor frameworks). While I loved programming for BeOS, IMO doing everything functionally is far far smoother an experience than doing everything with objects. Both I enjoyed far more than programming the Dalvik (android) Java framework (though that was circa 2009).

Anyways having experience in all four quadrants, I don't think it's as simple as ("frameworks/plugins -> OOP; libraries -> FP).

Can anyone explain to me what the difference between a framework and a library is? I've looked it up several times but it always seems cloudy at best, and it seems like some things that are referred to as frameworks are pretty similar to some other things referred to as libraries.

My favourite explanation is that a framework calls your code, whereas for a library, your code calls the library functions. Does that make sense?

Basically like when you call something like:

   Math.abs(-5)

That's a library call.

A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...

And what about React? If you search for "is React a framework" you'll come up with many, many people saying that it's a library. And yet, when writing a React app you absolutely have to structure your code a certain way.

Things can be both a library and a framework. You can use react like a utility and react itself can take have code injected in it.

1. Framework owns your main() function. Using libraries you don't lose control of your main().

2. Hollywood principle. Library: you call us. Framework: we call you.

3. Frameworks are good for novices in certain paradigm because they guide along a standardised way to build apps. If you however find the framework's way not precise enough or its abstraction leaky then you will have a hard time escaping from the straightjacket.

Lot of frameworks actually are a combination of two things:

1. the actual "way of building apps"

2. useful library of functions

Lot of people would like to start with 1 and use 2 to guide them in the beginning, but drop 1 later on. Unfortunately frameworks couple 1 and 2 together very tightly making many people not even consider such frameworks.

1. None of the programming languages I use regularly have the concept of a main() function (not dismissing the point, just saying it's language specific). 2. Yeah, heard this one many times. It seems very hand wavy to me. 3. That's more a cost/benefit analysis than an explanation of the difference.

> Lot of frameworks actually are a combination of two things:

> 1. the actual "way of building apps" > 2. useful library of functions

This describes React pretty much spot on. And yet, React people are very determined to point out that it's React is a library, not a framework.

The hollywood principle is actually to me the definitive criteria. You plug your code into React and React ends up orchestrating and coordinating between your code, thus it is in charge of calling it and in what order etc.

That's normally what I would call a framework.

Now I don't know, maybe there's ways to use React only as a library, not sure if it would provide any benefit in that way.

Reply on news.ycombinator.com