Interesting take on the PLO - page 5
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
If the question is to my example - at least you hide the implementation (you hide it even from yourself) - i.e. you write only the logic of calculations, it is convenient, it is readable, it allows you to avoid logical errors
SZZY: With respect to trading - I wrote and still do experiments with grids of orders, where I write the logic of placing orders as A + B - C, where A, B, and C - that is orders with predefined parameters, very useful for genetic algorithms- interesting topic
Wrappers are a good and logical solution. When it suits the purpose. And I think wrappers are an innovation in procedural language. Exactly in the sense of novelty and usefulness.
As for trading - I wrote and still carry out experiments with grids of orders where I write the logic of order placement as A + B - C , where A, B, and C are orders with predefined parameters - it is very useful for genetic algorithms- it is an interesting topic
A, B, and C with predefined parameters- as a phenotype for genetic algorithms?
encapsulation gives freedom of names. And if this problem is solved by name logic. This of course is costly. then python can be written in functions. but it will not be a marketable solution. BUT IT IS POSSIBLE.
In python, any function is an object, just like a variable)
By the way, an example of continuous OOP is Python. There, rather, no one knows that anything other than OOP exists.
there are closures and you can write without OOP at all, at least in the old one, whichever you like.
in python, any function, like a variable, is an object)
All you can do is use references to solve everything, as long as the names don't overlap. A function is of course an object, but its result is unified internally, and only in global and public you can look inside. i like python logic))))
there are closures and it is possible to write without oop at all, in the old one at least, whichever one likes
well you can, but still the minimum building block is an object
I haven't seen him in a while...
Has he really gone under a different screen name?
Nah, it's not Peter, it's a different style of writing.
the starkly enterprise OOP is Java. In our field, Du* *opy is represented (sprinkled to avoid getting caught up). If you want object beauty - try soberly to understand and remember their API, thankfully the theme is known :-)
But it's all bullshit...
To raise your programming skill, you may want to learn something mind-twisting. For example there's Rebol/Red ( https://www.red-lang.org/)- pretty cool stuff, it's not fucking easy to understand but it's cool.
or a classic, Smalltalk(https://pharo.org/). You can even use it in production.
And all this "let's write A+B in different styles" is child's play, honestly.
And then all questions about who is cooler, OOP or FP will disappear by themselves.
well you can, but still the minimum building block is the facility
the object was a breakthrough.
Where OOP is more convenient, I use OOP, where I need to save memory and time, and code for myself, I stay with procedural. Just came across an article, I wanted to listen to opinions, where/what is better). Result - I've heard a lot of different things in my address, not about programming) Everything as usual.
So no one will tell you anything new. Use what you are comfortable with, that's all.
To minimize errors, there is a whole area called evidentiary programming (formal verification in particular).
As a partial measure to improve the code quality, you may suggest following any common coding style (e.g. google codestyle), using assertions, constraints (const, override, access specifiers) that do not in fact affect execution but cause compilation errors if used incorrectly, become familiar with the approaches in design in general
The fact is, apart from critical programming areas, it is generally more important to get the production version out quickly than to get the quality of the code, which is bad but true