Linkers::X - Let's code in C++ , Daytrade & Daydream :)

nooby_mcnoob said:
Does such a setup make sense in all circumstances? With C++ concepts "around the corner" and templates, your algorithms shouldn't care about xVector vs std::vector.

But they do. And so it doesn't flow.
More...

You obviously missing the greater picture here. I wasn't asking you to analyze into a dot the source code which just Resembles to the reality, but to see if you can see the bigger pix. and how you seeing it!
If you are experienced coder/trader you should see clearly what i'm trying to say here.
And for Christ's sake! why should I NOT care about the speed? My implementation is decades old(commodore Amiga __ASM era) and way faster than the std::vector. It perfectly suits my needs and the magic is fully exposed trough the C-API LinkersX.dll & wrappers and it makes Linkers::X let just say... more vibrant;)
 
Last edited:
fan27 said:
As far as I can tell, the OP was not asking for you to perform a code review. To just say someones code is terrible without any context of their programming background is kind of lame.
More...

I may be mistaken, but he said that he is a senior C++ engineer. I've dealt with many senior C++ engineers who write this bum ass code. If I can make one person think twice about writing code like this, I have done my job.
 
LinkersX said:
You obviously missing the greater picture here. I wasn't asking you to analyze into a dot the source code which just Resembles to the reality.
If you are experienced coder/trader you'd see what i'm trying to say here.
More...

That I had such a visceral reaction to your code means that the rest of reality is going to suck.

Now, you can make it functionally very useful by brute forcing it. I've seen that before. And that's more or less what you'll end up doing, which is fine.

If you build a reliable, correct, featureful backtesting system in C++, I'd use it, even if it's completely ugly.
 
nooby_mcnoob said:
That I had such a visceral reaction to your code means that the rest of reality is going to suck.

Now, you can make it functionally very useful by brute forcing it. I've seen that before. And that's more or less what you'll end up doing, which is fine.

If you build a reliable, correct, featureful backtesting system in C++, I'd use it, even if it's completely ugly.
More...

Linkers::X c++ backend is vibrant as Sandra Afrika from this song, you see how's she bouncing around



But the front-end, the actual Trading language aka MQL4 or NinjaScript wrapper for example should be like Mona Lisa.

We are discussing the front-end here, and if You are seeing something very strange in that source code that's because i have certain last minute doubts about the actual syntax. The wrapper defines the actual Object Oriented Trading language aka Linkers::X
I'd actually like get a little input from the community here about the front-end, to hear ways to improve Syntax of the language.
This Trading API will be released on github in January 2018, free of charge

And I really don't see why wouldn't I just brute force things, that's all I ever got inherited from my __ASM era. Maybe I'm mistaken, but I think You are obviously younger generation, one of those new "Abstract classes in C#" kids from the block. You obviously haven't seen how things were done back in the days when c/C++ was just forming as a language.
 
Last edited:
LinkersX said:
Linkers::X c++ backend is vibrant as Sandra Afrika from this song, you see how's she bouncing around



But the front-end, the actual Trading language aka MQL4 or NinjaScript wrapper for example should be like Mona Lisa.

We are discussing the front-end here, and if You are seeing something very strange in that source code that's because i have certain last minute doubts about the actual syntax. The wrapper defines the actual Object Oriented Trading language aka Linkers::X
I'd actually like get a little input from the community here about the front-end, to hear ways to improve Syntax of the language.
This Trading API will be released on github in January 2018, free of charge

And I really don't see why wouldn't I just brute force things, that's all I ever got inherited from my __ASM era. Maybe I'm mistaken, but I think You are obviously younger generation, one of those new "Abstract classes in C#" kids from the block. You obviously haven't seen how things were done back in the days when c/C++ was just forming as a language.
More...

My friend, I have lunched with Bjarne (I pushed extra hard on polymorphic lambdas which are now in), worked professionally with members of the Boost committee, and even as recently as last year, got a Boost library author a very nice job. I have seen it evolve from Cfront to C++20 and have my fingers in all the pies. I even programmed trains in assembly.

Let me give you an example about brute force. I have devised a trading strategy that looks pretty good in backtests. Too good in fact. I am fearful that it isn't correct. So I suggested to my friend that he try and replicate it. I gave him the broad strokes in English and he replicated it. His results weren't as good as mine, but they were damn good. I asked him to send me his code.

