15 ms·
Why Class?
- deleted 13y ago[deleted]
- taybin 13y agoObject-oriented in the large, functional in the small. Makes sense to me.
- straws 13y agoGary Bernhardt has a nice talk about that: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries A lot of people I know consider object-oriented design orthogonal to the programming style — that the real improvement is moving from a procedural to functional approach. Any system that grows large enough to clearly define an architecture technically is object oriented, so long as it's passing messages among stable interfaces. You want to have that functional core and imperative shell. Tell above, ask below. It's just unfortunate that a lot of "object-oriented programming" that you learn in school is really just imperative programming with interfaces ;)
- dj-wonk 13y agoRe: "Any system that grows large enough to clearly define an architecture technically is object oriented, so long as it's passing messages among stable interfaces." @straws: I'm curious, why do you think that the situation you mention above implies that such a system is 'technically' object oriented? If I'm understanding your claim, I disagree. All you need are mechanisms for: (1) function-calling or message-passing (I don't think you were trying to emphasize an extremely rigourous definition of 'message passing' were you?) (2) namespacing (3) validating a 'stable interface' There are many definitions of OO, but this is one is good enough for my point: "Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs" (from http://en.wikipedia.org/wiki/Object-oriented_programming http://en.wikipedia.org/wiki/Object-oriented_programming) You don't need object-based inheritance (e.g. Java) or prototype-based inheritance (e.g. Javascript) to build large systems in this way. For example, you can build very large systems in Erlang (passing messages too!) without any kind of OO. There are lots of examples of how functional languages can enforce interfaces without classes, including Haskell.
- gnaritas 13y agoErlang processes are basically objects passing messages to each other. They have state and behavior and communicate via message passing, they are objects.
- straws 13y agoI think we're mostly in agreement, @dj-wonk. Objects are about bundling that state and behavior, nothing more. How they're created or instantiated is secondary. It's unnecessary to create classes for functionality when it's unnecessary to create objects for functionality. Here's an eloquent article on that subject: http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/ http://me.veekun.com/blog/2013/03/03/the-controller-pattern-...
- tomphoolery 13y agoThis. I think the debate between "OO vs. FP" is such a fallacy because it's clear you can do both. I attempt to program as functionally as possible within the OO framework that I use, but I also really like extracting functionality into classes and modules when I need to. It just makes sense to do both at once.
- RyanZAG 13y agoIf you think of classes as namespaces and not objects (which is what they are half the time), it becomes a bit saner. Pragmatism makes the world work. You can still write functional code in OO. Heck if it makes you feel better, you can just make a macro to rename 'namespace' to 'class' and then you can write code like namespace Utils { function thingy() {...} } Namespaces are generally an improvement over globally defined functions as it lets you mix and match libraries without having to worry that you included the right header files, etc. Again, pragmatism.
- dsego 13y agoAgreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.
- RyanZAG 13y agoYou can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts. Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything. Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really. I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.
- hernan604 13y agoClasses do too much if you dont have Roles. When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles. If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated. Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.
- gress 13y agoNot to get into the oo vs functional debate, but generic advice about how big a class should be and how it should relate to other classes is guaranteed to be inappropriate some of the time. Classes are a tool you can use to design a solution to your particular programming problem. Sometimes the problem with call for a few large classes. Sometimes it will call for an evenly balanced network of small classes. Sometimes there will be a lot of DTOs, and sometime none. Sometimes large classes will cause maintenance problems because there is a lot of complexity confusingly jammed in one place, and other times they will be a boon because you don't have to look in lots of confusingly named files to discover what you are looking for. Criticizing a design by how well it conforms to abstract rules, rather than criticizing its fit to the actual problem will often lead to confusion. These rules of thumb are useful, but only as a way to question whether your design is a good fit - I.e. "Would it be better if this class had more behavior or less behavior? Would it be better to split this class into smaller components, or should this group of similar classes be coalesced into a single entity?"
- afshinmeh 13y ago+1, Nice to see your post man, keep it up! :)
- lightblade 13y agoI think OO and FP can coexist peacefully. You just need to pick out their good parts and discard the rest, and use a programming language that allows this. Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist. Separate behaviors out into its own module. I'd avoid calling them classes here because there will be confusion. Interactions between objects can be implemented in FP style. This is where you get to use map and reduce. I've been learning about DCI (data context interaction) recently. I can't say I've fully grasped it yet, but it did opened my mind on how to do design differently.
- weavejester 13y agoSo just use objects for type-checking? Isn't that just FP with types?
- jbooth 13y agoOO itself is just syntactical sugar for standard C structs with functions taking them as args. Substitute in "self" for an additional first argument and you've got FP with types and structs.
- weavejester 13y agoThe definition of OOP rather depends on who you ask, but I suspect Alan Kay would disagree with you there :)
- jbooth 13y agoTake a look at some OOP C code sometime. Oh, C doesn't have objects? Sorry, I meant a my_struct{} and a bunch of my_struct_op(struct, otherargs) functions. You seem to be pretty emotionally invested in FP vs any other programming paradigm. I'm more of a "lots of tools in the box" kind of guy.
- 13y ago
- hernan604 13y agoUse a better OO meta object system, ie. Moose. And then you can build a class like LEGO, literally. Because, it has Class and Roles, a class can extend another class. And a Role can be built with multiple roles. And a class can be built with multiples Roles. Your OO is outdated if it doesnt implement classes, roles, types and at least method modifiers. And your language should allow first function class to allow functional programming if you desire. Perl has all that and comes installed in any unix/linux/mac.. try in your terminal: $ perl -v Every linux/unix/mac system runs perl. So your company is probably using perl and they dont even know.
- strictfp 13y agoI think that the article uses a bad example. OO is actually really bad in db apps (DTO apps). OO shines when you are in one big continuous memory space, and don't have to worry about the data behind the objects. I see OO as a good way of abstracting the data away from the logic of your program. This abstraction works well with classical desktop apps (lots of code, one big heap, pointers are always valid), but breaks down badly when your program is about communicating data and you start to cross memory address barriers. A lot of modern apps are about data. You see a lot of networked apps, db apps and layered apps with different technologies in every layer, communicating with each other only through shared data formats. Such an app is primarily concerned with shuffling data around, and oo breaks down into a horrible mess. Each transition to a data representation requires a complete serialization of the object graph to a reasonable data representation and back again at the other side. This means that you essentially have twice the amount of work than if you would operate on the data directly as you would do with FP. Once the amount of "internal juggling" with the data exceeds a certain limit, OO might be beneficial. But for data-centric apps, forget it.
- weavejester 13y ago> I see OO as a good way of abstracting the data away from the logic of your program. Why would you want to do this?
- jbooth 13y ago"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.
- weavejester 13y agoIsn't this an argument against hiding your data structures behind an opaque object structure?
- 13y ago
- sklivvz1971 13y agoI really like Hadi's criticism of OO, and in fact I would like to hijack it and take it a few steps further, to paint what in my mind is a more realistic picture. Functional programming is only an alternative choice of paradigm. Expert programmers will use the best tool for the job and eschew the pointless search for the absolute best. Why OO? Classes exist to decouple behaviors from data. In fact, their purpose is to think in terms of cohesive sets of behaviors instead of data-driven functions. Does this apply to any possible case? No, it's a leaky abstraction. Why FP? Functions exist to decouple behavior from other behavior. In fact, their purpose is to think in terms of completely decoupled sets of behaviors instead of cohesive functions. Does this apply to any possible case? No, it's a leaky abstraction. Why AOP? Aspects exist to decouple behaviors that apply across classes. In fact, their purpose is to think in terms of orthogonal sets of behaviors instead of hierarchical sets of behaviors. Does this apply to any possible case? No, it's a leaky abstraction. Why Procedural Programming? To separate the functionality of the application in separate behaviors. In fact, the purpose of procedures is to think in terms of behaviors instead of sequences of operations. Does this apply to any possible case? No, it's a leaky abstraction. Why Declarative Programming? To express solutions in terms of goals instead of behaviors. In fact, its purpose is to think in terms of desired state, not sequences or compositions of behaviors. Does this apply to any possible case? No, it's a leaky abstraction. Why Logic Programming? To explore the logical consequences of given facts, instead of focusing on behaviors or desired outcomes. In fact, its purpose is to find new truths starting from given truths. Does this apply to any possible case? No, it's a leaky abstraction. Why spaghetti code? Wait, no that's just crap ;-)
- weavejester 13y agoThe problem with this argument is that certain abstractions are more useful than others, particularly in certain problem domains. You rarely need a language with manual memory management when designing a web application, for instance.
- zachrose 13y agoWait, isn't that exactly the same "choose the right tool for the job" point that sklivvz1971 is making?
- anaphor 13y agohttp://c2.com/cgi/wiki?ExpressionProblem http://c2.com/cgi/wiki?ExpressionProblem
- yeukhon 13y agoOne can argue that Javascript's prototype is probably the future, not the traditional class-based OOP.
- jafaku 13y agoAre you going to say why?
- dasil003 13y agoAfter nearly 20 years of Javascript there still is no consensus on how to structure object-oriented systems. This is somewhat reminiscent of lisp's failure to succeed in the marketplace because it's so flexible that no one can agree and get behind enough core ideas to build a large ecosystem. Javascript had the weight of the web behind it to force adoption, but that clearly has been in spite of the OO model not because of it. I'm not trying to hate on JS either, I think it was a bit of a small miracle what Brendan Eich pulled off under the constraints he had and I'm thankful for JS every day. However I think it's fair to say that something like Ruby's metaclass and mixin system gives you 99% of the modeling power of advanced prototypal modeling with 99% less confusion. Obviously there are ways it could be done better and more explicitly than in Javascript's typeless object world, but even then I don't see where the win is. We need better ways to manage state and mutation in mainstream languages, not more ways to compose objects.
- deleted 13y ago[deleted]
- neebz 13y agoIn one of the initial posts of the series, OP mentions that functional programming doesn't have app state. Can anyone point out more details on this? I don't know if I am understanding it correctly but one of the reasons I absolutely loved Backbone.js was that it kept state of our DOM. Is this relevant to above discussion? because state surely looks pretty beneficial.
- huhtenberg 13y ago> Why Class? To enforce an invariant but of course. Just ask Bjarne. [1] http://www.artima.com/intv/goldilocks3.html http://www.artima.com/intv/goldilocks3.html
- ufo 13y agoYou can have Abstract Data Types without classes and object orientation.
- huhtenberg 13y agoSure.
- M4N14C 13y agoAsk Bjarne Stroustrup, do the opposite of what he says. The world will thank you.
- Tomis02 13y agoM4N14C, you've been hellbanned.
- dj-wonk 13y agoThis is a nice narrative. Some people have misconceptions about what OO gives you in comparison to other paradigms. OO provides specific abstractions, which may be useful in many cases, but also may be too much. In some cases, simpler abstractions may be preferable. Less complected (baked together and inseparable) abstractions can often be found in other paradigms. For example, in Java, a person might use a class even though all they need is a namespace. In many functional languages, you can just create a namespace without the other trappings of OO. Sometimes that is just what you want. I've seen some nice slides from Clojure talks that talk about how many OO abstractions are complected (combined) versions of simpler abstractions. If anyone has seen the slides I'm talking about, please share. For example, a class is combination of a namespace and ___. Possible answers include mutable state, shared data, and so on.
- Totient 13y agoI think that was Rich Hickey's "Simple Made Easy" talk: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy I think one of his most important points is that objects are good for representing, well, actual objects. As in, you have a mouse, or screen or some little robot that you are controlling through code. And that's all they are good for. Need a way to define a bunch of static methods and avoid name collisions? - you want a namespace. Need a place to store a bunch of data about something? - you want a associative array. Need a way to call the same function on different types? - you want an interface. I'm not sure about this, but I suspect part of the problem stems from the fact that object-oriented languages (usually Java these days) are the first language that students are exposed to. Once you start thinking in OO abstractions, it takes some effort to break out of the mindset.
- jakejake 13y agoThis is a great piece and probably mirrors the process that a lot of us have gone through over the years. I know it definitely rang true for me. I would hazard to guess that functional programming or any other solution will go through the same type of evolution and we will be looking back in 10 years at how immaturely we used the technology. Then we will circle back to yet some other technology that was previously used and went out of style, with some new insights added. It seems to me that we go in a great big circle over and over again, picking up a little bit of new info each time around.
- evincarofautumn 13y agoProgress does tend to be sort of helical, doesn’t it?
- VLM 13y agoAlso applies to the eternal wheel of centralization / decentralization. Or the peculiar 3-phase of interpreted / tokenized / compiled. On a larger scale paradigms usually pick a spot along the verbosity continuum. Concise and information dense or verbose and information free? This is another eternal cycle. Some modern java looks about the same as 1960s COBOL to me.
- abalone 13y agoIt's not like one paradigm is perfect for everything. But there's one thing that the author wrote that stood out for me: writing a "utils" class for stuff he doesn't "know where it really belongs." That's one of the benefits of OOP: it forces you to think harder about where things belong, and this really helps as codebases grow. A "utils" class is often a sign that things could be better organized.
- sagarm 13y agoI couldn't disagree more that thinking harder about where things belong is a benefit of OOP: it's an entirely unnecessary tax caused by the requirement to wrap every symbol in a class. Another aspect of this is unnecessary effort expended on deciding if A.operateson(B) or B.operateson(A). Sometimes, you want to Operate(A, B). If your language doesn't allow that, you end up with operator.Operate(A, B). Classes are not always the best organizational tool.
- btilly 13y agoThere is a fundamental point here that really bears thinking about. Software design has as a fundamental problem being able to express yourself in a way that is clear and remains clear as things change. Basic principles of good software design, like reducing cohesion, remain good principles no matter what "paradigm" you think you're using. When you change paradigms, be aware that the basic principles remain the same no matter what label you give them. And since design is all about tradeoffs, if you are going to have to violate a principle, you might as well do it in the clearest and most straightforward way possible. Let me give an example. A singleton is bad for all of the reasons that a global variable is bad. If you need one, I prefer to make it a global variable simply because that is honest about what design principle has been broken. (Unless I want to make it lazy - then it is easier to write with a singleton!) So learn the principles. Figure out what they look like and are called in your paradigm. Get on with life and solve real problems. Let me give a concrete example. I learned more about good OO design from the first edition of Code Complete than any other book that I ever read. Even though it was entirely about procedural programming. Because the principles that it discussed, from how to name functions to the value of abstract data types to information hiding, all apply directly to OO. And to functional programming. And to aspect oriented programming. They are truly universal. Learn the principles, they are more important than the labels.
- robrenaud 13y agoMostly agreed, except that cohesion is good, but coupling is bad. http://en.wikipedia.org/wiki/Cohesion_(computer_science) http://en.wikipedia.org/wiki/Cohesion_(computer_science) http://en.wikipedia.org/wiki/Coupling_(computer_science) http://en.wikipedia.org/wiki/Coupling_(computer_science)
- btilly 13y agoSlip up, yes. You're right, I said the wrong one. But what's important is not the label, but the principle. :-)
- deleted 13y ago[deleted]
- 13y ago
- hawkharris 13y agoWill someone give me a few concrete, practical examples of using functional programming in JavaScript? I'm interested in this concept, but I'm not sure how to go about applying it to my own work as a front-end web developer. Most of the resources online are theoretical.
- straws 13y agoEveryone using jQuery is benefitting from functional programming. Querying, traversing, and filtering are based on `each` and `map`. It turns what was formerly looping and saving values as temporary/instance variables into declarative, collection-based compositions of functions. Beyond that, Michael Fogus — big in the Clojure + Clojurescript community — has Functional Javascript which explores functional concepts using Underscore: http://www.amazon.com/Functional-JavaScript-Introducing-Programming-Underscore-js/dp/1449360726/ http://www.amazon.com/Functional-JavaScript-Introducing-Prog... Marijn Haverbeke — a big Lisp hacker and the creator of Codemirror — has a nice chapter in (the free!) Eloquent Javascript as well: http://eloquentjavascript.net/chapter6.html http://eloquentjavascript.net/chapter6.html You should also check out how Javascript supports functional programming in languages that compile to Javascript such as LiveScript or Elm. http://livescript.net/ http://livescript.net/ http://elm-lang.org/ http://elm-lang.org/
- dsego 13y agoCheck this out :) Christian Johansen - Pure, functional JavaScript http://vimeo.com/43382919 http://vimeo.com/43382919
- Jormundir 13y agoI think of learning OOP much like learning Chess. In Chess it's very easy to learn how the pieces move and start playing, but becoming a master is incredibly difficult, requiring years and years of deliberate practice. When I see people complaining about OOP, it makes me think of two beginners playing Chess, thinking victory is a random outcome. The dialogue of the article is entirely about coupling, and in OOP figuring out how to make a loosely coupled system is what separates the grand masters from the beginners. Designing a loosely coupled system is incredibly hard and requires years of deliberate practice to master. So when someone who's a beginner or not very good at OO design claims OO isn't a valuable paradigm, I don't listen. Bad OO can be less valuable than no OO, just like anything else, and just like anything else, that doesn't make the whole paradigm bad. I've explored functional programming in a couple of college courses now, and find it very intriguing. When it's time to go a make a system, however, I find it difficult to boil down functional principles into the system I want. This is a complaint in the same vein as the OO complaints. Functional programming is incredibly impressive when designing a behavior, but what separates the masters from the beginners seems to be when it's time to model an entire system. This is the current separation in my mind: OO is designed and really good for modeling a complex system that involves lots of mutation, and functional programming is really good for modeling and separating behavior within a system. I don't think we have grounds to say one is better than the other yet. Both OO and Functional have their niches where they're amazingly effective, and both have a giant gray area where it's difficult to mold the pure paradigm onto a solution. I think the best solution so far is a mixture of the two, such as we see in Scala. Though, a mixture too has its own set of drawbacks. Mainly what seems to be an explosion of language complexity and a giant need for design conventions and limitations when there are so many possible routes to a solution. The best of the current climate is a mixture of the two, with a framework that clearly defines and separates where and when to use one paradigm over the other, so you aren't bogged down with the additional complexity.
- deleted 13y ago[deleted]
- goggles99 13y agoIMO, most critics of FP or OOP do so because they lack a full understanding of one or the other. Either paradigm can be applied incorrectly and cause plenty of problems. Both have their merits and strong points. Each fits a different type of project better than the other. Also different people tend to grasp or appreciate one or the other better naturally depending on how their brains are wired. More logical, abstract thinkers tend toward OOP while more right brained people tend toward FP. There is nothing wrong with this. There is also nothing wrong with learning the benefits of the "other side". If fact it is quite beneficial. some language designers see and fully appreciate the benefits of both. They start putting class synonymous structures in FP languages or FP functionality in OOP languages. This is the future of the mainstream (Ex: EcmaScript 6 has classes/types, C# has Linq, closures, lambdas ETC).
- platz 13y agoWhy do you say right brained people tend toward FP? To me, FP has many abstractions that must be learned as well.
- callmecosmas 13y agoHaskell seems pretty left brained to me!
- chongli 13y agoRight/left brain dominance is a myth! http://www.theguardian.com/commentisfree/2013/nov/16/left-right-brain-distinction-myth http://www.theguardian.com/commentisfree/2013/nov/16/left-ri...
- V-2 13y agoI don't see FP as less abstract than OOP, either.
- mortyseinfeld 13y agoEver since I started playing around with Java (or even earlier with C++) having data co-mingled with functions has never felt right to me. It just never seemed very extensible to me, especially in a language like Java. Even in C# where you have extension methods, they are second class citizens. But also the old question of where to put a method seems like unecessary mental overhead for solving a problem. Use modules and just pass things in. You could probably even put some syntactic sugar in the language so that you could use the "object".method notation on the first argument passed in if you really wanted to. So someone give me clojure with optional typing, a Python-like syntax, and get off my lawn!
- jamii 13y ago> clojure with optional typing, a Python-like syntax http://julialang.org/ http://julialang.org/
- rcirka 13y agoI do agree the "noun" vs "verb" analogy when classes are taught are horrible..actually the way classes are taught in general are just confusing. Ultimately, classes are about code organization and reuse. Done properly, it leads to a well maintained program. Functional programming...it still needs to be organized somehow, whether you put them in classes or namespaces, the last thing you want is spaghetti code. Now depending in the type of programming, you may need to preserve state, which can be quite challenging in a purely functional environment.
- DanWaterworth 13y agoNow depending in the type of programming, you may need to preserve state, which can be quite challenging in a purely functional environment. What makes you say that?
- davidkhess 13y agoI've found the most critical difference between OO and FP to be state. Objects are stateful from the moment they are created until they are destroyed. FP is remarkable for its general lack of side-effects - i.e. computations do not normally affect shared state. I believe this distinction is a critical one because an application with a lot of shared state is more difficult to scale than one without. As another poster pointed out, in a shared addressed space such as a desktop app, this isn't a concern. But if you want to scale an application across multiple address spaces, communicating and synchronizing the state of objects between these spaces tends to be difficult. So, my tendency is: Small and shared address space? Tend to use OO patterns and implementations. Big and distributed address space? Tend to use FP patterns and implementations. Note, I don't consider OO vs. FP a language choice – I consider it a programming paradigm choice.
- fauigerzigerk 13y agoThe problem is that whether or not we have shared mutable state on a logical level is not for us to choose. It's ultimately a property of the task at hand. Pushing shared state onto the database doesn't make it go away. Workarounds like MapReduce or monads only help us defer the moment of truth. If shared mutable state is what users ultimately expect to see, these approaches are merely simulations of shared mutable state that exploit a time gap in users' perception. That gap is very brittle. Nightly batch windows become too short. Users expect real time updates leading to major redesigns of entire systems, like Google dropping MapReduce for their search index. But I think your point about state being the major difference between OO and FP is absolutely true. In OO systems, statefulness is the default everywhere. Nothing is formally known about state in OO system and that is a bad thing. We need state to be explicit and formally specified.
- naiquevin 13y agoI can somewhat relate to the conversations in the article. While I admit that I don't think I used OOP correctly, since I started using more functions instead of classes (in Python, my primary language), I observed that it has been more convenient to reuse and refactor existing code. Another observation is that it's far easier to read someone else's code if there is no mutation. For eg. I have enrolled for the proglang course[1] on coursera and only yesterday I completed this weeks homework which involves enhancing an already written game of Tetris in Ruby. Major part of the assignment was about reading and understanding the provided code that uses OOP and makes heavy use of mutation. It was quite difficult to understand what one method does without having a picture of the current state of the object, specially with side effecting methods that call other side effecting methods. A few times I had to add print statements here and there to actually understand which one is being when and how many times. While I could score full marks in the end, I am still not confident about completely understanding the code and have a feeling that if I ever need to work with it again, the amount of time it will take to load up everything again into my mind's memory will be equal to what it took for the first time. Of course, one could only make a true comparison by studying an implementation of Tetris written in FP style. But from my experience with reading and writing code in Erlang (for production) and Racket, Clojure (as hobby) I find it relatively easier to study functional code written by others. [1]: https://www.coursera.org/course/proglang https://www.coursera.org/course/proglang
- zamalek 13y ago> Don’t be silly Jake. Where else are you going to put functions if you don’t have classes? I'm seeing where this is going: GoLang.
- Quarrelsome 13y ago:D. Why is anyone even considering FP vs OO programming a choice? I've used functional patterns within OO before and I'm sure the opposite is possible. Both have merit depending on the skill-set and staff available to you, scale of project and existing infrastructure. I was however very disappointed when the author bundled interfaces into the mix as if it was the same as the rest of it. The interface enables you to support many different types of behaviour and enables you to structure your libraries in different ways. It's a different aspect from just classes themselves. Genuinely I don't think shit like this is healthy. Smacks of religion.
- kul_ 13y ago'Don’t be silly Jake. Where else are you going to put functions if you don’t have classes?' The core argument is more of philosophical in nature in terms of paradigms, because from functional programming view a function just acts on a data transforming it to other form. But in pure OO world (like Java) one can not dare to think beyond objects so for them it has to be in a object.
- sholanozie 13y agoI might be a little late, but does anyone have any examples of simple CRUD web applications written in a functional language? There seems to be a lot of meta discussion about the suitability of functional programming for the web, but not very many concrete examples. Thanks!
- deleted 13y ago[deleted]