A Good Article For You Budding Scripters

[BigEd781]

Here is a great article for novice programmers to read. It talks about "cargo-cult programmers", a term that has been around for some time, but usually the people who need to understand it the most do not. There are more than a few beginners around here who this applies to, and that's ok; you're learning. But if you would like to get ahead of the curve, reading this article can help.

http://blogs.msdn.com/ericlippert/archive/2004/03/01/syntax-semantics-micronesian-cults-and-novice-programmers.aspx

Here is an excerpt:

During the Second World War, the Americans set up airstrips on various tiny islands in the Pacific. After the war was over and the Americans went home, the natives did a perfectly sensible thing -- they dressed themselves up as ground traffic controllers and waved those sticks around. They mistook cause and effect -- they assumed that the guys waving the sticks were the ones making the planes full of supplies appear, and that if only they could get it right, they could pull the same trick. From our perspective, we know that it's the other way around -- the guys with the sticks are there because the planes need them to land. No planes, no guys.

The cargo cultists had the unimportant surface elements right, but did not see enough of the whole picture to succeed. They understood the form but not the content. There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.

Beginner programmers: do not go there! Programming courses for beginners often concentrate heavily on getting the syntax right. By "syntax" I mean the actual letters and numbers that make up the program, as opposed to "semantics", which is the meaning of the program. As an analogy, "syntax" is the set of grammar and spelling rules of English, "semantics" is what the sentences mean. Now, obviously, you have to learn the syntax of the language -- unsyntactic programs simply do not run. But what they don't stress in these courses is that the syntax is the easy part. The cargo cultists had the syntax -- the formal outward appearance -- of an airstrip down cold, but they sure got the semantics wrong.

 

[Mouser]

Nice read.

Algol 68 Haven't heard about that one in a long time.

Edit: I may as well actually say something about the topic

This is so true - especially when you're working on (modifying) code that you didn't write, like the existing RGSS classes and modules. With code that you've built, you know why things are the way they are (if you don't, then you've got bigger problems than this essay is talking about), because you're the one that made them that way. With someone else's code, you have to figure out A) what the code does, B ) how it does it, and C) why it does it that way. A is easy. B can be slightly harder. C is the tricky one - especially if the coder approaches the problem in a different way than you would: an old fart who learned to code before OO programming was even a twinkle in its father's eye is going to naturally tend toward different algorithms and solutions than someone whose first language was Perl. That doesn't make one method better than the other - in fact both are right or wrong depending on the situation: procedural and OO programming both have their place, along with all the other styles that have developed over the years. Except BASIC - that was just plain wrong. Horribly, horribly wrong.

Concrete example: I'm going through the RGSS structure piece by piece now. One of the first things I find is in the DataManager module - a slew of global variables. I would not have written the code this way. At the same time, I've got to have some faith that the people who did code this know the Principles of Good Program Design™, which clearly state: "Global variables are bad, m'kay?"

Let's say I want to rewrite this without using global variables. I still have the question of "WHY did they choose this design route?" Until I figure out the answer to that question, I can't confidently go and change the code. So I read, and I study, and I look at the other modules and classes and how they all fit together until (hopefully) I'll understand the reasons they took this route. Then I'll be in a position to know whether or not it should be changed, or even if it can be changed. At the same time, I'm studying Ruby syntax and semantics, which I'll also need to answer that question and decide what viable alternatives, if any, there are.

 

[izanamikun]

I know this is quite a necropost, but this article is pinned at the top of the forums so it attracts some attention. While the article is a great one it doesn't really point the way to exactly HOW to do this. For those of us brand-new to scripting and languages in general, the only way to learn *seems* to be fragmented at best. Are there any good scripting tutorials that focus on understanding semantics rather than syntax? I'm sure there's plenty of them in here, but since this post in particular is pinned to the top, it makes sense to link at least one of them here. Thanks in advance!

 

[kerbonklin]

I'm pretty much past this stage, unless it involves memory addresses and such. lol

 

[Andar]

While the article is a great one it doesn't really point the way to exactly HOW to do this. For those of us brand-new to scripting and languages in general, the only way to learn *seems* to be fragmented at best. Are there any good scripting tutorials that focus on understanding semantics rather than syntax?

I don't have any links to tutorials ready, but what you need to learn is how to create a "flowchart" of your program - that is the first step for functional programming (there are other programming styles that go beyond flowcharts, but as a beginner you need to start here before learning object oriented programming or other advanced methods).

