A question for OOP experts. - page 15

 
Alexey Navoykov:
So I don't see the point of contrasting your "kung fu" specifically with the OOP.

he's serious!

Tag Kon ow:
I'm just about to patent my concept. There are investors. So, it's serious.

last night I read the sleepwalking thread.... for some reason I imagined a long list of Windows developers - like in Star Wars credits!

and at the end of the list - in big letters ReTeg Konow !


@Peter Konow can you do a text sprite like this?)
 
Alexey Navoykov:
You remember everything in the project you're working on at the moment. What about past codes? Do you remember just as thoroughly what you wrote a year ago? Where things have changed, etc. Now the task is to tweak or correct your old code.

And none of this has anything to do with OOP. If your code is built on public access to global variables, it is not acceptable in any paradigm, neither in procedural, nor in OOP, let alone in functional. Therefore, I do not see any sense to contrast your "kung fu" with OOP.

Everything rests on Peter's phenomenal memory.

And I agree, if you remember all variables that are used in your whole project, when and where they are modified, easily find places of incorrect modification - then this very OOP becomes meaningless indeed. Peter, in fact, works at "assembler level". Whatever OOP-hacks and design patterns you come up with, in the end any data accesses are ordinary memory addresses, and within the address space allocated to the process, all memory addresses are fully accessible. The processor itself knows nothing about encapsulation.

There, and that's how Peter operates. There was a time when I was into assembler myself.

The only question is how it manages to compete with the processor in terms of memory capability.

 
Georgiy Merts:

It's all down to Peter's phenomenal memory

...

The only question is how he manages to compete with the processor in terms of memory capacity.

So, what is the phenomenon when we are talking about one and the same project he is working on all the time. Naturally, any programmer will have it all in his head all the time.
If he could clearly remember the code after some time, it would be a different story.
 
Alexey Navoykov:
So what is the phenom if we are talking about the same project he is working on all the time. Naturally, any programmer will have it all in his head all the time.
If he could clearly remember the code after a while, then another conversation.

Well, then, I'm not just anyone. I, too, mostly work on the same project, however, I only remember the basic gist. Such details as what and from what procedure is modified - I see only at the moment of direct development. And then, if I come back to this site I spend a lot of time trying to understand why this is so and not otherwise. As a result, I'm a supporter of cutting off all rights, so that ideally in any place of the program you have access only to what you're supposed to do in that place.

 
Alexey Navoykov:
You remember everything in the project you're working on at the moment. What about past codes? Do you remember as thoroughly what you wrote a year ago? Where things have changed, etc. Now the task is to tweak or correct your old code.

And none of this has anything to do with OOP. If your code is built on public access to global variables, this is not acceptable in any paradigm, neither in procedural, nor in OOP, let alone in functional. Therefore, I do not see any sense to contrast your "kung fu" with OOP.
Yes, I remember and understand old code very quickly. The project is so big that some parts haven't been changed for months or even years and when the time comes to improve something (e.g. ancient list) I go through all the details in a short time, refreshing my memory of how it works, without comments, which are almost non-existent in the source code. I remember looking at the bare code. And for some reason it seems to me that everyone can do that.
 

Alexey Navoykov:

...

And none of this has anything to do with OOP. If your code is built on public access to global variables, it is not acceptable in any paradigm, neither in procedural, nor in OOP, let alone in functional. Therefore, I do not see any sense to contrast your "kung fu" with OOP.

No, kung fu here is exactly OOP. A lot of moves and techniques, among which in a fight 10% of the useful. But what beautiful styles! And dragon, and monkey, and flamingo and toad... I have a specific sambo. You chop and you get the result.

 
Реter Konow:

No, it is OOP that is kung fu here. Lots of moves and tricks, among which 10% will come in handy in a fight. But what beautiful styles! Dragon, monkey, flamingo and toad... I have a specific sambo. You chop and you get the result.

It is not.

I've said it a hundred times before about the usefulness of encapsulation and rights constraints.

The usefulness of inheritance and polymorphism can be clearly seen when dealing with lists of items where there is a common virtual interface, but the implementation is significantly different.

Here is the simplest situation I encountered just this week - there is a list of structures, one of whose fields is a double-value. The idea came up to approximate these values using OOP.

Without OOP, I either have to write entirely procedures that will create the corresponding SLAEs and solve them. Or, if I already have such a program to work with an array of values - write procedures that would create such an array, and pass it to the library function.

With OOP - I inherit from CLSMCore class, and overload virtual functions that return point values. Immediately I can get the coefficients of the approximation polynomial.

