modify an exising automated trading package or build a new one ?

Quote from ecoscien:

Now what do you mean exactly in that last sentence? What problems do you foresee here?

More...

Somewhat related to the old Fortran programmers joke that GOD is INTEGER unless declared REAL.

The basic issue is that in a weakly typed languages bugs can be introduced into programs by changing the type of a variable at run time leading to unforseen/unwanted behavior. In a strongly (explicitly) typed language the compiler flags this as an error at compile time. This tends to require strongly typed languages to be more verbose and possibly impose 'unnatural' contraints on the writing of code.

Pascal is an example of a very strongly typed language.

I'm not that well informed on the current debate. A web search should turn up quite a lot of stuff about Python in this respect.
 
Quote from dcraig:

Somewhat related to the old Fortran programmers joke that GOD is INTEGER unless declared REAL.

The basic issue is that in a weakly typed languages bugs can be introduced into programs by changing the type of a variable at run time leading to unforseen/unwanted behavior. In a strongly (explicitly) typed language the compiler flags this as an error at compile time. This tends to require strongly typed languages to be more verbose and possibly impose 'unnatural' contraints on the writing of code.

Pascal is an example of a very strongly typed language.

I'm not that well informed on the current debate. A web search should turn up quite a lot of stuff about Python in this respect.
More...

Got it, Thanks, Craig.
 
Quote from dcraig:

Somewhat related to the old Fortran programmers joke that GOD is INTEGER unless declared REAL.

The basic issue is that in a weakly typed languages bugs can be introduced into programs by changing the type of a variable at run time leading to unforseen/unwanted behavior. In a strongly (explicitly) typed language the compiler flags this as an error at compile time. This tends to require strongly typed languages to be more verbose and possibly impose 'unnatural' contraints on the writing of code.

Pascal is an example of a very strongly typed language.

I'm not that well informed on the current debate. A web search should turn up quite a lot of stuff about Python in this respect.
More...
Craig,

The above requires correction. You make it sound like we are still living in Niklaus Wirth's pre-Pascal age of about 35+ years back. It would be irresponsible to allow absolute newbies pick up things for gospel that you yourself clearly don't know much about. Indeed, as you suggest, a little web search on Python might be beneficial in putting you on your way. You will learn that for Python your writing: "The basic issue is that in a weakly typed languages bugs can be introduced into programs by changing the type of a variable at run time leading to unforseen/unwanted behavior", could only be imagined as a BUG in Python itself. Never 'impossible' but rather extremely far fledged. (Never heard about bugs in Java? :D) Python is intensively relied upon, day in day out, by leading scientific research establishments.

nononsense
 
Quote from nononsense:

Craig,

The above requires correction. You make it sound like we are still living in Niklaus Wirth's pre-Pascal age of about 35+ years back. It would be irresponsible to allow absolute newbies pick up things for gospel that you yourself clearly don't know much about. Indeed, as you suggest, a little web search on Python might be beneficial in putting you on your way. You will learn that for Python your writing: "The basic issue is that in a weakly typed languages bugs can be introduced into programs by changing the type of a variable at run time leading to unforseen/unwanted behavior", could only be imagined as a BUG in Python itself. Never 'impossible' but rather extremely far fledged. (Never heard about bugs in Java? :D) Python is intensively relied upon, day in day out, by leading scientific research establishments.

nononsense
More...

Nonon,

I really didn't imply anything in particular about Python and I did recommend to DYOR. But here's some observations about Python and threads.

After some admittedly brief googling about threads I came up with a couple of things that caught my attention.

1. Python threads are 'mostly' user space things. I take that to mean they are something akin to green threads in Java or other user space threading implementations. The article also suggested that good use for threads in Python was 'to make the code clearer' and for asynchronous IO, neither of which I find compelling reasons to use threads. User space threads might be fine on a single CPU machine, but for SMP and dual core, threads really must be kernel based so the OS can schedule threads on the multiple CPUs. If I've understood what's being said correctly and this is sttill the current situation, this is a serious issue with the move to multi core machines.

2. Python maintains a global lock list, so that any object can only be accessed by one thread at a time. All sorts of issues come to mind here and without knowing more about the mechanism it's difficult to come any definite conclusion but the word 'deadlock' leaps out at me straight away. I'm really not fussed with the idea of implicit locking at all. Again, I may be missing something here.
 
Quote from dcraig:

Nonon,

I really didn't imply anything in particular about Python and I did recommend to DYOR. But here's some observations about Python and threads.

After some admittedly brief googling about threads I came up with a couple of things that caught my attention.

1. Python threads are 'mostly' user space things. I take that to mean they are something akin to green threads in Java or other user space threading implementations. The article also suggested that good use for threads in Python was 'to make the code clearer' and for asynchronous IO, neither of which I find compelling reasons to use threads. User space threads might be fine on a single CPU machine, but for SMP and dual core, threads really must be kernel based so the OS can schedule threads on the multiple CPUs. If I've understood what's being said correctly and this is sttill the current situation, this is a serious issue with the move to multi core machines.

2. Python maintains a global lock list, so that any object can only be accessed by one thread at a time. All sorts of issues come to mind here and without knowing more about the mechanism it's difficult to come any definite conclusion but the word 'deadlock' leaps out at me straight away. I'm really not fussed with the idea of implicit locking at all. Again, I may be missing something here.
More...

Craig, I appreciate your unbiased way of inquiring into many directions. Quite some contrast with other rubbish posts!

I make intensive use of threading in my trading. Deadlock situations can be easily created in any language offering thread support. It is a most common programming mistake of the unaware. Having learned from past experience, I will always take utmost care when introducing thread synchronizing features of a language. Being prudent helps a lot. :)

As to the inner workings of Python, if you have a question that research didn't answer for you, you can always raise it in the users-group. Highly competent people are always courteously trying to help. In fact, Python is rather simple for simple people but amazingly complex and versatile when you get into the more advanced parts.

nononsense
 
Craig,

Thanks for your very informative and thoughtful posts. I have done a little research over the internet and concluded that I will use Java as the programming language. The whole point of choosing a language, aside from performance, is to choose an environment least prone to bugs and errors in programming.

Thanks for your very valuable inputs. Also thanks for mentioning Mac OS X, I have concluded that Mac OS X, the 64 bits, is the best platform to use.

I would appreciate any comments and suggestions from people who have used Java to develop trading algos on Mac OS X.
 
You must log in or register to reply here.
Back
Top