Flowcharts are about logic sequences and have nothing to do with syntax - only in the last stage (implementation) they're turned into the program code with the correct syntax.

The following is a flowchart of the damage sequence in Ace as an example - that's how you start structuring your ideas and what you want your script to do, before you turn that into a real program:

http://forums.rpgmakerweb.com/index.php?/topic/4219-rpg-maker-vxace-damage-flow/

 

[izanamikun]

Oh, well that's awesome, I was doing that anyway. I write often, and outlines are kind of a thing for me so I've been doing that with events (sometimes what I want to do gets confusing without scripting to make it easier) so I was already doing that. So what you're saying is that most programming  follows these sorts of rules as a logic-based outline of sorts, yes? Thanks so much for that, I can understand why it might be harder to find books or tutorials on that sort of thing. Ha, maybe I should try to make one since I'm learning it anyway.

 

[MobiusXVI]

While the article is a great one it doesn't really point the way to exactly HOW to do this. For those of us brand-new to scripting and languages in general, the only way to learn *seems* to be fragmented at best. Are there any good scripting tutorials that focus on understanding semantics rather than syntax?

When I was first learning Ruby, I used this free book to get me started. http://ruby-doc.com/docs/ProgrammingRuby/

It does a fairly good job of explaining Ruby even to someone without any coding experience. It also emphasizes good coding, and even shows you different ways to code the same thing and explains why one form is better than the other. The one downside to this book is that it's written for Ruby 1.6, but RMXP uses Ruby 1.8 and RMVX and VXAce use Ruby 1.9. But 90% of the info is still accurate, and if you're looking for a good entry into coding Ruby, this is it.

 

[BigEd781]

I know this is quite a necropost, but this article is pinned at the top of the forums so it attracts some attention. While the article is a great one it doesn't really point the way to exactly HOW to do this. For those of us brand-new to scripting and languages in general, the only way to learn *seems* to be fragmented at best. Are there any good scripting tutorials that focus on understanding semantics rather than syntax? I'm sure there's plenty of them in here, but since this post in particular is pinned to the top, it makes sense to link at least one of them here. Thanks in advance!

Well, you're already on the right track; you need understand concepts (semantics). Don't worry about finding "scripting tutorials". The one thing that many in this community seem to miss is that Ruby is the language we are using here. If you understand Ruby then using RM is just like learning any other code base, there's no difference. Start at the beginning, learn the language.

 

[Ghaleon]

Necropost, just read this and found it to be relevant to an experience I've had.

Basically I took C++ programming after I graduated highschool, and I was doing great. Consistently getting top scores on tests and assignments, my brother 6 years my senior who only became interested in programming AFTER I was but had the opportunity to try and learn it professionally first since the age gap was swearing up and down that pointers were like the most complicated difficult to grasp thing ever...But I thought them to be no more complicated than any other basic concept.

Then came along the part where we started using Win32 and MFC... I was immediately dumbfounded with all the %@#@%#%@ that was automatically inserted into a fairly basic hello world (in windows, like not a console window). I just couldn't figure it out, and I was basically taught not to bother, just that it works, just use it... Eventually I managed to get some footing but I was no longer the star student, and I was often struggling just to be satisfactory in certain areas. Obviously working with DirectX was similarly difficult but it wasn't as nasty for me.

I never really did understand win32/mfc/directx as much as I would like to admit, and more often than not I would fiddle with existing code that works regarding them hoping for certain results without being 100% confident. This is basically why I never proceeded to try and make anything for myself using my coding knowledge after I graduated.

I'm curious, do anti cargo-coders think win32/mfc is an exception, and that they are GIVEN to be treated like that by virtually everyone? Were my instructors wrong in actually assuming that all their students would have this mentality with those tools, and pace their courses in such a way that there is no possible way to learn them in time to that extent before we were forced to use them? Just an example, when I learned win32, I was only given one 3 hour class, some basic homework over the week, and then during our next 3 hour class, we were told to make a tic-tac-toe game in windows using win32.. so 6 hours after even HEARING what win32 was for the first time. 

I kinda expect people to say "Well yeah, nobody really knows all of win32/mfc", but hope otherwise.

 

[BadMinotaur]

In my very limited experience with the Win32 API, it was a hideous mess, BUT there was a method to the madness. It was a buried method hidden under mounds of dirt and other madness with methods, but it was there.

 

[Tsukihime]

