15 ms·

When FP? And When OOP? (2013)

• tasubotadas 8y ago
  Usually, I follow a general rule of thumb: * For domain language (entities, services, value objects) use OOP as it is better at communicating intent * For data processing and low-level algorithms (usually happens inside OOP methods) use FP style as it is less error-prone.
  • gardaani 8y ago
    I found an article which has similar rules: * Use FP when you need to build something purely computational. * Use OOP when you want/need to build something generic for other people to use. * But if you are application or game developer, ECS way of thinking brings a lot of benefit to the table. https://hackernoon.com/when-not-to-use-ecs-48362c71cf47 https://hackernoon.com/when-not-to-use-ecs-48362c71cf47
    • yogthos 8y ago
      I have to disagree here. It's much easier to use data driven APIs than OO ones. With the former you get what you see and there are no additional rules. You call the API, it produces some result that you can use in any way you like. Meanwhile, objects have behaviors and internal state that you have to understand because each object is its own ad hoc DSL with its own rules and behaviors.
  • danmaz74 8y ago
    I write mostly Ruby these days, and this is my approach too. I usually write the pure functions as class methods. It would be great if it was possible to declare a function "pure" and have checks that it only uses pure functions itself - although this would be impossible to guarantee with Ruby, given its extremely dynamic nature.
  • UK-Al05 8y ago
    I would read Domain modeling made functional. I wouldn't go back to domain modelling in a oop language after that.
• millstone 8y ago
  What do others think of "SQL as a very functional language?" The insight that businesses decouple data from procedures is right. But SQL has poor support for functional hallmarks such as recursion, functions as first-class values, etc. SQL is not functional but declarative: it's less Haskell and more Prolog.
  • haolez 8y ago
    I agree with your assertion and I think that SQL is a fantastic language, regardless of which implementation we are dealing with.
  • whackjob123 8y ago
    I completely lost him at that point. Like you said, SQL is more like prolog. To boot, it's a language designed to mutate data, using a sequence of commands. Not very functional in my mind. I think the whole article suffers from a poorly defined notion of what functional exactly means, and what OOP exactly means, and I think the next step would be to stop thinking in terms of OOP and functional because most industry languages tend to blend elements of both now, so it is better to break it down into the features that you find useful and analyze them one by one such as, can functions be values, is there immutability support, pattern matching, types of polymorphism, generic data, etc etc
  • sidcool 8y ago
    In my opinion, SQL is a good mixture of DSL/Declarative & Functional paradigms. It enables programmers to specify operations to perform without worrying about the 'How'.
  • pdonis 8y ago
    > What do others think of "SQL as a very functional language?" I think the author is using "functional" in a different sense from its usual use nowadays. Basically I think he just means that with SQL, you focus on the operations you're performing (i.e., functions), and the functions are only loosely coupled to the actual data, since you can write many different functions (SQL statements) on the same database, and the same SQL statement can be applied to many different databases with different underlying storage architectures. But of course, as you note, SQL being "functional" in this sense does not mean it supports more recent features associated with functional programming.
• sidcool 8y ago
  This is a good point. Strictly adhering to just one style, either OO or FP, seems very limiting. Instead, this blog suggests guidelines. My favorite line from the post: "Those that are unlikely to change but are subject to being operated upon by a changing cast of entities should be written in a more functional style, while those things that change relatively often can be written in an OO style"
  • innocentoldguy 8y ago
    I can understand that line of thinking, but I don't know that I agree with it. At least not fully. The biggest problem with OOP from a data perspective is that it shleps state around and that state can change in goofy ways, especially when you introduce threads. I think this is where immutable functional programming really shines. I do realize there's a lot more to consider though when architecting a particular solution.
    • sidcool 8y ago
      Totally agree, I would introduce immutability in OO to address Concurrency issues. In short, picking the best of both worlds. Where the conflicts arise is when we have stateless functions. It's a bad practice from OO perspective to have stateless (or static) functions. I am yet to have a good solution to this problem.
      • gmueckl 8y ago
        Objects shine when they encapsulate complex state in ways that disallow illegal states to arise. The trouble starts once you try to add complex transformation processes (e.g. business processes) to objects. When they work on complex graphs of objects, you can't really put them into a single one of them as none of them is the obvious place. What I found to work best is to build an OO data model and a (not necessarily functional) business logic layer on top. In pure OO languages like Java and C# this layer takes on singleton characteristics, which is a clear sign that this code should be simply procedural. The individual functions are often not very interdependent and easy to work on and test.
  • 8y ago
