As a bona fide newbie, I will say that this list and its users have been a tremendous help. I always try to go to the User Guide and UKB first, but for someone just learning AFL, things can get confusing.
In the last two months, I've posted a few dumb questions on this board and a few not so dumb. The snippets of code offered by members in response, really helped me to understand things. Then the kind programming of my trading ideas into AFL by a couple of volunteers, really accelerated matters for me. I figure I made a year's worth of progress in the last two months with that help vs without. In fact, without that help I might have just given up at the six month mark, if I was trying to figure this all out on my own. Just ordered a copy of Howard's book thanks to this thread. And Progster, thanks for the link to CFT. That looks to be a useful resource. We need a web board, in addition to this Yahoo list, that breaks things down into as many sub forums as possible - maybe not so much for discussion (that's what Yahoo is for) but for archiving and easier searching. --- In [email protected], Dennis Brown <[EMAIL PROTECTED]> wrote: > > Brian, > > You are correct. I switched to AB because I wanted a programming > language that was fundamentally tied into the realtime price arrays > and the charting for the same. RT quotes --> Database --> AFL --> > Charts. That was all I wanted, and that is pretty much all I use. > There is a lot of overhead associated with getting and maintaining the > data, interacting with the user, and outputting the the data in a > useful form. I only wanted to be concerned with the algorithms that > decided to buy or sell. Interestingly, even with all the support > functions handled by AB, I still spend 80% of my time coding UI > things! I think it is some kind of computer programming law. > > AFL was my real destination with AmiBroker, and I had a hard time > because it was not well defined. A lot of assumptions were made about > prior knowledge of specific programming language conventions in C like > languages. Languages I had no experience with. These are middle > level languages. My experience was with machine level assembler code, > and very high level like Revolution/SuperCard/HyperCard, and a > smattering of BASIC and APL from the original versions 40 years ago. > I had no idea that I was supposed to go learn C syntax before I could > use the AFL documentation. IMHO this is a documentation hole big > enough to drive a truck through. > > Then what happens when someone has no experience with any programming > language at all. Perhaps some Excel experience, or maybe experience > using a programmable calculator. I can't imagine the bewilderment > with AFL. It takes a lot of handholding from support or this list to > get over the first hump. > > I believe it would be appropriate to define the AFL language in the > documentation as if it were the only language that exists on the planet. > > For instance "+" is defined as "Addition". Whereas, in reality the > "+" operator is data type dependent. It will add two numbers, add a > number to every element in an array, add two arrays element by > element, or concatenate two strings. It will not add a number or > array to a string. > > As I have suggested before, I would have liked to see a "Complete" > listing of all operators, functions, reserved words, syntax > characters, directives, etc., in one live list index that points to a > page that explains each one in the same way that the functions are now > described. Then additional "see also" pointers on those pages to > point to more in depth documents when available. In fact the current > functions list could simply be expanded to do this. > > This would have saved me many weeks off the learning curve. > > I don't know if Howard is planning on doing this in his new book, but > it should be part of the on-line documentation. > > Best regards, > Dennis > > > On Aug 28, 2008, at 10:34 AM, brian_z111 wrote: > > > I didn't explain myself very well there. > > > > What I am saying is that I think we are making it harder by not > > admitting that it is a programmers program and just getting on with > > teaching AFL. > > > > If anyone held told me that at the start I would have run for it but > > the fact is that the help manual is about 'AmiBroker the program' but > > eventually I came to realise it is all about programming - > > specifically AFL. > > > > So, if I do want to get on with it where do I go? > > > > The AFL section of the help manual is condensed. > > The first few chapters of Howards Book are a basic intro to AB and > > the rest of the book is orientated around SystemDesign & Evaluation? > > > > Where is the next stop on the AFL line? > > > > > > brian_z > > > > > > > > > > --- In [email protected], "brian_z111" <brian_z111@> wrote: > >> > >> Herman, > >> > >>> I always figured that sticking with AFL would have provided a more > >>> continuous path for users to develop their programming expertise. > >> > >> This is a new point, not really discussed much before, I think. > >> > >> I really don't know how to put it in words but you are so right. > >> > >> Tomasz should be proud of me because if I am a programmer at all I > > am > >> an array programmer...... but sometimes I am left reaching for AFL? > >> > >> Perhaps there are conventions that people with 2 or more > > programming > >> languages automatically understand? > >> > >> Do I have to go and learn C++ as well. > >> > >> Should I need too? > >> > >> brian_z > >> > > > > > > > > ------------------------------------ > > > > Please note that this group is for discussion between users only. > > > > To get support from AmiBroker please send an e-mail directly to > > SUPPORT {at} amibroker.com > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > http://www.amibroker.com/devlog/ > > > > For other support material please check also: > > http://www.amibroker.com/support.html > > Yahoo! Groups Links > > > > > > >