That is, under equal conditions (when we have a library function or class), I would lose without OOP by introducing an extra intermediate array. Not to mention the need to figure out exactly how to fill it. (Value retrieval functions - with or without OOP - need to be written). The main advantage, in my opinion, is the simplicity of support and modification. With OOP there is less to understand. And at the beginning I spent absolutely as much effort on writing the CLSMCore class as I would have spent on the library approximation function without OOP.

 
Georgiy Merts:

It is not.

I've said it a hundred times before about the usefulness of encapsulation and rights constraints.

The usefulness of inheritance and polymorphism is clearly seen when working with lists of items that share a common virtual interface, but the implementation is significantly different.

Here is the simplest situation I encountered just this week: there is a list of structures, one of whose fields is a double-value. The idea came up to approximate these values using OOP.

Without OOP, I either have to write entirely procedures that will create the corresponding SLAEs and solve them. Or, if I already have such a program to work with an array of values - write procedures that would create such an array, and pass it to the library function.

With OOP - I inherit from CLSMCore class, and overload virtual functions that return point values. Immediately I can get the coefficients of the approximation polynomial.

That is, under equal conditions (when we have a library function or class), I would lose without OOP by introducing an extra intermediate array. Not to mention the need to figure out exactly how to fill it. (Value retrieval functions - with or without OOP - need to be written). The main advantage, in my opinion, is exactly the simplicity of support and modification. With OOP there is less to understand. And at the beginning I spent as much effort on writing the CLSMCore class as I would have spent on the library approximation function without OOP.

For example, I've never understood what function overloading is needed. It's absurd, isn't it? We make a function without parameters, inside we write all calculations of the overloaded functions, make variables global and have access to the results from any other function. Well, isn't that nice!

But no! We will divide all the calculations into functions with the same name, but different parameters. And we will make a heap of input parameters for each function. No. That's not enough. Let's make the names of parameters unreadable. And we will make all sorts of arrays to be passed in mixture with them. And we will make a dozen of such functions so that we would have to ponder over each one. And we'll make sure that access to them will be encrypted. For the syntax to be more sophisticated. That's professionalism!

Sorry, George. I've had enough.


ZS. Just one global array for the results of 10 overloaded functions and one function without parameters that does their work. How is it worse than that? 10 times less syntax.

 
Реter Konow:

I, for one, have never understood why functions need to be overloaded. It's ridiculous, isn't it? You make a function without parameters, write all calculations of overloaded functions inside, make variables global and have access to results from any other function. Well, isn't that nice!

But no! We will divide all the calculations into functions with the same name, but different parameters. And we will make a heap of input parameters for each function. No. That's not enough. Let's make the names of parameters unreadable. And we will make all sorts of arrays to be passed in mixture with them. And we will make a dozen of such functions so that we would have to ponder over each one. And we'll make sure that access to them will be encrypted. For the syntax to be more sophisticated. That's professionalism!

Sorry, George. I'm sorry, George.


ZS. Just one global array for the results of 10 overloaded functions and one function without parameters that does their work. How is it worse than that? 10 times less syntax.

That's right, tell me more about this function. You've got one with a monster-sized switch that selects one of a dozen functions. In such a switch, it's very easy to make a mistake by accidentally writing code belonging to one of the branches in the wrong place.

Things are much simpler with an overload. We have ten different descendants, and each time we work with ONE class, and it has ONE overloadable function. We cannot accidentally write it in another class, because we have to open a completely different file for it.

Plus - the parsing itself in this very huge switch is, in my opinion, much more stressful than opening the one class we need, and then parsing just one function.

In fact, in assembler code all this switch's handling anyway comes down to the same swich, depending on this pointer. But in case of OOP all this is hidden from the programmer and doesn't interfere with his work. Without OOP - you have to deal with it.

Roughly speaking, when you walk - you end up sending signals to your muscles in a certain sequence that move them. However, at the level of consciousness - you just remember which movement to make. Here, OOP is exactly that kind of "memory of what movement to make". You "don't understand why we need to remember the movement when we have a bunch of muscles, and nerves wired to them". well... I've said many times before, for titans of memorisation, it's really quite enough to remember which muscles have to be tensed in what sequence to go. There's no point in remembering the whole movement. For others, who cannot remember so much, it is much more reasonable to remember the whole movement, and what happens to the muscles, in what sequence they are tensed and to what extent - it is more reasonable to hide it from the mind.

 

Реter Konow:

I, for one, have never understood why functions need to be overloaded. It's ridiculous, isn't it? You make a function without parameters, write all calculations of overloaded functions inside, make variables global and have access to results from any other function. Well, isn't that nice!


Tremendous, you're doing some kind of bike building without proper study of the common approach. Peter, find some good book, perhaps Stroustrup, in some book he wrote a text editor, on a real problem you will learn something, I do not remember the content, but it is unlikely to teach you something bad.

Reason: