Can anyone suggest a good programming primer? One for the very beginners through mid-experience, with examples that I can work through myself? (I learn much better through experience.) I know some of you have had schooling in this and might have textbooks or other such things to recommend.
I did the exact same thing instant did. I don't know how to code anything but some mild LUA, but if that's what you wanna code, then check out AddOns of people here at Ace. Just, if you wanna learn the basics, You might now wanna look at Rowne's AddOns, as he likes to code in a different unique way every week. :P
To further agree with what everyone has said already - staring at code is my learning process. I do not have any books to recommend at this time.
I would, however, suggest reading The Ongoing Classes and glance through topics discussed under Developer's Corner. Both of those have helped a lot of people get started with some understandings.
I just studied computer science and software engineering at the university, helped a lot :P
Been there, done that too. LUA is relatively new to me, but since its like the 6th language I've learnt, its not too hard. Getting into programming was a complete nightmare though. I remember it oh so well.
Bascially, if you're trying to work out whats going on, theres a few things that will really help. The first is that if you know anything at all about C, or other procedural languages, just forget it. You'll be doing yourself a favour. OO code is nothing like its procedural counterparts, and your head may well try to implode if you cant grasp this seemingly simple fact.
Beyond that, theres no really easy way to explain just how to code a mod just so it does what you want. The way I've been doing it is:
Step 1 -- Start off small. Take a minimal ACE mod template. Be it an actual skeleton stub file, or be it somone elses Mod. Pick something that starts out with something similar to what you want to achieve.
Step 2 -- Read, or die. Have a look at the layout ofother peoples mods. Ace has a good coding style ettiquette. This means that you should find the functions exactly where you expect to find them. From here, hopefully just reading through the code will give you some idea as to what's going on. If you work out what a function is doing, write it into the function. "--" designates a comment in LUA, and its invaluable to comment mods as you work out what they're doing. That way you save yourself the headscratching if you have to do it again later.
Step 3 -- Live a little... Once you have an idea as to what the function is doing, try modifying the function. I'd suggest windowing WoW to do this. Modify the .lua file, and then try a "/console reloadui". Given the mod fired off at start up, the UI reload should reflect any and all changes you've made the the .lua. Including parser errors. Now you're at this stage, you need to ask yourself one question. Do your changes begin to reflect the changes you intended to make to the file? If not, why not? Given that something unexpected is happeneing, you're most likely going to have done something pretty silly, but this iss all in the process of learning what the functions are doing and how.
Step 4. -- Commenting is good... I know some people will pull me up over the inefficiency of superflous characters. But to all you naysayers, read the next point. For anyone else, always when trying to write your mods, for heaven sake, comment what you're writing. Even if it is just a personal copy of the mod. The way I code for applications, I comment everything. Especially when I start out with a new language, like I am now. The thing is, you will invariably become better at what you're doing. Much better. At that stage, if you ever look back on old code, you really wont have the foggiest what the hell was going through your mind when you wrote it. Sometimes you may not even recognise what its doing, or how. These comments will help you if you have to go back to fix a mod. Maybe one you havent needed to touch for months. One that's become broken when blizzard automagically breaks the function calls you're making to the underlying LUA system.
Step 5 -- Stripping and optimisation. This is something That I'll be doing much more of in LUA than I do in other languages. I'm used to ;s, bracketing and heavy commenting. I can't help it, its just how I know how to program. also commenting any code thats shared in a project gives an undeniable advantage to others trying to work out (A) what you're doing and (B) why you're doing it that way. Thus I'll write my programs with all this in mind. After I get the mod to do what I want, I'll archive a copy of the file. Coments, semi-colons, brackets and all. Then I'll procede to strip every last unecessary character out of my files. This reduces my file sizes by about 20-50% depending upon how large the mod I've just written is. Given that at least 50% of the Ace way of coding is all about code efficiency and optimisations, this just gives your mod that much less time be read and loaded. As they say; Less is More. Also at this stage, tis good to look for any functinos, statments, conditionals, etc that you could shrink down. Often I'll have superflous catches on if statements which where made for clarity, but are now no longer needed.
for example
if Foo
if Bar
do something
end
end
can be written as
if Foo and Bar
do something
end
It doesnt look very messy here, but when you're dealing with several conditionals at once, it can get messy quickly. To LUA though, messy code is not necessarily bad. As long as the logic is the same, you can put it all in one lump, or several lumps. The thing is, often, one lump is usually better -- since it takes less space. The problem with lumping code in this way though is it can soon descend into an unintelligable mess to the human eye.
Anyway, I hope at least some of that will help a little. Getting started is always the hardest part, but stick to your guns for a few weeks, and it'll start to seem like second nature to you.
Also, if you have a question no matter how small or how large conceptually, ask it. I for one have finished my post-graduate education (MSc, and I'm almost finished with my CAS in Systems Assurance-- if I can ever get the last 6 credits done). I also plan to teach computer science and will be persuing my education as such-- likely going next to my PhD.
I has an extreme passion for teaching, troubleshooting, debugging, optimization, etc. Its not easy to distract me with a nice puzzler =), which may or may not be a good thing.
Above all, the way to be successful-- utiliize your resources.
Hmmm, wouldn't it be great if we had an editor which stored comments in a separate file, dynamically linked into the display when editing, yet separate so that the distribution can opt not to include it unless the downloader wanted to see it.
Hmmm, wouldn't it be great if we had an editor which stored comments in a separate file, dynamically linked into the display when editing, yet separate so that the distribution can opt not to include it unless the downloader wanted to see it.
Yeah, that'd be soooooooo nice. But until then, archives will suffice. If i were working on *nix or *BSD I'd be running some versioning system of some sort, like arch. But im not, I'm relegated to windows. Still, at least my new Power Mac should be arriving in a week or so. I should probably set up something like that if im gonna start up on AceBar though for stable and dev branches.
We can actually do that using the lua pre-processor that Kergoth showed up to talk about a bit back. You could have the comments in, you'd just have to pre-process your code before releasing it.
Stun, there is an Ace SVN that you can use, and there are good SVN clients for windows that work quite well.
I'll keep plugging at it then. Thanks. I asked because I have a much easier time learning through experience than example. If I can read the basics of something and then try it out myself first, then I'll have a much stronger grasp of it than if I sit down and look at someone else's work and try to learn from that.
I wonder: I know it defeats the purpose of commenting the add-ons myself, but in the classroom section on the site, could we post commented code and files for examples?
So many times, I'm trying to figure out how to do something, so I will look at someone elses code to see how they did it. Many times this only raises more questions, compounding the issue into a brain meltdown. If there were commented peieces to reference, this would aide many of us in the writing process I feel.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTHen attempt to make the same application by writing everything yourself (just writing off the code from a web page or somewhere).
Then you can look at some other code and -- COMMENT each line of the code as you understand what it does.
I would, however, suggest reading The Ongoing Classes and glance through topics discussed under Developer's Corner. Both of those have helped a lot of people get started with some understandings.
Beyond that, DL the Development tools and example addon located on Ace's download page.
There is also great sources for key LUA documentation located at LUA.ORG and WoW Wiki.
Classrooms
Been there, done that too. LUA is relatively new to me, but since its like the 6th language I've learnt, its not too hard. Getting into programming was a complete nightmare though. I remember it oh so well.
Bascially, if you're trying to work out whats going on, theres a few things that will really help. The first is that if you know anything at all about C, or other procedural languages, just forget it. You'll be doing yourself a favour. OO code is nothing like its procedural counterparts, and your head may well try to implode if you cant grasp this seemingly simple fact.
Beyond that, theres no really easy way to explain just how to code a mod just so it does what you want. The way I've been doing it is:
Step 1 -- Start off small. Take a minimal ACE mod template. Be it an actual skeleton stub file, or be it somone elses Mod. Pick something that starts out with something similar to what you want to achieve.
Step 2 -- Read, or die. Have a look at the layout ofother peoples mods. Ace has a good coding style ettiquette. This means that you should find the functions exactly where you expect to find them. From here, hopefully just reading through the code will give you some idea as to what's going on. If you work out what a function is doing, write it into the function. "--" designates a comment in LUA, and its invaluable to comment mods as you work out what they're doing. That way you save yourself the headscratching if you have to do it again later.
Step 3 -- Live a little... Once you have an idea as to what the function is doing, try modifying the function. I'd suggest windowing WoW to do this. Modify the .lua file, and then try a "/console reloadui". Given the mod fired off at start up, the UI reload should reflect any and all changes you've made the the .lua. Including parser errors. Now you're at this stage, you need to ask yourself one question. Do your changes begin to reflect the changes you intended to make to the file? If not, why not? Given that something unexpected is happeneing, you're most likely going to have done something pretty silly, but this iss all in the process of learning what the functions are doing and how.
Step 4. -- Commenting is good... I know some people will pull me up over the inefficiency of superflous characters. But to all you naysayers, read the next point. For anyone else, always when trying to write your mods, for heaven sake, comment what you're writing. Even if it is just a personal copy of the mod. The way I code for applications, I comment everything. Especially when I start out with a new language, like I am now. The thing is, you will invariably become better at what you're doing. Much better. At that stage, if you ever look back on old code, you really wont have the foggiest what the hell was going through your mind when you wrote it. Sometimes you may not even recognise what its doing, or how. These comments will help you if you have to go back to fix a mod. Maybe one you havent needed to touch for months. One that's become broken when blizzard automagically breaks the function calls you're making to the underlying LUA system.
Step 5 -- Stripping and optimisation. This is something That I'll be doing much more of in LUA than I do in other languages. I'm used to ;s, bracketing and heavy commenting. I can't help it, its just how I know how to program. also commenting any code thats shared in a project gives an undeniable advantage to others trying to work out (A) what you're doing and (B) why you're doing it that way. Thus I'll write my programs with all this in mind. After I get the mod to do what I want, I'll archive a copy of the file. Coments, semi-colons, brackets and all. Then I'll procede to strip every last unecessary character out of my files. This reduces my file sizes by about 20-50% depending upon how large the mod I've just written is. Given that at least 50% of the Ace way of coding is all about code efficiency and optimisations, this just gives your mod that much less time be read and loaded. As they say; Less is More. Also at this stage, tis good to look for any functinos, statments, conditionals, etc that you could shrink down. Often I'll have superflous catches on if statements which where made for clarity, but are now no longer needed.
for example
if Foo if Bar do something end endcan be written as
It doesnt look very messy here, but when you're dealing with several conditionals at once, it can get messy quickly. To LUA though, messy code is not necessarily bad. As long as the logic is the same, you can put it all in one lump, or several lumps. The thing is, often, one lump is usually better -- since it takes less space. The problem with lumping code in this way though is it can soon descend into an unintelligable mess to the human eye.
Anyway, I hope at least some of that will help a little. Getting started is always the hardest part, but stick to your guns for a few weeks, and it'll start to seem like second nature to you.
I has an extreme passion for teaching, troubleshooting, debugging, optimization, etc. Its not easy to distract me with a nice puzzler =), which may or may not be a good thing.
Above all, the way to be successful-- utiliize your resources.
Yeah, that'd be soooooooo nice. But until then, archives will suffice. If i were working on *nix or *BSD I'd be running some versioning system of some sort, like arch. But im not, I'm relegated to windows. Still, at least my new Power Mac should be arriving in a week or so. I should probably set up something like that if im gonna start up on AceBar though for stable and dev branches.
Stun, there is an Ace SVN that you can use, and there are good SVN clients for windows that work quite well.
I wonder: I know it defeats the purpose of commenting the add-ons myself, but in the classroom section on the site, could we post commented code and files for examples?
So many times, I'm trying to figure out how to do something, so I will look at someone elses code to see how they did it. Many times this only raises more questions, compounding the issue into a brain meltdown. If there were commented peieces to reference, this would aide many of us in the writing process I feel.