• maweki 8y ago
  I think about using OOP only in terms of the structure of my data. Is my data more easily represented using actual pointer loops or is it a tree structure? With immutable objects you can't easily create longer loops in data (self-reference is okay though). Is my data a tree of some notion, I always go for FP.
• austincheney 8y ago
  > A well-crafted OO architecture makes changing the way things are put together easy. I agree and its why I don't like OOP. Either you are thinking in terms of putting things together or tearing them apart. Complex means to intertwine or put together. OOP thus increases complexity and a well defined OOP system makes increasing complexity easier. I, personally, prefer simple. Simple systems takes more work up front, but are easier to read, reason about, extend, and maintain.
  • mikekchar 8y ago
    While a lot of people make objects for the sake of making objects, I think it is instructive to think why you want to make objects in OO. As another poster has said, what if I had structs and functions with multiple dispatch? Why would that not be better than OO? People tend to think of OO as a way of encapsulating data and then providing access to it. I rather think of it as a way of encoding program state. Often you have multiple operations that you want to perform on the same program state. It is nice to group that code together. Indeed, we have a computer sciency word for that: cohesion. In FP, too, we do exactly the same thing. Take a look at any modern FP program and you will see that it is usually broken down into modules that represent program state. The modules contain code that operates on that state. We do it for the same reason we do it in OO: it creates good cohesion. Getting back to my original question: why not structs with multiple dispatch? Actually, I wouldn't mind that at all (what's not to like about multiple dispatch?). However, the problem, I actually have is the struct. It's the same problem I have with the way many people approach OO: they are thinking about the code from the perspective of how to encapsulate data, not about what functionality they want. They are thinking about raw data instead of program state. A struct is a fine place to store data, but it's not the first place you want to go when you are doing design. Instead you want to build your functionality and identify where you have commonalities in state. Then you should start thinking, "Hey these are using similar state. Are they related? Would it be more cohesive if I grouped them together?" Of course, it would be kind of strange to do that all the time. Most experienced programmers have a pretty good idea what program state they need to work on before they start. They can design data structures that are likely to be needed ahead of time. However, the priority should be to adjust the data structures to match the needs of the program state and to create more cohesive programs -- not to provide rigid boundaries separating your code. Of course, nothing I've said is much different than programming in FP, and I wish that were not a surprise. OO and FP are not really so different. It's pretty easy to make the exact same mistakes in FP as you can make in OO. I sometimes feel like FP is just not popular enough to have widespread bad practices (like writing entire applications using only free monads).
