5 ms·
>> 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
by CraigJPerry 6y ago
>> 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.
- dnautics 6y ago(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).
- esperent 6y agoCan 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.
- phyrex 6y agoMy favourite explanation is that a framework calls your code, whereas for a library, your code calls the library functions. Does that make sense?
- leafboi 6y agoBasically 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...
- esperent 6y agoAnd 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.
- leafboi 6y agoThings 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.
- snidane 6y ago1. 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.