OOP and functional programming
Pages: 12
Today I have read an interesting article about the way they want to teach development in school. Some would like to forget OOP in order to come back for a simple functional programming... I think that it's a bad thing - both of these paradigms are useful helping to increase the creation process. I start this new thread just to get your point of view ++
This is an article in French language, but I guess that there is the same idea all around the world. There is a video in English in the middle of this page :
https://programmation.developpez.com/actu/338193/Quels-sont-les-paradigmes-de-programmation-qui-mobilisent-le-plus-d-impact-sur-vous-en-tant-qu-ingenieur-du-genie-logiciel-Pour-quelles-raisons/
Another one but older :
https://programmation.developpez.com/actu/270947/Est-ce-une-grosse-erreur-de-considerer-la-POO-comme-standard-de-l-industrie-pour-l-organisation-des-bases-de-code/
https://programmation.developpez.com/actu/338193/Quels-sont-les-paradigmes-de-programmation-qui-mobilisent-le-plus-d-impact-sur-vous-en-tant-qu-ingenieur-du-genie-logiciel-Pour-quelles-raisons/
Another one but older :
https://programmation.developpez.com/actu/270947/Est-ce-une-grosse-erreur-de-considerer-la-POO-comme-standard-de-l-industrie-pour-l-organisation-des-bases-de-code/
Last edited on
IMHO you want both. Non OOP languages and needs still exist, but OOP is critical.
It only takes 1 semester to get a solid grounding in functional programming. This gives you a decent background in making class methods in c++ and its red headed stepchildren like java/c#/javascript/etc which dominate most schools now.
OOP is taught without good explains at so many places now. The weird words used barely make sense in english, the syntax is given 'this is how it is' with no understanding of why it is that way, and it quickly overwhelms the kids that didn't get into it on their own years before. Couple that to the lazy autograde/turnin crap being used at many places and you have a complete failure to teach... they give you an assignment with all this weird syntax /jargon & a web site to submit, you do the work and it kicks it back with confusing error messages and tells you its wrong but not really why... I dont know if I could even do it today if I went back in time to 18 year old me and started now. I managed to work with it recently to assist someone, but I know a lot more than any student and it was still a rough road and all I was doing was navigating the auto website part, very little coding assistance.
It only takes 1 semester to get a solid grounding in functional programming. This gives you a decent background in making class methods in c++ and its red headed stepchildren like java/c#/javascript/etc which dominate most schools now.
OOP is taught without good explains at so many places now. The weird words used barely make sense in english, the syntax is given 'this is how it is' with no understanding of why it is that way, and it quickly overwhelms the kids that didn't get into it on their own years before. Couple that to the lazy autograde/turnin crap being used at many places and you have a complete failure to teach... they give you an assignment with all this weird syntax /jargon & a web site to submit, you do the work and it kicks it back with confusing error messages and tells you its wrong but not really why... I dont know if I could even do it today if I went back in time to 18 year old me and started now. I managed to work with it recently to assist someone, but I know a lot more than any student and it was still a rough road and all I was doing was navigating the auto website part, very little coding assistance.
Yeah, most modern languages are coming around to the multi-paradigm paradigm, because people have realized that different tasks calls for different tools. Languages that are deliberately focused on specific paradigms usually end up feeling annoying to use.
That said, if I could only have one, I'd keep OOP over functional. A lot of common functional idioms are easy enough to express using objects, but the opposite is not necessarily true.
That said, if I could only have one, I'd keep OOP over functional. A lot of common functional idioms are easy enough to express using objects, but the opposite is not necessarily true.
C++ isn't a strictly OOP language, it is multi-pardigm that includes aspects of functional programming.
The often repeated declaration that C++ is strictly OOP is as nonsensical as the idea to understand C++ requires teaching C first.
Both are myths according to Bjarne Stroustrup:
https://isocpp.org/blog/2014/12/myths-1
There are three other myths debunked as well:
https://isocpp.org/blog/2014/12/myths-2
https://isocpp.org/blog/2014/12/myths-3
Overview of the myths:
https://isocpp.org/blog/2014/12/five-popular-myths-about-c-bjarne-stroustrup
The often repeated declaration that C++ is strictly OOP is as nonsensical as the idea to understand C++ requires teaching C first.
Both are myths according to Bjarne Stroustrup:
https://isocpp.org/blog/2014/12/myths-1
There are three other myths debunked as well:
https://isocpp.org/blog/2014/12/myths-2
https://isocpp.org/blog/2014/12/myths-3
Overview of the myths:
https://isocpp.org/blog/2014/12/five-popular-myths-about-c-bjarne-stroustrup
Multi-paradigm is the key. I understand and admit functional programming as a way to code something relevant quickly - a proof of concept which can be optimized using the OOP paradigm. The main problem has been exposed by @jonnin when he said "OOP is taught without good explanations at so many places now". I saw too many bad examples with bank accounts, student systems and other stuff. I have understood static/virtual functions and polymorphism creating my own codes - nothing else matters. Thanks for this interesting thread and its conversation ++
| a proof of concept which can be optimized using the OOP paradigm |
What does that "optimization" yield for you?
Will it make code more efficient?
Will it make code easier to maintain?
I totally agree that OPP (and C++) are more often than not atrociously taught, I've said that here in the fora quite often.
The problem devolves to a lot of those making and setting the curricula are not people with a lot of experience in coding C++. They might be (barely) adequate C coders, of a C that is years and decades out of date. And a lot of the instructors fall into the same category as well. Or some other language like Java and they think C++ and Java are equivalent. PFFFFFFFFFFFFFFFFFFFFFFFFFT!
A lot of the material available for self-teaching, books and online videos, especially the videos, are just plain bad. My programming library is chock-a-block full of not-good tomes.
Another consideration is even recently published books are notoriously outdated by the time they see print.
One book I've found that teaches C++20 quite well, published in 2020, up front mentions there are parts of the C++20 stdlib that at the time of publication not one compiler was able to compile the code.
Another book published earlier has a cover blurb that it covers C++14 & C++17. Well, other than a couple of paragraphs about what C++14/C++17 added to the toolbox with NO example code the book reads as if it were written to target C++11 only.
I've glanced at a later edition of the same book that blurbs it covers C++20. No, it doesn't.
Having up-to-date compilers is also a "must." Visual Studio 6 was horrible in allowing things that violated even the C++ standard at the time.
Learn C++, https://www.learncpp.com/, is one of the better online resources for C++, and it is free. Not comprehensive, but it does teach the basics and does it well.
12+ "chapters" before the site gets into the nitty-gritty details of OOP, though from the start it shows examples of using objects (objects are part of OOP, duh) from the C++ stdlib.
Formal classroom instruction setups could learn from the approach there. C++ is a huge "critter", trying to teach it all at once is folly. Learning C++ isn't a single semester situation.
C++11 transformed the language a lot. C++20 is almost as radical a change as well.
Going backwards to the 1980's is a stupid idea, and a disservice to students who need to learn how to code for the 21st Century.
The problem devolves to a lot of those making and setting the curricula are not people with a lot of experience in coding C++. They might be (barely) adequate C coders, of a C that is years and decades out of date. And a lot of the instructors fall into the same category as well. Or some other language like Java and they think C++ and Java are equivalent. PFFFFFFFFFFFFFFFFFFFFFFFFFT!
A lot of the material available for self-teaching, books and online videos, especially the videos, are just plain bad. My programming library is chock-a-block full of not-good tomes.
Another consideration is even recently published books are notoriously outdated by the time they see print.
One book I've found that teaches C++20 quite well, published in 2020, up front mentions there are parts of the C++20 stdlib that at the time of publication not one compiler was able to compile the code.
Another book published earlier has a cover blurb that it covers C++14 & C++17. Well, other than a couple of paragraphs about what C++14/C++17 added to the toolbox with NO example code the book reads as if it were written to target C++11 only.
I've glanced at a later edition of the same book that blurbs it covers C++20. No, it doesn't.
Having up-to-date compilers is also a "must." Visual Studio 6 was horrible in allowing things that violated even the C++ standard at the time.
Learn C++, https://www.learncpp.com/, is one of the better online resources for C++, and it is free. Not comprehensive, but it does teach the basics and does it well.
12+ "chapters" before the site gets into the nitty-gritty details of OOP, though from the start it shows examples of using objects (objects are part of OOP, duh) from the C++ stdlib.
Formal classroom instruction setups could learn from the approach there. C++ is a huge "critter", trying to teach it all at once is folly. Learning C++ isn't a single semester situation.
C++11 transformed the language a lot. C++20 is almost as radical a change as well.
Going backwards to the 1980's is a stupid idea, and a disservice to students who need to learn how to code for the 21st Century.
This is an interesting question - and I give you my point of view :)
(for me) An optimized code is a code which I can read easily, taking some parts when I need something more or less similar, reaching some good skill according to standards which better devs than me take for clever and relevant codes...
I don't talk about optimal speed or CPU cycles... no!
There are so many ways to code a process that there is always the possibility to argue "that it could be better, changing/adding this part with ... bla bla bla". I think that a dev has to go further than the simple "ok it works as expected - it's enough", but really sometimes I don't understand some punctilious arguments ++
(for me) An optimized code is a code which I can read easily, taking some parts when I need something more or less similar, reaching some good skill according to standards which better devs than me take for clever and relevant codes...
I don't talk about optimal speed or CPU cycles... no!
There are so many ways to code a process that there is always the possibility to argue "that it could be better, changing/adding this part with ... bla bla bla". I think that a dev has to go further than the simple "ok it works as expected - it's enough", but really sometimes I don't understand some punctilious arguments ++
Last edited on
Is everybody talking about the same things?
I thought that
- "procedural" (e.g. C)
- "object-oriented" (e.g. Java)
- "functional" (e.g. Haskell)
were distinct paradigms?
Some of the answers seem to be using "functional" where I would use "procedural". Which is it?
I thought that
- "procedural" (e.g. C)
- "object-oriented" (e.g. Java)
- "functional" (e.g. Haskell)
were distinct paradigms?
Some of the answers seem to be using "functional" where I would use "procedural". Which is it?
Probably carelessness -- I may have said procedural over functional. I think of c++ as supporting functional programming, then: the ability to write subroutines that are not part of objects and loosely resemble math's y = f(x) notation.
Granted it could be {x,y,z...} = f(a,b,c...) or even worse f can, and often does, modify the inputs as well as creating an output (eg a bool pass/fail result but the data is in the reference parameters passed back is a common theme), so the math notation idea breaks down quickly.
However you want to slice it, I feel that loose functions are critical things to support. Sometimes, its simple math, like a high performance integer power function or a string parser that is not specific to an object (validation of numbers coming in as text, for example). Other times its more specific, foo(object_type_a, object_type_b) where the two things have no awareness of each other and never should outside of your specific need.
procedural programming... I think you would need a data structure/wrapper, possibly a finite state machine of some flavor, to do that in c++ to mirror such a language? Its doable, and probably not to difficult, but its not directly supported.
Granted it could be {x,y,z...} = f(a,b,c...) or even worse f can, and often does, modify the inputs as well as creating an output (eg a bool pass/fail result but the data is in the reference parameters passed back is a common theme), so the math notation idea breaks down quickly.
However you want to slice it, I feel that loose functions are critical things to support. Sometimes, its simple math, like a high performance integer power function or a string parser that is not specific to an object (validation of numbers coming in as text, for example). Other times its more specific, foo(object_type_a, object_type_b) where the two things have no awareness of each other and never should outside of your specific need.
procedural programming... I think you would need a data structure/wrapper, possibly a finite state machine of some flavor, to do that in c++ to mirror such a language? Its doable, and probably not to difficult, but its not directly supported.
Last edited on
| Some of the answers seem to be using "functional" where I would use "procedural". Which is it? |
Of course there is plenty of overlap and so I think the words can be somewhat subjective.
C++ provides the tools to write procedural, object-oriented and functional program styles. How you use the available tools...
I've always thought that naming stuff like this was just stupid. Who really thinks, "Hmm, this looks like a job for OOP!"? Even an OOP approach can be designed in a functional programming way.
Any language that forces you one way or another is not worth learning. And, like Helios, I'd take OOP over functional any day if forced to choose.
The biggest issue I've seen is that OOP styled languages are not really stopping you from being a functional programmer, but functional programming languages are stopping you from OOP.
I had to use Lisp for a while, what an awful language. Pretentious and stupid. I hated starting with it, I kinda got use to it, then I realized I hated it even more.
Any language that forces you one way or another is not worth learning. And, like Helios, I'd take OOP over functional any day if forced to choose.
The biggest issue I've seen is that OOP styled languages are not really stopping you from being a functional programmer, but functional programming languages are stopping you from OOP.
I had to use Lisp for a while, what an awful language. Pretentious and stupid. I hated starting with it, I kinda got use to it, then I realized I hated it even more.
Lisp is really a child of its time. It was designed that way to make the compiler as simple as possible. So in exchange, you have to write the AST yourself. The type system is also very rudimentary, again because computers were too slow and memory-bound for something much more sophisticated, so if you want type checks you have to tag your objects appropriately and manually check the tags on the parameters you receive.
Last edited on
We were taught Lisp in our 3rd year degree course for 1 semester without access to a Lisp system - so we couldn't actually do any real Lisp programming! So it was all book work with pen/paper exercises that were marked by the lecturer. Ahhhh...
We also had Snobol for 1 semester again without access to a Snobol system. The other semester was for Algol68. We did have access to a batch Algol68 compiler but we were each limited to a maximum number of 'runs' - I think it was 10. I never had neither Lisp nor Snobol programs actually execute on a computer...
We also had Snobol for 1 semester again without access to a Snobol system. The other semester was for Algol68. We did have access to a batch Algol68 compiler but we were each limited to a maximum number of 'runs' - I think it was 10. I never had neither Lisp nor Snobol programs actually execute on a computer...
Man. They say languages never die. That may be true for some, but others just completely slip out of the collective consciousness. This is the first time I've heard anything about Snobol in ages, and it's about never actually having programmed anything in it.
EDIT: Forgot the "in ages". :P
EDIT: Forgot the "in ages". :P
Last edited on
| but others just completely slip out of the collective consciousness |
So hands up all those who remember CESIL ?
| The biggest issue I've seen is that OOP styled languages are not really stopping you from being a functional programmer, but functional programming languages are stopping you from OOP. |
Yes, this is because OOP languages require a layer of functional so you can attach methods to your objects, but functional does not have to support OOP to get its job done. Functional works better with user defined types, like a C struct, that can at least hold a few loosely associated variables in one thing, but even that isn't necessary for it to work.
Ive made my peace with OOP over the years. I still think there is a lot of hype and militant 'do it this way or bust' in the field that could use a step back and re-evaluation. So many simple things are made so overly complicated with bad inheritance, bad templates, etc. Its like the discipline has forgotten the KISS design pattern, which was all the rage when I was a youngling.
I remember some of the old languages that you guys mention, but like you, we didn't have systems for them so I never learned many of them. I had a fairly normal 80s progression sequence of self apple 2e basic -> self taught pascal and later formal pascal -> C/C++ and branched out from there only as jobs required it. Most of what I learned after C++ has been a step backwards, though javascript has my seal of approval, and C# I only hate because it has a stoopid name, I can admit its pretty good after that.
Last edited on
Pages: 12