• sifoobar 8y ago
  I'll take structs and multiple dispatch [0] over both of those any day. Raw FP is too primitive and OOP mixes too many concerns, multiple dispatch strikes a nice compromise between the two and offers additional flexibility. While Common Lisp's CLOS is often referred to as OOP, it's definitely less coupled than single dispatch. [0] https://gitlab.com/sifoo/snigl#functions https://gitlab.com/sifoo/snigl#functions
  • sshine 8y ago
    I can't imagine what makes FP too primitive. It is essentially abstract. FP's degree of being primitive depends on the coarseness of its combinators. What I find limiting is easy access to efficient, immutable data structures. Ocaml leaves you with the option to switch to mutable data structures at the cost of safety, and Haskell provides things like the ST monad for handling mutable updates safely at the cost of type-level complexity.
    • sifoobar 8y ago
      The post drew a line between OOP and FP; for that line to mean anything, polymorphism would have to go with OOP. Which is what I meant by raw FP. And solving the same kind of problems without polymorphism (be that multiple dispatch, type classes or otherwise), is a struggle.
      • polityagent 8y ago
        Polymorphism doesn't require anything to do with OOP or objects themselves, see clojure multi methods as an extremely pure example that involves nothing even close to an object. Protocols or typeclasses are also ways to implement functionality over (usually) immutable data. I don't see the relation to a mutable object with a closed set of methods defined at compile time.
        • sifoobar 8y ago
          I didn't make the distinction, the post sort of did between the lines. Go back to my original comment and you'll see that multiple dispatch is what got us here. I never said anything about mutable/immutable data, I'm talking about polymorphism. But I did mention type classes as an alternative. I frankly fail to see how this is leading anywhere.
• jameslk 8y ago
  One important consideration I think that's missing here is how the computation over the data is processed. Immutability, a hallmark of FP, has a small performance hit on both computation and memory[0] but allows for computation to be divided more easily via referential transparency[1]. For applications that will scale horizontally, such as web apps, I think FP makes more sense, since computation over data can spread across multiple servers/processors. Where as for applications that cannot scale horizontally but must be performant, such as game engines, OOP seems to make sense since it makes mutation easier to handle by hiding it with encapsulation. I have a hypothesis that multiple core processors and cloud computing led to the current surge in popularity of FP. 0. https://en.wikipedia.org/wiki/Functional_programming#Efficiency_issues https://en.wikipedia.org/wiki/Functional_programming#Efficie... 1. http://wiki.c2.com/?ReferentialTransparency http://wiki.c2.com/?ReferentialTransparency
  • gnulinux 8y ago
    Imho this kind of thinking is wrong. I believe in every large enough program such as a web server or game engine there will be parts that are suitable for fp and suitable for oop. A web server (of a large enough company) and a game engine are complex enough programs that they do not include one type of data flow, so why would we need to use only one type of programming to formalize that data flow?
    • jameslk 8y ago
      Applications large enough will likely contain both paradigms, yes, but the processing constraints of the application will likely dictate the appropriate methodology to use dominantly. For example, I always found it ironic that the JavaScript library Immutable.js uses OOP heavily, but I'm guessing this was for performance reasons.
      • sshine 8y ago
        Yes, every compiler/transpiler inevitably must address its underlying (virtual) machine's primitives.
  • 8y ago
• asplake 8y ago
  > The central tenet of FP is that data is only loosely coupled to functions. You can write different operations on the same data structure, and the central model for abstraction is the function, not the data structure. Is this accurate? I would see it more as FP separates the two abstractions that OOP (for better or for worse) would have us keep together.
• visarga 8y ago
  The scenario where OO shines is game programming. Each object encapsulates a game entity and it basically runs like a simulator, allowing for complex interactions between objects. But software in general is not like a game and OO doesn't help as much.
  • vesak 8y ago
    Game programmers use entity systems, not OO... or do they?
    • Ace17 8y ago
      Fun related quote from reddit: "you can tell if someone started game development as a hobby because they ARE using an ECS."
      • bni 8y ago
        What do the pros use? Why is ECS bad in a game/simulation type program?
        • afiori 8y ago
          I think it means that pros try to use an ECS but often fallback to object spaghetti. But I might be wrong
        • Ace17 8y ago
          ECS is the "microservices" of game development : it's touted as the way to go, and in some cases it's the best solution, but it comes with increased wiring complexity cost, and the hype surrounding it causes it to often be adopted for dubious reasons (e.g "deep class hierarchies are bad, therefore I need ECS"). Very interesting article here: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...
        • Retra 8y ago
          ECSs are sort of designed to be flexible and make it easy to extend and mix the behaviors of a game. Most games do not need such flexibility, because professional games are designed and you already know what capabilities are needed, and it is more efficient and less complex to implement those things directly. However, if you're designing an open-ended game engine for other people to develop in, then an ECS is a godsend, because you have no clue what they plan to make their game do.