I'm curious, do anti cargo-coders think win32/mfc is an exception, and that they are GIVEN to be treated like that by virtually everyone? Were my instructors wrong in actually assuming that all their students would have this mentality with those tools, and pace their courses in such a way that there is no possible way to learn them in time to that extent before we were forced to use them? Just an example, when I learned win32, I was only given one 3 hour class, some basic homework over the week, and then during our next 3 hour class, we were told to make a tic-tac-toe game in windows using win32.. so 6 hours after even HEARING what win32 was for the first time. 


I kinda expect people to say "Well yeah, nobody really knows all of win32/mfc", but hope otherwise.

I don't think most instructors expect you to fully understand the framework/API/tools that you're using; you just need to get the basics down to the point where you can comfortably produce something.


And then when you're sure you know how to create a window, you can then go ahead and wonder why the code you're writing does what you think it does and whether there are alternatives.


Trying to understand how things work before you even know how to work it, doesn't really seem very logical to me.


This is not limited to win32/mfc, but maybe your experience was a lot worse than I'm thinking.

 

[BigEd781]

Trying to understand how things work before you even know how to work it, doesn't really seem very logical to me.

Well, it's an iterative process. When learning something new, you start writing your implementation of [whatever], but when you come across something you don't understand, you look it up. Only once you have a relatively good understanding of why your code does what it does do you move on to the next implementation step.


Learning by doing this way has always worked best for me.

 

[maoyurui]

Hello I'm just new here. I've been going in and out of this site for tips and such for making my game in RPG maker VX Ace. Granted I'm not a programmer but I am curious on trying to make a script that I might use for ACE. But that's another story for now.

My native language isn't english so forgive me if any of my spellings and grammar are off. My interest got piqued on this pinned topic after I finally decided to registered here in order to ask a question related to a game I want to make (Again that will be another story).

The thing is after reading the linked article it does show the importance of learning the basics. Which I would also like to learn because as I said I'm no programmer. The point of the author is also true and setting the example of the plane/cargo is quite good. But I want to give my own humble opinion on it.

There are somethings I wish to point out as someone who isn't even an american and someone who grew from the pacific (South Pacific to be exact) that I think the guys missed. These are The language barrier, how people adapt to learning and most of all the teachers.

To set an example a native english speaker who knows nothing about programming versus a guy who also do not know anything about the same thing yet is just mediocre on the english language would have even a hard time learning something from a book that is not written on his own language.

Even if we give the later the highest enthusiasm in studying the language barrier would only slowdown his learning curve or worse will actually dismay him from going forth with it. But I'm not saying this to be always true though since I'm just pointing it out in a more realistic scenario of an ordinary man.

Another case in point would be how the Japanese always have their instructions and teaching manuals on their own language giving them a bit of an end and with that even instructors that teaches them on their own native tongue.

Then there is also the factor of how each people can actually learn. Some people learn faster by practical lessons. This is often can attributed by the fact that they can always ask on the spot on what they don't understand, something that a book can't do. In other words simplification.

Hence most of the times base by experience, video tutorials make it more easier to learn than let say pointing someone to a book who may or may not be able to access by someone who wants to learn. The visualization is sometimes more useful than reading.

Anyway I hope I didn't offend anyone by my post. If I did I deeply apologize but I assure you it's not my intent. I was just giving my own opinion on the topic at hand so that it may shed some things that people who are eager to teach may think to improve their teaching method. Although most probably one would just point someone here to a reference site or book to read.

In the end though the message of Learning from The Basic first is true indeed and in that note I do agree on the article linked here. Again my apologies if my english is insufficient and lacking. As I said before english isn't my native tongue. Thank you and have a nice day to all

 

[Balrogic]

Hence most of the times base by experience, video tutorials make it more easier to learn than let say pointing someone to a book who may or may not be able to access by someone who wants to learn. The visualization is sometimes more useful than reading.

I actually have the opposite problem where it's far more difficult to learn by video tutorials. I have a neurological disability that makes it difficult to process spoken language and tend to get horrific headaches when I try to learn that way. That said, you may want to try Youtube.

https://www.youtube.com/playlist?list=PL1512BD72E7C9FFCA

I can't verify the quality for obvious reasons but the viewers seem happy with the series.

 

[Andar]

Hence most of the times base by experience, video tutorials make it more easier to learn than let say pointing someone to a book who may or may not be able to access by someone who wants to learn. The visualization is sometimes more useful than reading.

While I agree that video tutorials can be most helpfull in a lot of cases, this specific case (programming tutorials) they are a lot worse than books.
When you program, you need to WRITE the code - and it needs to be exact. Having a written tutorial where you can read the needed code is a lot better than a video tutorial where you have to speed-guess what part of the written code had been recorded.


There were cases here on this board where someone got errors in the code he believed to be the same as in a tutorial video - but in reality he mixed up [] with () - those are two entirely different functions in code, and in the video it was simply impossible to see which was used where due to bad resolution (and only minimal difference).


Second problem with videos is that it takes time to write down code - most videos are simply too fast to allow the pupil to write the code without stop and rewind. Having a written code is a lot easier to learn than watching a video.

 

[Lemur]

There are those people (if you live in the states you know the type) that will go out and buy expensive running clothes, workout equipment, new shoes, treadmills, gym memberships, and the entire works. Sure, they look sharp enough in all that getup, but they're not getting anything done until they actually start working out now are they?


You can watch / read as many tutorials and articles as you want, but none of it counts for anything until you actually apply it constantly. The biggest mistake you can make is to go through the early sections of programming without trying to implement anything with them. Even if it seems easy, you're going to forget what you don't practice yourself.


This is why even a few months of professional experience after College makes such a dramatic difference in programmers. When you're out in the field, you have to apply it. That's how you get good.


Now that being said, using tutorials to supplement and learn new things is great, just make sure to apply them.


If you really want to get a good idea of practical applications and what happens in the real world, look at conference videos: http://confreaks.com/ . That's where I've learned some of the most useful bits of information by far. Working professionals talking about their work and what they do.


Honestly I find myself very skeptical of online blog posts and tutorials. Rarely are they tested, reviewed, or anything in between. There's great value in a good book coming from a good publisher. Having a subscription to Safari Books Online has proved to be an invaluable reference in professional work. I don't know how to make practical applications in Haskell? There's a book for that. Do note it runs $29 a month, but I've found it worth every dollar.

 

[Maximus32]

Wow, VERY interesting article!

Occasionally, I do fall into that loop of randomly changing variables and such because I'm too lazy to try and understand how the scripts actually work, and I see how that's such a waste of human talent and ingenuity. We have such powerful and creative minds and we should never stop looking to challenge and exercise our brains: I think programming is an excellent way to do just this.

However, programming can be tricky and intimidating for a newbie, as the whole idea of coding is expanding at an ever faster pace--there's just soooo much information out there and it can be overwhelming. Sometimes I feel like I need to learn new material and produce or fix my code faster and faster, which only causes me to take all of those beautiful intricacies and abstractions for granted and resort to cargo-cult practices, haha

One thing I realized is how I should always try to understand the code and ask 'why?' more often when programming

Thanks for posting this!

 

[JaiCrimson]

The problem with this is that nobody chunks the learning process into easy to digest sections for newbies. If I only wanted to learn bit by bit at a time - just learning to understand the small parts that apply to whatever I happen to be working on - well, I can't. I've tried to find specific information so many times now and every time it just spirals further and further until I'm trying to learn the entire Ruby language just for one conversation. Yeah I want to understand modules and classes and arrays and how to define variables but having to learn every single form of expression and notation seems a little excessive if I just want to tell the engine to make my name always appear in orange... (I dont actually want to do this its just an example. xD) Eventually though I'd expect the bits to come together and become a larger understanding as I take on more and more complex tasks. Does this make sense to anyone??

 

[Andar]

We understand what you want, but unfortunately it can't work that way.

It's like you saying "I want to learn another language to speak with the people in another country, but I don't want to learn everything - can't I get away with only learning twenty words first?"

As with any language (no matter if computer programming or speaking) everything is connected. It is possible to ignore the advanced part (for example if you don't want to enter a theological discussion you don't need the vocabulary for theology), but you have to learn the basics (grammar, at least several hundred words to talk) first.

You simply cannot get away with a smaller part if you want to use the language at all.

And with the computer (where an entirely different kind of logic is neccessary to learn programming) that minimum is a larger part of the total language.

So no, you can't learn tiny parts and specific commands until you've learned the basic structures of the programming language.

 

[Kes]

Could I suggest you have a look at Slip into Ruby?  Trihan has done a good job of breaking it down into manageable chunks, and explains things (together with giving examples for you to do yourself) so that you can get the basics in a straightforward way.

I am not a scripter, by training or inclination.  I have struggled with understanding even the most rudimentary things.  However, since starting these tutorials, things are making a lot more sense, so I'm recommending them from personal experience.