Learning to code
- This topic has 12 replies, 8 voices, and was last updated 2 weeks ago by
.
-
You could consider taking a BASIC course if those still exist, as ProRealCode/ProBuilder is based on the BASIC programming language.
Of course, the ProRealTime language is designed for programming indicators and trading systems.
Have you already reviewed the three manuals (ProBuilder/ProOrder/ProScreener)?1 user thanked author for this post.
Hi! You can check also Marketplace: https://market.prorealcode.com/product-category/training-videos/
1 user thanked author for this post.
Charles Babbage, is often considered the ‘father of the computer’. His early mechanical concept designs of the ‘The difference Engine and then the ‘Analytic Engine’, evolved into todays ‘General Purpose Computing’.
He had a realisation that the engine could do various calculations, no just a specific one, using punched cards inspired by ‘Jacquard loom’, which introduce programmability and the start of computer programming.
The ‘Analytic Engine’ design introduced the Arithmetic Logic Unit(ALU); Control Unit; Memory; Input/Output and Stored Instructions, concepts which are found into todays CPU’s and computers.
Ada Lovelace, is often considered the first computer programmer. She recognised that, the ‘Analytical Engine’ could be used for more than mathematical calculations, and could be used to perform any kind of process.
Ada’s extensive notes are considered to contain the first ‘Algorithm’ intended for a machine and foresaw the potential for computers.
Later, Alan Turing and John von Neumann developed the theoretical and practical foundations of computing that followed in Babbage’s footsteps.
Today, our general purpose computers works around manipulating numbers in binary and can be programmed using various programming languages and there instructions.
Programming in binary, ‘Machine Language’ is difficult for us humans with all those ones and zero, others have designed languages to aid writing the programs which then can be converted to the machine language.
Low level languages are closer to machine language than higher level languages which is where ‘Basic’ resides and is more human readable with all the machine complexity hidden from site.
Thanks to Charles; Ada; Alan; John and all the others getting us to this point and the other going into the future.
Regards druby and ChatGpt
1 user thanked author for this post.
Coding / Programming was all around me during the latter half of my career, but I managed to swerve / avoid it! 🙂
When I retired I surprised myself … no coding or formal language courses, I dived straight in and used Algos from the PRC Library as a basis. I then coded simple Algos from scratch, later more complex.
I still mostly have to trial my code to be confident it will work as intended … hence why I seldom help with coding problems on here.
You will get there , just stick at it, but definately also use Algos from the Library on here as a basis for understanding what can be achieved.
1 user thanked author for this post.
PRT language is , like Basic language, pretty easy.
Just think like a computer, read the code from top to bottom, understand how variables works, how arrays works, how conditions works (if then elsif endif), and divide your problems in different parts (smaller problems you can solve easier).
Read the manuals linked above. It may sound like reading a dictionary while trying to learn a foreign language, but remember that more you know all the instructions (words of the foreign language you are trying to learn), more it will be easy for you to translate your thoughts into the PRT language…
Sometimes there is different ways to solve a problem, more you will have experiences (you can read other codes that are posted here and try to understand how they work ; you need to understand the logic behind any code that you read), more you will be able to simplify your codes or make them works faster, etc…
1 user thanked author for this post.
Learning, all about something before starting, against, just getting stuck in not knowing anything are two extremes and the best way to start I guess would fall somewhere in between, since you always know ‘something’.
The former, you may take time, learn a lot but generally not use most of it or very little. The latter, focusses you on the current problem, and where you need gain knowledge.
Giving someone a box of tools doesn’t automagically mean they know what to do with then, however, if your doing ‘something’, it doesn’t take long before you realise you need something heavy, a hammer, to whack it!
Other than simple programming concepts like maths; logic, syntax, comments; variables; condition blocks; loops and input and output, knowing what your trying to program can be a big problem.
Though an algorithm itself can be tricky to implement and refine using the language, knowing the actual system your trying to program for, is the bigger issue.
The first thing that stood out with PRT and the ProBuilder lauguage was the system limits are either not posted or spread over the manuals and not gathered in a table somewhere or list of error messages.
Though generally, this may not be much of the a problem with simpler algorithms, it becomes more of an issue in more complex and/or going to the limits or beyond the current language design.
It’s only knowing, the limits, limit of language and system design that you can ensure you stay within it.
Further to that, code can appear in several different forms, screeners; indicators; proBacktest and proOrder variety’s all with a different subset of common and specific commands.
Then the operational differences, like decimal places and active bar between indicators/backtest also the different ways errors are relayed or not ect…
In conclusion, PRT feels like a bunch of modules bolted together where there are nuts and washers missing in various places. There are a lot of good features but various parts don’t talk to other parts or incompatible or limited in some way.
As time goes on in the life of a application, hopefully these issues will get ironed out, however, its not always that easy to achieve, especially in the short term. The initial design of the platform may have out lived its usefulness to be easily updated with out significant fundamental design changes, changes which require significant time and resources, that’s before adding new features which may be more easily added to a new design. Then there’s backwards compatibility, copyright, licencing, regulations, and other loops to jump through, all while keeping the platform in usable shape and without raising the wrath of the users.
Mostly, when you use software, your not using it from the first version or the beginning so all the prior info, details and evulsion get condensed over the following versions which often appears as the new or different features from last version. To me this is like watching a film from the middle, your missing vital info which takes you off in a different direction, a direction not intended. This can lead to a process of using the software in a way that was not intended or envisioned, this because the core process is masked by the weight of the number of added features added over its lifetime.
Though me being wound up by software is no way limited to just PRT, and is widespread, its something I begrudging live with. Not being totally immune, I do sometimes break out with symptoms of , head in hands; shaking head and occasion rants.
Its often said that an error in software is called a ‘bug’ and eradicating the ‘bugs’ is called ‘debugging’ however, its really the code winding you up about all the errors you make, and a sign that you should be thinking about, what you’ve done, do you know what your doing, and where you should be going.
regards all
1 user thanked author for this post.
Good points, #GraHal, jump straight in and #Lucasbest, divide your problems.
Problems are very timid and elusive creatures, they let you know there there, sometimes, but they like playing hide and seek, and your always it!
If you have 4+2 = 6 and it should have been 1+2 = 3, what is the problem here, is it the 6 or is the 4 or both.
For me the 6 is a symptom of the problem and 4 is the actual problem, you could say the programmer is the creator of the problem.
So if you have a problem, it is more likely a symptom, if so, you need to look up-stream to where the problem skewed off to caused all the knock-on symptoms the problem caused.
In investigating the problem, it may be easily found , but more difficult ones may need a systematic approach maybe going forward or backward through the code, also displaying intermediate values.
It’s possible that the ‘problem’ is outside of the code, this is more difficult and requires a detailed track of the variable and seeing if there changes matches the code execution as expected.
It maybe that your concept of what should happen is not correct, or something deeper you have no control over.
Another problem with ‘Problem(s)’ is that if you can’t find it and ask others. You can only express your problem by the symptom(s) of the problem. It may not be possible to identify the problem from a symptom, or chain of symptoms it creates, with out being able to investigate the code yourself. Under these scenario it could end up as a guessing game where nothing is taken off the table, not even a lot of time wasting.
To aid avoiding problems, you could add test code to ensure variable don’t fall out, or stay within there limits.
I think the IF statements are a good example here.
IF var = 3 THEN
‘do something’
ENDIF
‘do something’ is only executed when var = 3, which is required, but what’s happening when its not 3.
Inserting,
ELSE
‘do nothing’
This takes control of all the other combinations, rather than assuming the rest of the code is happy with the NOT 3 senario.
Generally we know what we want when condition is true, but never scrutinise when its not. Normally not a problem, but when it is, you ‘may’ only get the symptom, if your lucky!
1 user thanked author for this post.
You have helped quite a few of us on here with your very detailed and analytical approach to problem solving.
A Big Thank You!
1 user thanked author for this post.
I was going to say, Good Luck! but ‘Luck is not a factor’
When you don’t know anything, that just means, you have the biggest potential for improvement.
One phrase I often squark out is:
“Within reason, you can teach anybody anything, but what you can’t teach them, is to recognise when it’s wrong!
Learning something new means you’re going to make mistakes!
If you’re going to make mistake, you may as well get stuck in and start learning. (circular logic)
Learning is a like a double edge sword, we try to use one edge to learn and improve, but we often catch ourselves with the other edge while wildly swinging, with not knowing, ‘our mistakes’.
We don’t often realise, that there are a limited number of shrinking mistakes, because once we know of them, why would we want to repeat, the more we learn of them the better.
The more we know about the mistakes to avoid, the closer we get to no mistakes!
If learning something new, causes mistakes, then does making mistakes, cause learning something new. (circular logic again)
An example of this would be writing some code and getting an error message, and not know how to resolve it.
If you intentionally write code to invoke errors, you know what caused them, then when they later popup, you have built up an immune response which can help you respond to what it may be.
Learning by mistakes…
If you open up a new Indicator file, don’t write any code in it, and try to add it to a chart, guess what!
You get an error message notifying you that the file need to be terminated with the RETURN keyword.
Who knew! , learnt that!, all Indicator files need the RETURN keyword, and I have even wrote any code yet, magic!
Like the body, it takes a while to build up an immune response, if it looks like it’s not getting any better, you can always ask on PRC.
2 users thanked author for this post.
The way i learnt to code i prorealtime was to start to play with the auto code function and then start to try things when that culdent do the things i wanted to try.
I spent hours and hours just trying things and when i dident gett the result i whanted, more hours to understand why.
I come from a zero programing background apart from some PLC in school and a few trys in phyton that ended with “Hello world”.
My personality is obsessive at times tho, so lack off sleep have made me needing to take brake the past months..
Just stick to it and try ideas untill you understand why they work or dont work.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