• diminoten 8y ago
  The problem arises when you try to couple an OO language with a FP design (or vice versa). You end up leaving large portions of the language on the floor, and are constantly "inventing" ways to solve problems that you'd get for free if you just did things the way the language was built to do them. The reality is we should be much more flexible with what languages we choose to solve problems, if we want the flexibility to best match our problems to the right design paradigm. Failing that, it's better to go with one "kind" of programming, the one that fits the language. At that point, we're hunting consistency, not the platonic ideal of the solution. Unrelated, but it seems like people here were sold OO as magical or somehow "easy". It's damn hard to get an OO design right, and if it's not working for you, it's probably you and not OO. You probably missed something, which is not only reasonable, but expected. That's where the experience, skill, and expertise come into play.
• willtim 8y ago
  The most useful part of OOP when building large systems, is its inherent support for first-class modules. This is the one feature I miss when working in most FP languages.
  • scns 8y ago
    Check out the module system of OCaml/ReasonML
    • willtim 8y ago
      Yes it's very good, but still somewhat stratified. Checkout the 1ML project for something even more unified: https://people.mpi-sws.org/~rossberg/1ml/ https://people.mpi-sws.org/~rossberg/1ml/
• z3t4 8y ago
  If you take pure functions, and "side effect free" mantra, and apply it to OOP you get a pretty good mix. For example, instead of saving a file to the file-system, you save the file to a file-system. A class/prototype can only mutate it's own object. If possible - a function should only use it's parameters and internal variables, eg. not access global/module scope.
• alkonaut 8y ago
  I think these concepts are often conflated. One thing I miss most in OOP and appreciate most when doing FP is ADT's, when I can represent Type payment = Invoice(Address) | Card(CardDetails) And then match/switch on those things, while the compiler will tell me if I did something wrong such as not handle one case. Adding a third type of payment (Cash) is as simple as adding "| Cash" to the definition - and the compiler will tell me exactly where I haven't handled cash payments. A simple smell test for a programming language is this: if describing the above takes more than the above code - your language has a wart. If you try to describe this properly in C# you'll be writing an abstract outer class and N concrete inner classes, plus boilerplate for comparisons and so on. You'll be looking at likely 50-100 lines of code where no single line of code actually shows whan what you are modeling. This is the terrible part of OO. I'm sure there are a few cases to show an FP weakness handled elegantly by OO - but I'm equally sure those cases are fewer. Also, there is nothing particularly "FP" about ADT's. They are just common in FP languages. Any OO language with a sum type and exhaustive matching can do this. But typically, such as for Java, C++ and C# they don't (yet). There are languages that support this that aren't FP (but not necessarily OO either) such as Rust and Kotlin.
  • labourcurious 8y ago
    In Java, you can use https://github.com/derive4j/derive4j https://github.com/derive4j/derive4j to achieve this.
  • rkangel 8y ago
    ADTs are common in statically typed FP languages (and others you mentioned like Rust and Kotlin). I have been working with Elixir a lot, and being dynamically typed the concept isn't appropriate. Pattern matching is the concept that they all have in common, that I miss when it isn't available. You don't have the 'exhaustiveness' check in Elixir because it's not possible in a dynamic language (dialyzer aside), but it's still a very powerful tool.
    • chriswarbo 8y ago
      I write Scheme code as if it had ADTs, e.g. (match payment [('invoice address ) (foo address )] [('card card-details) (bar card-details)]) As you say, there's no exhaustiveness check; plus the language won't guarantee that the product types are adhered to. For example, someone might give us `('invoice card-details)` and the language wouldn't complain. Racket's contract system can help with this; although it's very slow.