It is a mess. It got the job done (i.e., brute force) but it was impossible to follow and the decisions made were just made for the sake of making them. That's brute force. That makes it difficult to understand and clean up. If I had no other choice, I'd use it.
 
LinkersX said:
I'd actually like get a little input from the community here about the front-end, to hear ways to improve Syntax of the language.
More...

Then I think you should start a serious thread.

"I am working on an API, this is what it looks like right now, what do you think?"

As opposed to whatever weak passive statements you made at the outset.
 
nooby_mcnoob said:
My friend, I have lunched with Bjarne (I pushed extra hard on polymorphic lambdas which are now in), worked professionally with members of the Boost committee, and even as recently as last year, got a Boost library author a very nice job. I have seen it evolve from Cfront to C++20 and have my fingers in all the pies. I even programmed trains in assembly.

Let me give you an example about brute force. I have devised a trading strategy that looks pretty good in backtests. Too good in fact. I am fearful that it isn't correct. So I suggested to my friend that he try and replicate it. I gave him the broad strokes in English and he replicated it. His results weren't as good as mine, but they were damn good. I asked him to send me his code.

It is a mess. It got the job done (i.e., brute force) but it was impossible to follow and the decisions made were just made for the sake of making them. That's brute force. That makes it difficult to understand and clean up. If I had no other choice, I'd use it.
More...

RESPECT!
However in this silly thread, we will soon discover some shocking benchmark results when comparing speed of the std:: vs Linkers::X containers.
Trust me bro, there is a reason why I'm avoiding the std:: implementations, and why i kept my containers hidden in the drawer for personal use only over years...
The Emphasis in the Linkers::X trading language should be simplicity,because an average Trader Joe, who is btw not a c++ developer, and who is using one of these silly retail platforms like MT4, doesn't know NOR want to learn anything about polymorphic lambdas but he's more than willing learn
few simple if/then/else statements with named events
There are over 100++ named events built in into the API, that i developed in my 10++ years in the algo trading.

Code: 
if(e.broken_swing_low)
{
short1.sell();
}

// second one to learn for Trader Joe
if(e.higher_swing_high)
{
long1.buy();
}

or use switchers instead of if/then
 
Last edited:
fan27 said:
Actually, I am working on doing something very similar. I am building a Quant ML SDK which will drastically reduce the effort to find profitable trading strategies. Without going to much in to how it will work, the end result will be strategy definitions which will be saved as JSON and the SDK will come with methods to translate the JSON to platform specific code (i.e. TradeStation, NinjaTrader, Custom, etc). As i960 mentioned, the code with have to know the limitations of each platform. The main value add of product will be finding the strategies. Automatically converting them to platform specific code is an added convenience. As a standalone utility, I don't necessarily see a lot of value in having a generic strategy definition (code, JSON, etc) that can be translated to multiple platforms.
More...

In Linkers::X this would translate into something like this:


Code: 
xMarketReplay replay1;
xTime time1 ;  // actual begin time of replay Microseconds resolution

//init
xTime.scDateTime(sierra_SCDateTime); // init xTime from SierraCharts SCDateTime
replay1.loadHistory(20170101, 20171201);
replay1.message("Hey mum, look at these charts...", "192.168.1.45:27017"); // my in-laws would like to see the replay too.
replay1.out(chart1); // local MetaTrader chart
replay1.replay(time1); //my mother in law happy ;-) Priceless

of course my Mother in laws computer is running Linkers::X on a remote location "192.168.1.45:27017", and she will get my lovely "Hey mum, look at these charts, next time this year I'm gonna be a millionaire ;)" message
She will jut roll her eyes and think: Jesus, where this guy is coming from...

She will then press OK to "confirm replay" message with chuckle.
Replay starts in her browser in HTML5/Javascript charts. Everyone Happy?!

NO she's not happy, nor she ever will be. In fact she will just make a big sarcastic remark about the fact that this is just a market replay and i still haven't made any money yet, then she will probably gather the in-Laws for an Intervention, because I'm lazy as man can be and i medicate myself on her daughter's couch, watching charts on my laptop whole day long with a "day-dream" in my head that my martingale EA will make me a millionaire in 2 weeks before the EA gets a margin call ?!$%#@hahahaha
.
 
Last edited:
You must log in or register to reply here.
Back
Top