To Google and back in 6mths, Rick Lane provide a CTO view of ADL, with a screen shot available here. Reminds me a bit of StreamBase Studio but for the Algo world based on an algo trader DSL
~ by mdavey on April 28, 2013.
Posted in Trading
I do not see the slightest advantage of using a visual programming language. This has been discussed and the voices that dismiss it as nonsense are overwhelming. What is new about this? And also a guy who works for 6 months for one of the top IT firms in the world to abruptly leave does not leave a whole lot of confidence in his judgement skills and opinions. Maybe sometimes its better to spend a bit more time researching what one is about to get into before making decisions that impact oneself and others. Visual is sexy and adds to the “U-E” but that is about it.
Fred said this on April 28, 2013 at 12:50 pm | Reply
Hey Matt, thanks for the StreamBase shout-out and for the ADL pointers. BTW here is a link the all the slides for Rick Lane’s gotocon Chicago 2013 presentation: http://gotocon.com/dl/goto-chicago-2013/slides/RickLane_VisualProgrammingCookingTheSpaghetti.pdf
ADL looks pretty interesting. From the slides I think it is a very different kind of VPL than StreamBase’s EventFlow VPL. ADL looks very control flow-oriented and the primitives are very granular, kind of like LabView, though it does appear to have nice modularity constructs built-in. EventFlow is dataflow-oriented and the builtin operators are generally at a higher level of abstraction — we compromise a bit and have a text-based expression language to specify what kind of evaluations go on in each operator. Seems like a pretty good balance, though there’re good variations available in all directions.
It’s cool that Rick Lane talks about the spaghetti issue. I think it doesn’t get talked about out loud enough. He approaches spaghetti mitigation from the Deutsch limit angle — limiting the number of operators per module — which is one part of the spaghetti issue. Other aspects to work through are inter-module dependences, state dependencies, concurrency and parallelism architecture, and, bumping it up a level, replication and availability. All of this has can have its own spaghetti not all of which are solved problems in the general case for sure. The spaghetti problem is logically no worse in VPLs than it is in text-based languages. It’s just that it is harder to hide. The upside of visual spaghetti is that you literally see it developing early on while there’s still time to refactor.
In other words, just because a language is visual doesn’t mean you get to throw good software engineering practice by the wayside.
One of our own guidelines, by the way, is that Deutsch is kind of an optimist. 50 operators per module is too many, in general (especially if you have to show the application on a projector). We think about breaking things up when we hit a dozen or so.
Steve Barber said this on April 29, 2013 at 4:24 pm | Reply
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.
Create a free website or blog at WordPress.com.