• samuell 8y ago
  I have recently came to like the following distinction: - Let data be relatively static, immutable, objects (just as the post suggests) - For functions which are merely read-only views of this data, implement them as methods on the class (An example would be "Volume()" on a data object representing a geometric object) - For functions that changes the original data on data objects, implement them as separate functions (can be encapsulated in asynchronous black-box processes ala flow-based programming if you like), returning new, immutable instances of the objects they operate on. This allows keeping data objects immutable, while still allowing you to gather certain frequently used calculations on the object itself, for code readability / maintainability, as long as they are read-only.
• exergy 8y ago
  A tangent here, but a place where object-orientation works better than anything else is in simulations of the real world. Thus, nothing to do with databases, and in fact it is referred to as object oriented modelling (OOM) rather than OOP. The way it works is that, let's say you are modelling a pump. The pump is made up of a motor, a shell, the fluid with its own conservation equations etc. In such cases, inheritance and aggregation are godsends that allow us to quickly compose real-life objects as aggregates of easily modified and understood sub-components. Also, once you've taken these sub components to a point where you trust them, there is no further need to spend any time thinking about them. They are there, and you trust them, and you can reuse them and combine them with confidence. More than anything, it gives us a great way to think about the modelling problem. The success of Modelica speaks to the superiority of this paradigm over things that came before it.
  • humanrebar 8y ago
    Eh. Most processes in the physical world are reciprocal and most relationships bidirectional. OOP wants you to add a method to one class. So you're either figuring out which billiard ball gets the 'collide' method call or you end up modelling very abstract concepts like CollisionPolicy and the "real world modelling" starts looking more and more like functional abstractions OnlyWithMoreNouns.
    • dtougas 8y ago
      If you are giving your ball a collide method, or creating a CollisionPolicy, then you are probably doing it wrong. Therein lies a huge part of the problem of OO design: modelling is difficult, and lots of us get it wrong. Just because you use FP or some other paradigm does not automatically mean you will get it right. I have seen poorly modelled solutions written in many different languages. I have also seen elegant solutions implemented in a variety of forms as well. I think that having some depth of experience in a language, as well as a solid grasp of the problem, and perhaps some anal retentive tendencies (i.e. an innate desire to keep things very structured and consistent), can go a long way to solving problems elegantly :-)
    • exergy 8y ago
• 0x445442 8y ago
  I think OOP is better suited when state needs to be maintained in memory over time. User interface development is one obvious use case and I think OOP really gained traction during a period when thick clients were the norm. However, when thick clients gave way to web apps (ignoring SPAs for the moment) the industry still tried to pound the square OO peg into the round backend hole. Most of that backend code is just transforming data between a database and either a browser in the case of a web app or another client in the case of web services, applying business rules along the way. I think this class of software is much better served by the FP model.
  • yogthos 8y ago
    FP works much better for UIs in my experience. Take a look at Reagent as an example http://reagent-project.github.io/ http://reagent-project.github.io/ With Reagent, you have reactive atoms containing your data and components subscribe to them. Whenever the state of the atom changes, the UI is automatically repainted. You basically end up with a classic MVC pattern where UI components dispatch events that update the sate, and observe the changes via subscriptions. The advantage over OO is that the state is easily decoupled from the UI, and you can observe the entire state of the UI via data. Since the logic lives outside the UI components, you can also do testing at event level which tends to be a lot more stable.
    • ceronman 8y ago
      I love how Reagent works and I do think it makes interactive applications simpler and easier to reason about. That said, I think FP still has one disadvantage which is performance. This is because the underlying computer is 100% imperative and there are still a lot of work to make FP patterns efficient. FP works well for interactive UIs because the number of objects that change in GUI is very small, so performance is not an issue. But take a video game, for example, then you have thousands of moving objects that are updated at 60FPS. Once you get that you notice is really hard to write the logic as a set of immutable state changes, object allocation becomes a bottleneck and then you discover that OO is more suitable, at least for now. Maybe later there will be ways to efficiently translate the FP patterns into the imperative CPU models.
