I would argue that there are very definitely cases where operator overloading can make code more clear: Specifically when you are working with some custom data type for which different mathematical operations are well defined.
I would argue that there are very definitely cases where operator overloading can make code more clear: Specifically when you are working with some custom data type for which different mathematical operations are well defined.
This makes sense to me, thanks! I primarily use Python, C++ and some Fortran, so my typical programs / libraries aren’t really “pure” OOP in that sense.
What I write is mostly various mathematical models, so as a rule of thumb, I’ll write a class to represent some model, which holds the model parameters and methods to operate on them. If I write generic functions (root solver, integration algorithm, etc.) those won’t be classes, because why would they be?
It sounds to me like the issue here arises more from an “everything is a nail” type of problem than anything else.
Oh, thanks then! I’ve heard people shred on OOP regularly, saying that it’s full of foot-canons, and while I’ve never understood where they’re coming from, I definitely agree that there are tasks that are best solved with a functional approach.
Can someone please enlighten me on what makes inheritance, polymorphism, an operator overloading so bad? I use the all regularly, and have yet to experience the foot cannons I have heard so much about.
I was joking, and definitely agree with you. I don’t think I’ve used eval
since my first programming course in uni.
Edit: Except for monkey hacks for laughs of course.
For Python I think there’s an actual point though: A lot of Python projects are user friendly wrappers for pre-compiled high-performance code. It makes sense to call something “py” to signal what the library is.
That will give you an extremely clear error when you run the code. Also, any IDE worth its salt should be able to fix that for you.
Even the error message you get from C++ for missing a semicolon is harder to understand and fix than this.
I have to be honest: I dont see the problem of including the entire signature at the top of the doc, and the listing the params below. If I know the class/function, a quick look at the signature is often all I need, so I find it convenient that it’s at the top of the doc. If it’s a class/function I’m not familiar with, I just scroll to the bullet points.
I agree on the bit about whitespace in signatures though. Luckily Python allows me to use as many lines as I want within a parentheses.
I believe eval
would like a word with you…
Yes, typing <p> in HTML is like pressing enter in word, but that doesn’t make it a programming language, it makes it a markup language.
A markup language is also what you can use to format comments here: You use a specific syntax to indicate how you want things formatted.
The separation from a programming language is that a programming language can be used to implement logic, like saying: In the following paragraph, a word should be bold if it contains the letter “A”. That cannot be done with a markup language.</p>
A markup language (which is what HTML is) is like an advanced text container. When you write a post or comment here, you can use specific syntax to indicate the size of the text, a hyperlink, a quote, etc. HTML is that. It doesn’t “do” anything, you’re just writing in what you want it to display, and that is displayed.
A programming language lets you somehow “do” something. Instead of declaring explicitly “write this text in bold” a programming language can be used to process all the text in an arbitrary document, and change the word “aeroplane” to bold whenever it turns up. That is: The output from the code isn’t just a rendering of what is explicitly written there, which is what a markup language gives you.
Aaaaand you’ve now reinvented punch cards for Brainfuck in mspaint. How do you feel about yourself?
People not getting this… computers are inherently binary (until quantum computers become truly viable). That’s the joke.
I believe it does “one pass” when it loads the code into ram, because syntax errors can be caught before anything runs. But I think the actual interpretation happens pretty much one line at a time :)
Not even “not so bad”, I would say that as a scripting language it’s fantastic. If I’m writing any actually complex code, then static typing is much easier to work with, but if you want to hack together some stuff, python is great.
It also interfaces extremely easily with C++ through pybind11, so for most of what I do, I end up writing the major code base in C++ and a lightweight wrapper in Python, because then you don’t have to think about anything when using the lib, just hack away in dynamically typed Python, and let your compiled C++ do the heavy lifting.
That’s a compiled language, an interpreted language is translated to assembly at runtime, in pythons case: pretty much one line at a time.
Disclaimer: To the best of my knowledge, please correct me where I’m wrong.
I use a GUI (GitKraken) to easily visualise the different branches I’m working on, the state of my local vs. the remote etc. I sometimes use the gui to resolve merge conflicts. 99 % of my gut usage is command line based.
GUI’s definitely have a space, but that space is specifically doing the thing the command line is bad at: Visualising stuff.
Boy do I have news for you…
Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.
Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…