Procedural programming was never abandoned, it just doesn't have a hype machine around it. How much software is written in plain C which is neither OO nor functional?
> How much software is written in plain C which is neither OO
And I would assert that every maintainable C program is fundamentally designed in a relatively object-oriented way (functions that operated on structured, polymorphic function pointers, etc.) even if the original author wasn't particularly thinking in terms of classes or inheritance.
C programs aren't functional because C isn't functional (no inherent concept of closures), but Greenspun's tenth rule:
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" usually applies.
>> C programs aren't functional because C isn't functional (no inherent concept of closures)
You don't need closures to do functional programming.
I was recently tinkering in some C++ code and thought "this part should be able to run in parallel." It was simply doing the same operation of a list of objects. It's a complex operation involving some temporary data structures. I had to dig through several layers of functions, but I kept finding that all data was created locally. Functions that returned complex result are passed a class to fill out. It was then that I realized it was written in a functional style - or at least my limited understanding of what that means. The top level function is now run in parallel, which required no changes beneath that level.
Now I prefer that style but like TFA here, I don't think 100 percent functional is a good idea.
I think what you're illustrating there is how vague of a term OO is. If you can apply it to code that was never even intentionally written to be OO then is it that meaningful? Btw OO did not invent encapsulation and polymorphism.
And I would assert that every maintainable C program is fundamentally designed in a relatively object-oriented way (functions that operated on structured, polymorphic function pointers, etc.) even if the original author wasn't particularly thinking in terms of classes or inheritance.
That is in the eye of the beholder.
I can well believe that you would look at the code and decide that the author wrote in an OO way. I also believe that there are plenty of authors of such code who would disagree with your assessment.
I don’t think it is correct to say that those things are OO because they predate the concept and are used in many paradigms. When I think of OO I think of strict encapsulation (via private), complex inheritance, methods bound and defined in classes, single dispatch, etc.
so languages like self and javascript which, even in the modern forms, have no real classes are not oo to you?
i mean, the fact that you can use class style syntax do define object constructors in javascript and tho result is fairly coherent, seems to suggest that classes are not inherent to oo.
also, the fact that it's called “object oriented” not “classical”.
other examples of non-oo with strict encapsulation includes haskell, where if you lack the constructor, you can only use it according to the public api. it also uses single dispatch for typeclasses.
complex inheritance rare in oo - mostly only single inheritance is supported - and most oo design advocates pretty much say “don't use inheritance”. so it doesn't seem like it's intrinsic.
It is perfectly possible to use a functional style in an OO/procedural language, as John Carmack demonstrates below. You just lose the guarantees (which is a steep cost IMHO)
One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well.
For example, I have an object... what do I do with it? So I hit the '.' on my keyboard and read the list of things that the object can do.
This is why OOP is popular, it allows better tooling. If people want to move beyond OOP then they need to think about how the new style integrates with the IDE so that the programmer can hit the '.' or equivalent and get a list of useful things to do with the object in question.
This is a common idea but I'm skeptical it's that simple.
Haskell has a powerful enough type system that it can enable "hole-driven development" where you specify the type of your code and then leave a "hole" in the implementation -- anywhere in the implementation, including making the entire implementation a hole! -- and the tools can suggest what should go in the hole, leaving new holes in the code.
Then you can incrementally resolve smaller and smaller holes based on the suggestions you get, and finally you have a completely tool-written program, where you just helped disambiguate when you had to.
Haskell is weighed down with the problem that by the time I'm five pages into a "Haskell is actually easy, and let me show you how" tutorial, the average reader's eyes glaze over thanks to passages like:
"While >>= and return are the basic monadic sequencing operations, we also need some monadic primitives. A monadic primitive is simply an operation that uses the insides of the monad abstraction and taps into the `wheels and gears' that make the monad work. For example, in the IO monad, operators such as putChar are primitive since they deal with the inner workings of the IO monad. Similarly, our state monad uses two primitives: readSM and updateSM. Note that these depend on the inner structure of the monad..."
Or, possibly because when I make a post on Hacker News about how difficult it is to implement Quicksort in Haskell, the first response is a four-line Haskell implementation of Quicksort, spawning a 50-post subthread which points out that it's not actually an implementation of Quicksort, because it does not have the same performance characteristics as Quicksort, and instead has the performance characteristics of a lethargic water buffalo.
By the end of the thread, the question of whether it is possible to write a Quicksort in Haskell that has the performance characteristics of Quicksort is left as an open research question.
Instead of downvoting the parent, Haskell devotees would do well to recognize that this is a pretty good representation of the hurdle that would-be recruits to Haskell face.
There is a reason why Haskell is not popular. But I don't think the impenetrable passages about Monads are the reason behind it.
It is more about what you gain by adopting Haskell and powering through the impenetrable passages.
If it is not blazing fast runtime performance and fast speed of development and maintainable code, then Haskell is pointless. As such, if there are those kind of benefits available, there is plenty of extra brainpower available among developers to comprehend passages.
Agda literally has this "hole-driven development" as a standard feature in its IDE modes. Not only that, but when developing Agda code you get a list of every binding in scope, as well as a prompt of the type that must be provided to resolve the "hole". The expectation is that every part of developing Agda code can be expressed as a kind of "autocomplete", if desired.
Both type hole development and auto completion are enabled by static types. Haskell could theoretically benefit from all these advantages that mainstream statically typed enjoy thanks to IDEA, Visual Studio, or XCode but the Haskell community has this arrogant attitude that they are above such "pragmatic" tools and as such, never took the importance of IDE's seriously.
So when you watch a video on Haskell's awesome type hole development, the developer is often using vim and typing everything by hand. In 2020.
Except VS Code supports Haskell pretty well. And implementing IDEs is hard work, why do that when it's such a niche language that editors like VS Code suffice?
Haskell is popular in universities, fintech companies, and among the FP crowed at large. Many programmers know of it's benefits and simply avoid it because FP is very difficult for many to code in and Haskell is trying to be FP only...
Popular in which fintech companies? I don't believe this is true, but I would be happy to wrong.
Jane Street uses OCaml, but of course that's not Haskell. All the other finance firms seem to use pretty standard C/C++ because they need the low latency.
I've done Haskell contract work at multiple large Wall Street investment banks. It's not like it's their only language - these are large orgs with lots of smart people, sometimes some of them use Haskell.
> One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well.
That's just dot-syntax and modules. That has nothing to do with OOP itself. Nothing is keeping you from doing that in functional languages that support proper modules.
Well generally speaking you're just describing a search problem: I have this data, what operations can I perform on it? Hypothetically you could do something like if I type a keycode after a variable it lists functions that can be run on it. Its just a tooling thing not really a language design thing.
But their point is -- and I agree! -- that with unfashionable OO languages there’s nothing hypothetical about it, it’s completely mainstream. All the IDEs have done this for years and it works extremely well.
The poor design of that class aside, I would rather have the specific version rather than the unspecified version. If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists.
> If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists.
Non-trivial data structures are always conformed to some specification, doesn't matter if its Clojure or an OOP-language. If you receive an HTTP request over the wire you will have to check it. Once you conform it to the specification you know exactly how it looks and there's no need to jump through hoops to access the information.
But with proper static typing you don't have to check it because you already know it's correct since it's construction. It relieves a lot of mental burden for me to not even have to consider the case that it might be incorrect, as long as I'm dealing with structures internal to my program.
I have a lot of respect for Rich Hickey and I feel like he Understands something that goes straight over my head, but his appreciation for generic, shapeless maps and lists is something I just don't get.
> But with proper static typing you don't have to check it because you already know it's correct since it's construction.
Its construction is dependent on it conforming to a specific form. In this case, your statically typed data comes from a parsed string that is then conformed to a specification to ensure that is has a certain shape. In Clojure you would just do the conforming to specification part and keep the data generic.
I think the appreciation for generic data has to do with the fact the fact that it makes Clojure code very generic and facilitates a lot of functional composition.
I have a counterpoint. OOP made simple things way too complicated and that resulted in more jobs in software development. Its the sad truth. Or the happy one, depending on which side of the fence one is.