• brightball 8y ago
  IMO... FP: Server Side OOP: Client Side
  • hombre_fatal 8y ago
    After working with Elm, Clojure, React, and friends, I'd say FP also wins for client/UI development. For example, CoreData in iOS has to be my least favorite approach to a data model yet. I spend a lot of time thinking "I wish this was Elm or React, it would definitely clean this up" when building iOS apps in general. Definitely feels like the state of the art has changed.
    • brightball 8y ago
      I could see that. I just see the stateful objects approach being more useful on an interface.
• gambler 8y ago
  1. What you see in Java is not OOP. It's static, late-bound class/interface oriented programming. Mostly just a set of subtly bad ideas. 2. Real OOP and FP do not operate on the same level. Functional, logic and imperative programming are about language design. OOP is about system design. C++ and Java poisoned the concept. Listen to Alan Kay. Note that he openly admits that "objects" as they were implemented in Smalltalk are too small. Good objects are probably somewhere in between Ruby/JavaScript object and ad a microservice in size/complexity. 3. You can implement an OOP system in an FP language. Elixir/Erlang are a good example. --- Side note: most of what Kay said about system design was validated many times over. If you think you know better than him simply because you use command line and functional programming, while he talks about graphical interfaces and OOP, you are missing the point, big time.
  • harimau777 8y ago
    Which category would you put Design Patterns under? I mostly do "functional" style programming but your comment makes me think maybe learning more about design patterns could improve my system designs.
    • gambler 8y ago
      If you're talking about GoF design patterns, then I think they are a waste of time. They are low-level and extremely class-oriented. This is exactly the area where FP wins over Java-like languages hands-down. And I'm saying this as primarily Java/C# developer. Hinton has a great presentation about it: http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/ What I would recommend is learning about the Smalltalk approach (not necessarily the language, but how Smalltalk environments are designed and what you can do in them). Another thing I recommend looking into is Agent-Oriented programming. Agents seem to be much closer to Kay's original vision than anything we call "object" today. Here is a really cool read: https://alumni.media.mit.edu/~mt/diss/prog-w-agents.pdf https://alumni.media.mit.edu/~mt/diss/prog-w-agents.pdf It might sounds academic, but there are tons of great design ideas there. I used some of them in HR applications, which is as "boring" and practical as programming gets.
  • 8y ago
• khasan222 8y ago
  I enjoy using a mix of the two. I find that some things are better expressed in OOP over FP, and will regularly mix them in the same code base. It lends itself to very nice code that doesn't force you to do anything but make it easier for someone who has never seen it to fix it.
