|
PureBytes Links
Trading Reference Links
|
Dear members do not waste
your time ...
Regards,
Ton.
----- Original Message -----
Sent: Sunday, January 10, 2010 4:15
AM
Subject: Re: [amibroker] A computer
science related question on the AFL Language
This is getting irritating. You are expressing your views in a manner
that is rather insulting.
I have my doubts about your claim to such
experience. If you truly had experience with such large companies, you
would have expressed your views with greater tact.
While I would had
made slightly different decisions on some aspects of AFL, I can understand the
rationale behind those choices I would have made differently and I certainly
would not criticize the product or the developer for the choices
made.
AFL is a specialty language, and so I would not expect the same
things from it that I expect from the programming languages I normally
use. In some respects it is analogous to VB. VB was originally
designed as a scripting language for MS Office. In that domain it works
very well. But as a general purpose programming language it is deeply
flawed. It does what it was designed to do very well, but for other
domains it is a poor choice. AFL, too, does what it does well, but I
would not use it to develop a streaming video server.
This reminds me
of an experience I had early on in my career. I had to develop a product
for the agricultural consulting industry. My product had several
competitors, and their products were quite impressive. They had the look
and feel of something designed by engineers for engineers. They were
also commercial failures because they ignored the characteristics of the
target market. The clients and the users were very different. The
clients were farmers with earned doctorates in some aspect of agribusiness,
with plenty of experience using IT. The users were secondary school
graduates who had never turned on a computer. They were bright people,
and could strip down, repair, and reassemble their farm equipment without any
problems, but they were intimidated by IT. I developed a product that
had a very simple interface, using jargon the users would be familiar with,
and building in a little AI. That product was ridiculed by the
competition, who falsely believed that the product was as simple as the user
interface. However, the product was a commercial success BECAUSE THE
USERS UNDERSTOOD IT. My product did all the same things that the
competition did, but it's interface was designed to be intuitive for the end
users. The feedback we received from the clients was that the users
refused to use the competitors' products because they did not understand them,
but they loved using the product I developed because they found it so
intuitive that they did not need the user's manual.
If you had
the experience you claim to have, you would know that a product's design must
take the end users needs into account, and you would have made allowance for
that in your assessment of AmiBroker. This is a product that appears to
have been around for a long time, and so it must have found a good fit between
what it offers and what its users need and understand.
Now, as for your
claims about python, I am well aware that there are some 'libraries' that have
been developed for it using fortran and C/C++, and so it is possible to get
reasonably fast code from it. I am not impressed by it, though, since I
can make my C++ code much faster than my fortran and C code, and I have used
fortran for twice as long as I have C++. Going to something that is only
as fast as good quality fortran code is for me a step backward. However,
if I were developing a product that needed something analogous to AFL, I would
rebuke any programmer working for me who suggested I provide support for
python in that product. Neither Amibroker nor the products I develop
need a full fledged general purpose programming language, although there is no
question that a specialty scripting language is often useful. It is
sufficient that one can develop plugins for AmiBroker, so one can use a
general purpose language like C++ if one needs to do so. This has
nothing to do with the nature of the python language itself. Rather, it
has to do with the availability of capable programmers who know it and the
rather small likelihood of customers asking for it. It is hard enough to
find capable programmers who know mainstream languages like fortran or C++, or
more recent languages like perl. When I look at undergraduate and
college curriculae, I see some coverage of basic object oriented concepts, but
very little dealing with generic programming and none at all dealing with more
advanced concepts like template metaprogramming. Until there is
significant demand for support for python bindings for one of my products and
until there is a sufficient and reliable supply of capable python programmers,
I will not be adding support for python bindings to any of my
products.
I am sorry I am not especially impressed by what looks to be
one of your favourite programming languages, but if you want to advocate its
use, you have to address the business aspects of such a decision in addition
to any technical advantages the language offers. There is no point in me
developing a product in python, or any other language, if it is too hard to
find a capable python programming to maintain and extend it. And there
is no commercial sense in providing support for python bindings if there are
insufficient numbers of customers who could use it.
In any event, this
is hardly the place for you to try to sell the merits of python as most here
are not likely to even understand the programming issues you and I may
see. And I'd rather not see my mailbox cluttered by this stuff. I
would rather see useful information about using AFL as it is to develop, and
experiment with/backtest, trading systems.
Cheers,
Ted
On Sat, Jan 9, 2010 at 9:20 PM, Potato Soup <potatosoupz@yahoo.com>
wrote:
Nobody's venting. And if you don't care about it, why are you posting?
Date: Sat, 9 Jan 2010 21:15:51 -0500
Subject: RE: [amibroker] A computer science related question on
the AFL Language
Well, if you have such a
knowledge, send an e-mail may be privately to TJ, but I do not care about
your venting here.
In
addition, not much respect for somebody posting with a fake name. No much
respect neither for your multi-billion dollars programs, who put you in the
class of Goldman Sachs, with so poor systems they had to get a AIG guarantee
the taxpayers had to pay, thanks to their political influence.
JP
A very simple question to
answer. I use your product because it is one of the few that offer decent
built in drawing capabilities (pixel level). How much money I or my
employers have is largely irrelevant, all tools are considered for the
job.
I'm sorry that you don't want to take some constructive
criticism from other people in the field. That is unfortunate for your
customers. I, nor anyone else has suggested that you failed in your original
endeavor, or that AB/AFL is unworthy of any recognition. If you re-read my
original posts you'll see that I mention that it has some positive
attributes. But if you expect everyone to blindly praise you and suppress
constructive criticism or advice than you will be disappointed. The best
software takes the best ideas from everyone and synthesizes them together. I
still have hope that AB can someday be the
best.
Cheers.
From: Tomasz Janeczko <groups@xxxxxxxxxxcom>
To: amibroker@xxxxxxxxxps.com
Sent: Sat,
January 9, 2010 8:37:17 PM
Subject: Re: [amibroker] A computer
science related question on the AFL
Language
Hello,
If you are so great and working
for all those multi-billion institutions I am wondering what are you doing
here,
using so cheap and "flawed" system as you wrote in your original
post. Surely for that amount of money that you have in hand
you could
hire best programmers in the world and write your own super-trouper language
and all that stuff.
So please give me a break. I wrote AFL for
myself back in 1995 because I need tool for my own purposes. I decided to
offer it for others and some people liked it. That's whole story. If you do
not like it then search elsewhere or write your own for your multi-billion
institution. And no thanks I do not need your advice.
Best
regards,
Tomasz Janeczko
amibroker.com
On 2010-01-10 02:24, Potato Soup
wrote:
Sorry for adding my "twisted" opinion, which only has
experience building trading systems for multi-billion dollar
institutions.
And Python's math modules that are implemented in
Fortran and C are not "slow" In fact there are Python math implementations
that run on GPUs. Python as a language can be optimized to be as fast as
anything.
I'm more than happy to offer help if the AB author needs
assistance adopting more modern and "twisted" technologies. My goal in
offering the feedback was to help improve the product.
Cheers.
Date: Sun, 10 Jan 2010 02:17:31 +0100
Subject: Re: [amibroker] A computer science
related question on the AFL Language
Hello,
Precisely.
AFL is designed to be
able to express trading system rules / indicators in easy and short form and
to be fast. That's all. It is intended to be easy to use and fast thanks to
array processing that general-purpose languages lack. Just compare Traders
Tips formulas published on S&C site for various platforms (some of them
using so called "standard" laguages) and you will quickly find which formula
is the shortest and easiest to understand. That speaks for itself and has
more weight that sombody's twisted opinion.
If one wants full blown
C++ - one can use it - just write your code in C++, compile it as a plugin
and that's it.
Python/Lua and all that stuff are slow compared to AFL
array processing. And as far as object-oriented programming is considered,
most people are not comfortable with it (and belive it or not but most
people are NOT programmers). I can tell that because I hear a lot of
feedback from users.
Best regards,
Tomasz Janeczko
amibroker.com
On
2010-01-09 14:57, Prashanth wrote:
Its not a
question of whether it can be improved or not. Its a question of how user
friendly it is. Most traders are not programmers and hence complex coding is
out of question for vast majority. Its this group that appreciates the
easiness of coding in AFL as compared to other languages which may hold more
potential but can be much more difficult to learn.
I believe TJ
has simpliefied as much as possible and maybe during that simplification
process, there were some sacrifices that were done. Unless one is a hard
core programmer, I feel AFL more than meets every specification. For those
who like to use more tools, ADK is always there to use and create outside of
AB what they desire to achieve.
----- Original Message
-----
Sent: Saturday, January 09, 2010 19:15
PM
Subject:
Re: [amibroker] A computer science related question on the AFL
Language
Why design one when Python is free, as is Lua, Squirrel
and other easy scripting languages? I have built many trading systems for
hedge funds and big banks. Never once considered building a language with
it.
Sounds like you think AFL can't be improved? From a language
perspective AFL has some good ideas and concepts but uneven execution. A
lot of things feel incrementally added, whether they were or not I don't
know.
Date: Sat, 9 Jan 2010 08:34:37 -0500
Subject: RE: [amibroker] A computer science
related question on the AFL Language
Well, you should design
one! As far as I am concerned, elegant and great price/quality
ratio, the best in the market in that bracket. Part of my tool box and
achieved north of 70% last year with it.
JP
AFL is an imperative language primarily with a dose of vector
processing features that enable the terseness that you talk about. I would
not describe it as an OO language in any way, just because it has OO
bindings or provides access to objects. If you can not write an object
then the OO syntax introduced in the backtester is syntactic sugar at
best. I also wouldn't say it has anywhere near the power of C or C++ just
because it offers some syntax similarities. Those languages derive their
power mainly from their ability to access memory directly, and at the OS'
discretion this means writing directly to hardware memory maps. Of course
C++ takes things much further. But AFL doesn't give you anywhere the
expressive data structure creation abilities that a true imperative or OO
language would.
Personally I feel AFL is a deeply flawed language
that mixes constructs from Basic and C at very superficial levels. It
provides its power from underneath the hood, not at the true language
level.
I would pay a lot of money for AB with Python as its
language, using NumPy as the fast math and numerical processing
underpinning.
This is not to say that AFL doesn't have elegant
concepts or advantages. It is just not a well designed language from the
ground up.
-----Original Message-----
From: "cascade3891"
<cascade3891@yahoo.com>
Date: Sat, 09 Jan 2010
08:26:59
To: <amibroker@xxxxxxxxxps.com>
Subject:
[amibroker] A computer science related question on the AFL
Language
Hi Amibroker community,
I have specific questions
about the AFL language, regarding where it stands within the computer
language spectrum(s) and what effect that has on speed/performance,
agility and modularity as well as its accuracy for readability and unit
testing purposes.
I know that AFL is not an object oriented
programming language for the main part (however it does have some OO
features like COM), does this make AFL primarily a functional programming
language, a bit like OCaml??
Are functional programming languages
better for financial trading applications? Where there is a need for
speed, and quality stable code?
AFL seems a lot brief in terms of the
amount of code that you have to write (terse) ... this makes it more
attractive for reading over and checking the code, and for backtesting
purposes.
I notice also that with AFL you don't have to declare
data types, again making it much more efficient.
Is there a
drawback to using an OO code for financial trading
systems/applications?
I quite like the speed and terseness of
the AFL language actually, and also since it has many similarities to C.
But would there be any limitations to not being able to define classes and
objects?
I'm not an experience programmer so sorry if I sound
green.
Anyone have any ideas on Tomasz' original design philosophy
when he set out creating the AFL language? to me it seems like he wanted
to keep the power and similarities to C/C++ given the similar syntactical
structure, whether because he knows that language well, or because he
wanted it to be able to have the same sort of power, but he also seems to
have kept in mind the needs for performance and stability, terseness for
backtesting/speed purposes, and maybe also b/c most traders need to
pick up the language, hence trying to make AFL easier to grasp.
------------------------------------
****
IMPORTANT PLEASE READ ****
This group is for the discussion between
users only.
This is *NOT* technical support channel.
TO GET
TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO
SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions
sent via other channels won't be considered)
For NEW RELEASE
ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo!
Groups Links
-- R.E.(Ted) Byers, Ph.D.,Ed.D. TED@xxxxxxxxxxxxxxxCORP.COMCTO Merchant
Services Corp. 350 Harry Walker Parkway North, Suite 8 Newmarket,
Ontario L3Y 8L3
__._,_.___
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
![]()
__,_._,___
|
|