9 ms·
> “OOP is prevalent because cheap OOP developers are readily available, while functional programmers are typically more smart, and more expensive…” The reason
by cpursley 7y ago
> “OOP is prevalent because cheap OOP developers are readily available, while functional programmers are typically more smart, and more expensive…”
The reason I prefer functional programming over OOP is that I'm just not smart enough to understand all the OOP abstractions and how to build reliable systems with it. Functional programming is just easier to grasp mentally, as it takes away a lot of the foot-guns (mutable state, inheritance, etc).
- ErikAugust 7y agoYeah, I have also found that even very good OOP programmers will take longer to implement their designs, and they are no less error-prone. Unit testing seems much trickier as well.
- gmueckl 7y agoIf unit testing is added to an OO language in such a way that it alllows you to ignore access qualifiers completely in unit tests (and only there), the whole process becomes a lot less painful. I am not a programming language expert, but I think that enkisting the help of the compiler for stubbing and mocking could potentially ease a lot of pain.
- DaiPlusPlus 7y agoC# has `InternalsVisibleTo` FWIW - though `internal` isn’t the same as `private` - but if you really want to unit-test private members you can always use reflection. An OOP purist would tell you to abstract-out your fancy private logic into a DI-injected service that can then be tested separately.
- gmueckl 7y ago> An OOP purist would tell you to abstract-out your fancy private logic into a DI-injected service that can then be tested separately. Many OOP purists don't seem to think about ways the language itself could work differently to support them better. All these guys seem to remember is their set of favorite hammers.
- DaiPlusPlus 7y agoWell, consider composition-over-inheritance, traits and mixins - all of which require language support, otherwise you get horrible developer ergonomics issues like having to repeat interface implementations over and over - or build your own domain-level implementation of traits - which just wastes people’s time.
- p1esk 7y agoI grasped the concept of OOP pretty easily. Can't say the same about FP.
- naikrovek 7y agoBecause the OOP concept doesn't map to how a computer actually operates on data, and FP does much more. It's certainly much easier in a Functional language to optimize for the CPU cache and to support concurrency and parallelism. OOP was designed for humans, and not computers; of course it is going to be easier.
- AnimalMuppet 7y agoI strongly disagree. How a computer actually operates on data is the CPU's opcodes, which: 1) have no notion of what a function is, 2) are quite happy to deal with global variables, 3) are perfectly willing to mutate data anywhere, 4) are willing to branch to arbitrary locations. That's about as far from FP as you can get.
- naikrovek 7y agoAnd OOP is closer? Are you saying CPUs are object oriented? Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. I am saying that CPUs are NOT object oriented and that functional programming is closer to how a CPU operates than OOP is, and therefore much easier for a compiler (and a compiler author) to reason about and to optimize.
- Jtsummers 7y agoQuestion: Which functional programming languages are you specifically referring to with that statement?
- AnimalMuppet 7y ago> And OOP is closer? No. > Are you saying CPUs are object oriented? No. > Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. Yes, because it was flat-out wrong. FP is not in any way closer to how a CPU operates. (I mean, the rest of your post had problems, too, but that one bit was glaringly wrong.) > I am saying that CPUs are NOT object oriented That I will agree with.
- matchagaucho 7y agoPretty much every OO language has implemented lambda (anonymous) functions in recent years. It's actually a very enjoyable coding flow to create closures in stateless objects using C# or Java.
- c3534l 7y agoHow to write good OO code: write it like it's supposed to be Haskell. Avoid state, favor composiblity, prefer static functions, treat classes like types, throw errors to enforce type safety. All the fancy OOP design patterns and SOLID stuff just enforce or implement the principles which are provided by the semantics of strongly typed functional code. It's easier to be a bad programmer in Python or Java than Haskell, but being a good Haskell or Rust programmer is no more easy or difficult than being an equally good Python or Java coder, IMHO.
- derefr 7y agoI've always been a fan of thinking of systems as strictly-delineated combinations of two components: • protocol glue (which is OOP/actor modelled) • business logic (which is best served by being strongly-typed and statically verified.) I'm a big fan of writing most of your code as libraries and "engines" in a language like Haskell or an ML (or Rust, if your algorithms are best specified on a pointer or RAM-word machine); and then taking those components and hooking them up to the outside world using an actor language like Erlang. IMHO, this uses each language for its strengths. You've given the argument for why business logic is suited to languages like Haskell, so I'll give the other half: Languages like Erlang, or Smalltalk, or other "true" OOP languages (i.e. languages where actors control not just their own state, but their own executing code) are good at reacting to arbitrary untyped messages, doing clever things after only partially parsing them, without needing a complete understanding of what they mean. This allows for components like proxies or brokers to react to metadata on RPC requests without needing to constantly be told about the typings of new messages. This also allows rolling upgrades of distributed systems that don't require a preliminary "teach the system that the new message-type exists and it should ignore it" upgrade.
- onlyrealcuzzo 7y agoI always say that it's pretty hard to write REALLY bad functional code. The same cannot be said of OOP.
- miloshadzic 7y agoIt's pretty easy to write dreadfully unmaintainable lisp.
- faichai 7y agoIs that mainly due to macros or something else? Macros is a whole other paradigm...
- mruts 7y agoI wouldn't call Lisp a functional language. Historically it's not functional, and in practice it usually isn't functional either. When I hear "functional", I usually interpret it to mean languages influenced or derived from the ML family of languages. Notable features of these languages include algebraic data types, match expressions, emphasis on monadic operations (fold, scan, map, etc), support for TCO, and a expressive static type system (though unfortunately not necessarily supported higher kinds), and a discouragement of mutations. Common Lisp doesn't really emphasize any of those things, and Scheme only a couple.
- nategri 7y ago> “OOP is prevalent because cheap OOP developers are readily available, while functional programmers are typically more smart, and more expensive…” Yuck-o. That's a physically painful amount of bias.
- overkalix 7y agoThat was embarrassing to read. I can program decently in Scala and a bit in Elixir and I'm a goddamn moron...
- mruts 7y agoHe never said functional programmers weren't morons, he just said they were "more smart."
- DaiPlusPlus 7y agoEven if it’s true (I don’t claim it is) because FP’s brick-wall learning curve is a huge filter - given that FP isn’t widely used in SE (and you don’t need to learn FP to make lots of money doing SE) - the people spending time to learn FP will be doing it for esoteric-appeal or intellectual curiosity - which can be argued is a better indicator of general intelligence - the same way that people who know and write OCaml, COBOL, Ada and Erlang today are probably very smart.
- tome 7y agoThis is basically Paul Graham's argument in "The Python Paradox". http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
- derefr 7y agoAll systems are OOP (i.e. mutable-state state machines, mutated through message-passing according to rules that are an opaque part of their own state) at some level. Systems that don't describe themselves as OOP just have one "object": the OS process. This object is still there, and still has to pass messages through IPC, sockets, disk IO, etc. (Or, if you drop the OS altogether and write a unikernel, your "objects" are [real or virtual] machines.) This isn't an argument in favor of OOP as a be-all end-all paradigm for writing all your code in, mind you; it's just an argument against thinking you can have a language that has no OOP aspects whatsoever. Maybe you can, if that language only models pure, side-effect-free computations! (eBPF could theoretically be non-OOP, I guess?)
- betenoire 7y agoAll systems are _NOT_ OOP. State, or the existence of an "object" does signify OOP any more than the existence of a function or a function call signifies FP.
- Unbeliever69 7y ago"Functional programming is just easier to grasp mentally" Disagree. Coming from a OOP background I'm still waiting for that ah ha FP moment. "as it takes away a lot of the foot-guns (mutable state, inheritance, etc)" Agree. And it is far easier to test functional code!
- madhadron 7y agoTry Ullman's wonderful 'Elements of ML Programming'. Standard ML is a pretty good place to start because it's a relatively small language with a pretty straightforward semantics, and Ullman did a really good job of getting students into the mindset.
- geggam 7y agoI dont think anyone is smart enough to grasp it all. Especially the hordes of enterprise java developers who create it.
- eli_gottlieb 7y agoFunctional programming is definitely not easier to grasp, but it does make compositionality explicit. So the downside is that a single line of code can be denser and less intuitive. The upside is that you can reason inductively over large bodies of code, treating Desired Properties for large things as following neatly from Desired Properties for small things.
- bcheung 7y agoI generally prefer FP style for most things as well, but sometimes FP can be taken too far. Trying to understand type signatures that are 3 lines long with nested class types/generics and getting your code to fit into some kind of monad transformer pipeline can get confusing very fast. For problem domains where you have a lot of state that is shared all over the place (like trying to implement a vector editing program, electronic schematic editor/simulator, or game development), I find OOP models easier to work with. Monads can be used when you have shared context, but then your code gets constrained and a bit unnatural; you have to worry about Kleisli composition, endofunctors, and plumbing things into and out of the state monad. Yuck. FP is a tool. OOP is a tool. Know their strengths and weaknesses and when to use each. Yes, you can work entirely with a single paradigm but IMO you're handicapping yourself by doing so.
- jayar95 7y ago>signatures that are 3 lines long What hath God wrought
- pjmlp 7y ago> Functional programming is just easier to grasp mentally, as it takes away a lot of the foot-guns (mutable state, inheritance, etc). I guess Lisp and Scheme derived languages aren't functional then.
- oarabbus_ 7y agoI can read and understand procedural and OOP, but I've never been able to make sense of Lisp or Haskell code. Like, not even the super simple examples which show you a side-by-side comparison.
- 6thaccount2 7y agoYea, but did you open a book on either language? I've trudged through a few Lisp books and tutorials and at least part of a Haskell book. You're right that syntax-wise they're very different than Python & Java, but the simple examples aren't hard once you learn more. Granted, I can't write even moderately advanced Haskell code, but quick-sort and some list comprehension code shown in "Learn you a Haskell" is pretty straightforward. "Real World Haskell" is also not too bad (at least the first few chapters). If you're even aware of Lisp & Haskell, you'll be able to pick them up at least at a superficial level with a little effort. Lisp is just weird due to the parentheses and the pre-fix notation, but the principles are very simple and allow you to directly manipulate the syntax tree as there is no difference between code and data. For example the simple lisp expression (+ 2 2) returns 4. What about (* 2 (+ 2 2))? The inner expression returns 4 and that is passed to the multiplication operator with 2: (* 2 (+ 2 2))###### (* 2 (4))###### (* 2 4)###### 8###### Edit: I have no idea how to format things on HN, so I out six "#" to represent a new line. Btw...David Touretsky's Common Lisp book is extremely high level and approachable. My biggest issue with many lisps is that installing and learning the tooling (Ex: Emacs) is a huge pain. I'd recommend you start with Racket as it is like Python in that it comes with a simple IDE, so you can focus on the language and not the tooling. Racket also has a lot of libraries for a niche language.
- andredz 7y ago(* 2 (+ 2 2)) (* 2 (4)) (* 2 4) 8
- 6thaccount2 7y agoThank you good soul!
- jstimpfle 7y agoThat's just bragging in disguise. "Look, I'm so smart, I can't understand how you make it so complicated".