• kingdomcome50 8y ago
  I find most discussions of this nature to be completely missing the point. Semantic arguments about the specific syntax required to accomplish some goal, or comparisons of which approach works better for a _single_ given use case are silly. We get it, the expression problem exists. The fact of the matter is that FP and OOP work on different levels. Higher-levels favor FP and lower-levels favor OOP. That is, coordination is best-implemented via FP and enforcing rules is best-implemented as OOP. Arbitrarily choosing a single approach ensures poor system design. For example, as many have pointed out, methods like "collide" or "attack" don't really make sense to have on a single object. This is because this method works at the level of coordination, and therefore _should_ be functional. Alternatively a method like "addDamage" method works at the domain level were it enforces rules/state change. We can easily apply the above observation to system architecture and conclude that the outer-most layers of an application (services) are best-implemented using a FP approach and the inner-most layers (domain) are best-implemented using OOP. It does not surprise me that most applications adopt FP. Because most people think procedurally and start applications with a top-down mindset, the outer-most layers (use cases) tend to be modeled first where a FP approach makes sense. This then just carries through the rest of the application.
  • AnimalMuppet 8y ago
    > It does not surprise me that most applications adopt FP. Because most people think procedurally and start applications with a top-down mindset, the outer-most layers (use cases) tend to be modeled first where a FP approach makes sense. This then just carries through the rest of the application. Did you mean "OOP" instead of "FP" here? First, I think more applications adopt OOP than adopt FP. Second, I find it hard to go from "most people think procedurally" to "therefore they wind up at FP".
    • kingdomcome50 8y ago
      I did not. Simply using objects does not mean one has adopted OOP. OOP means modeling behavior _with_ data, not _around_ data. It is something that must done be intentionally, not a product of your choice of language (although can certainly play a factor). I would suggest that most systems adopt a procedural style where objects are more or less bags of data being passed around to functions/methods. This generally fits the mental model of how people think. That is, in terms of input -> output. OOP blurs that simplicity because each unit of behavior (method) also has a surrounding context (properties) that may be affected as well. At the end of the day the difference between Object.DoSomething( data ) and DoSomething( object, data ) is just semantics (look at how python implements classes for example).
• phaedrus 8y ago
  I disagree with his conclusion which equates the database to functional programming. Relational algebra is a third paradigm on the same level as, and different from, OOP and FP. I remember seeing an article pointing out that the database is the "mutable global variable in the middle of your functional program". Also both functional programming and object oriented programming make much more use of hierarchical organization and implementation hiding than do relational databases.
  • lenticular 8y ago
    Relational algebra is essentially the same thing as logic programming, which is a separate paradigm. However, typeclasses get you a lot closer to the way normalized databases structure data than OOP does. Not that typeclasses are specifically FP, but they are currently only found in FP languages.
  • snidane 8y ago
    This is exactly where typical pure lambda-calculus based programming falls short. Lambda calculus afaik doesn't have the concept of IO, so it has to be bolted on in the programming languages as an afterthought. I believe more powerful formalism has to be used. For example pi calculus or petri nets. In both you can represent the 'global variable database' as a process sitting somewhere and you communicate with it using channels or as a message passing in general. Lambda calculus is too constraining, because everything is a deterministic function and it can't model exactly this scenario. Another use case hard to model in lambda calculus is time. Eg. run some function after N seconds. Or plain 'sleep' function. When you now look at programming languages in terms of, let's say, Petri nets, you see clearly how OOP (Alan Kay's message passing) is the part where you send messages between processes and FP is contents of a particular process. Other than that, there are two types of OOP I noticed. 1. Alan Kay message passing. Originated from people trying to implement simulations 2. OOP as modules (Java, C++), aka 'Dog implements Animal' OOP. In this paradigm people try to come up with ontologies, ie. hierarchical models of data dependencies. Instead of using actual modules, people use classes for some reason. Then you can see module-like features implemented on classes, eg. private and public modifiers of methods. 'Dog implements Animal' should be modeled as 'Module Dog depends on module Animal'
• ken 8y ago
  > And yet, we embrace objects in our applications. Is this just fashion? I think that's 90% of it, actually. In no case in my life have I seen a company starting a new project say "We're going to examine the available {programming languages, databases, operating systems, ...} and pick the one which is most appropriate to our problem". It was definitely never even considered after more than 3 lines of code have been written. Even upgrading from one version of a language to a newer version of that same language is, usually, like pulling teeth. Thinking back over the past several companies I've worked with, reasons for picking a programming language included: - $(first_dev) wanted to learn a new language - $(first_dev) didn't want to learn a new language - Company policy says we must use $(lang) (even though no other software runs on the same platform, or has anything at all in common with this new project) - $(founder) used to work for $(compiler_company) - We googled for a library to do $(task) and first one we found was for $(lang) I don't know what to call this, but it isn't engineering. My only problem with calling it fashion is that I'm afraid it would seem disrespectful to the fashion industry.