Algo Design Lab (ADL)


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.

2 Responses to “Algo Design Lab (ADL)”

  1. 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.

  2. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: