My approach. The core is the engine. - page 17
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
The approach is reminiscent of Pascal's TurboVision. Although, type control and encapsulation constraints were already implemented in this library.
I remembered Pascal for I've seen it and even managed to plug in TurboVision a couple of times during the classes... my recollections are very unpleasant, no matter how I twisted Turbowijn - anyway, the only output was Norton Commander - everything was very narrowly-specialized, if I'm not mistaken, Pascal 6.0 wasn't yet OOP.
I remembered Pascal because I had seen it and even managed to plug in Turbowijn a couple of times during classes... The memories are very unpleasant, no matter how you twist Turbowizhne - you can only get Norton Commander in the output - everything was very specialized, if I'm not mistaken, there was no OOP in Pascal 6.0 yet
As I recall, TurboVision was precisely the first OOP library (with incomplete support of the ideology then, but still), and it appeared in Pascal 6.0
I looked intoWikipedia. It seems to agree with me.
As I remember, TurboVision was exactly the first OOP-library (with incomplete support of the ideology then, but still), and it appeared in Pascal 6.0
Looked intoWikipedia. It seems to agree with me.
Alas, I successfully passed that moment in my education - OOP was shown only in C++; 5 years later I went to Delphi on my own, Pascal remained in my mind as a procedural programming language.
As I remember, TurboVision was the first OOP library (with incomplete support of the ideology then, but still), and it appeared in Pascal 6.0
I looked onWikipedia. It seems to agree with me.
A full-fledged OOP for Pascal first appeared in Delphi. Turbo Vision referred exclusively to the text GUI under Ms-DOS.
Full OOP for Pascal first appeared in Delphi. Turbo Vision was exclusively concerned with the text GUI under Ms-DOS.
Well, that's what I say - "with incomplete support". The sixth Pascal was "Pascal with objects". And that's right, TurboVision was a purely windowed interface. Well, roughly what Peter brings to your attention.
In fact, Peter's creation is quite interesting. It's the applicability that raises questions. Not once I've encountered that absence of globally accessible objects and full encapsulation of code, working exclusively through purely virtual interfaces prevented a lot of bugs, and helped in supporting and fixing bugs. Actually, Peter correctly noted - "based on programmer convenience".
Full access to an array of all features - in theory, it really allows you to achieve greater efficiency, due to the lack of overhead on interface wrappers, on control and type conversion, on following object access protocols... However, all this is achieved just by the fact that all these things - must be remembered and taken into account by the programmer himself.
It turns out that we take it upon ourselves, instead of transferring the work to the computer in every possible way. Peter, as a titan of memorization - is not burdened by it. But I'm afraid the rest of us would find it quite stressful. And one may agree to it just for the sake of some big advantages. Alas, I don't see them. Especially since Peter's focus is not on automatic trading, but on manual trading.
The secret to remembering is that your thinking must be structured. You have to look at code through the lens of OOP, but not use OOP itself. This is what I do. You have OOP in the program, I have it in my head.
Therefore, I get the advantages of OOP and the advantages of its absence. And you get only the advantages of OOP.
The secret to remembering is that your thinking must be structured. You have to look at code through the lens of OOP, but not use OOP itself. This is what I do. You have OOP in the program, I have it in my head.
Therefore, I get the advantages of OOP and the advantages of its absence. And you get only the advantages of OOP.
That reminds me:
So, I get the benefits of OOP and the benefits of not having it. And you only get the benefits of OOP.
It's hard to say what you see, but I will say that if you take a ready-made class, bring its methods and fields to the global scope (deploy), you get your approach, then you call the fields the kernel and the engine and get... you get unmanageable code which you can write from scratch, but you can't modify
ZS:
Why is OOP interesting? - because the programmer doesn't have to think up new variable names all the time! - you create a base class, write everything you see at the moment and that's it.... It is not necessary to inherit, just create an instance of the class (or even an array of classes!) and get all the variables, which are split for every object (class) at once ... OOP at least is practical, and the speed of execution... You always work either directly with CPU registers or use higher level languages, usually you have enough computing power to write everything as convenient, if not enough power, you start profiling and rewrite the problematic code segments - not many people do this
It's hard to say what you see, but I will say that if you take a ready-made class, bring its methods and fields to the global scope (deploy), we get your approach, then we call the fields the kernel and the engine and get... you get unmanageable code which you can write from scratch, but you can't modify
ZS:
Why is OOP interesting? - because the programmer doesn't have to think up new variable names all the time! - you create a base class, write everything you see at the moment and that's it.... It is not necessary to inherit, just create an instance of the class (or even an array of classes!) and get all the variables, which are split for every object (class) at once ... OOP at least is practical, and the speed of execution... You always work directly with processor registers or use higher level languages, usually you have enough computing power to write everything as convenient, if not enough power, you start profiling and rewrite the problematic code sections - not many people do this
What repulses me in OOP is a rigid format of code writing. As you've seen, I tend to compile large data tables and find it very practical. In OOP I have to adhere to a bunch of rules, which I personally find very constraining.
In short, I'm programming with a different OOP. My own. There are few rules and a lot of freedom. Functionality itself is put into large blocks, and data are organized in kernels. I don't even specially think through their structure. Everything develops on its own. On the intuitive level.