Automated System Development for Non-Programmers.

Discussion in 'Automated Trading' started by Bogwaluth, Jul 29, 2006.

  1. hi nana,

    Having very extensively written about this in the past, let me resume very briefly.

    If you set out to program computers in research projects - most automated market systems would fit this category - fast development turn-around is of utmost importance.
    Over many years, it has been found that development time (debugging part most important), is mainly dependent on the number of lines of code required. In this sense, one could attribute a "clutter" factor to every single programming language.

    "Good"scripting languages shine in this "time to finish" as reported go by a factor of 2 up to 10 as compared to C++ or C#. Also Java is a rather "high clutter" language.

    Know-nothings will immediately object with the execution speed argument. This is a complete nutty idea as in well written code, "good" scripting languages ONLY intervene as a kind of glue between execution blocks of highly optimized C++ library code. Penalty is almost nihil.

    As to your: "I think i know what you are going to say.. learn Python." It is true that I am actually using Python (or stuck with Python). In fact, if I am not mistaken, I have not very often - if at all - referred to Python in my most recent posts. I have already pointed out that Ruby could also be a very serious contender. Being myself very tied up in my current Python projects, switching to Ruby is not that easy right now. This said, if I would have to choose between both, I would go for Ruby.

    nono
     
    #11     Aug 5, 2006
  2. Regardless of whether you are learning a programming language, trading at home or at the local Starbucks, this little tidbit is prime knowledge.

    Thanx,

    Jimmy
     
    #12     Aug 5, 2006
  3. man

    man


    being one of the C++ group i am unable to comment on anything other/better. but i completely second the point that limiting factors in trading system development are not only statKnowHow and marketKnowledge but the shere limitations of your IT-environment. the proper language is definitely a key argument. if you are able to implement robust variations more quickly this per se can become a valid edge over time.

    yet my opinion is still that the actual program design is the first key point. if you do not fully exploit software organisation (extensive use of testing classes for example in the way x-treme programming technique understands the term), it probably does not matter too much which language you chose in the first place. we are finally trading everything from our C++ testing and trading platform. i think we will never really dive into another language since the cost is too high - especially in terms of time.

    having said that i assume that nono refers to high class exploitation of all language features and i second all he said.

    standard tools are much more limited than the average user is aware of. but, there are people trading from TS and trading great sharpe ratios. so in the end it is not entirely a question of IT. but we are here in automated system development. and in this league IT is much more dominant.
     
    #13     Aug 6, 2006
  4. taowave

    taowave

    when you say higher time frame,does that mean daily/weekly or intraday?
     
    #14     Aug 7, 2006
  5. segv

    segv

    Hire a programmer, or learn to program.

    -segv
     
    #15     Aug 7, 2006
  6. More importantly than whether you can program yourself or hire a good programmer... Knowing how to properly develop excellant specs and requirements... as in the design of your project... is much more important...

    good upFront design saves you thousands of dollars and hours of re-do surgery...

    <b>most</b> software projects fail because of poor design... a large percentage of them fail badly...

    imagine trying to build a good size 3 story house with a basement and attic and 2 bathrooms, etc... without good blueprints... just winging it... many software projects start out like that...

    you don't need NASA style documentation or planning for your software project but you do need good agile modeling... and 'commodity' code... as in components you can purchase to put together a system rather than build something from scratch.. witch is mind booglingly time consuming if the project is even moderately complex...

    It took Microsoft about years to get a the first good version of MS Word out... talk about suffering... when they thought they would knock it out in a few months...

    Here is Da book... The book... on software project development... especially if you are going to develop a financial system... at least its the best i have ever read... and re read and applied

    http://www.amazon.com/gp/product/1572316217/103-6987045-0025453?v=glance&n=283155

    cj...

    :)
    __________________
    HAVE STOP - WILL TRADE

    If You Have The Vision We Have The Code
     
    #16     Aug 7, 2006
  7. 5% inspiration, 95% transpiration
    like T.A.Edison said

    Many people these days boast to do "RESEARCH" but never find anything during their whole lives.
     
    #17     Aug 8, 2006
  8. man

    man

    it takes a lot of transpiration to witness inspiration fail 95% of the time.

    (that was smart.)
     
    #18     Aug 8, 2006
  9. nbates

    nbates

    I see the phrase "automated system" here on ET quite a bit and it seems they (and those who program them) fall into two general categories;

    a) simple systems, using higher level platforms like Excel or TradeStation with retail brokers, and
    b) complex systems, developed with languages like C++, Python, Ruby, C#, .NET, etc. with custom interfaces.

    In the realm of the latter I have found the interfaces (quotes, news, execution) and the features they provide, to be an extremely important piece of the equation.

    For example a good quote feed allows tracking and scanning over the broad market in near or soft real-time with little burden on the system and a poor feed will soak-up every ounce of CPU available making it difficult for the system to do anything other than capture data.

    The execution interface(s) are another story and the needs here are different in that you want the best performance (speed, reliability, and smarts) and need a great brokering and clearing relationship co-joined where you can receive maximum leverage and a universal short list, plus ultra-low transaction costs.

    The rest is just programming and the application of knowledge.

    NB
     
    #19     Aug 8, 2006
  10. man

    man

    "... The rest is just programming and the application of knowledge."


    just programming and the application of knowledge. damn! if i just had known that earlier ... thanks for pinpointing it out!

    that phrase makes my week ...
     
    #20     Aug 8, 2006