One interesting phenomenon I've been seeing lately is people new to REALbasic jumping right in and starting out with the advanced topics before getting a solid footing. I'm not certain what causes people to want to do this, but when you do it, you're not doing yourself any favors.
For instance, I've seen a number of people asking questions about how to do various low-level declares. Ok, that's not strange and good for them! However, I find out a number of posts into the discussion that a major source of confusion for the user is with datatypes. Like how the integer constant 0 is not the same thing as the boolean value false. Or that you must use returned values. You should not be working on declares if these concepts are the stumbling blocks because you'll end up frustrating yourself more than anything.
If you're just starting out with REALbasic, my suggestion for you is to start with the tutorials. They're a good way to get comfortable with a lot of the basics of the language (which aren't that hard to learn). Once you've become more comfortable with the semantics of the language, then the more advanced topics like declares will be a lot less frustrating.
Uh....theres a power switch?
"Like how the integer constant 0 is not the same thing as the boolean value false. Or that you must use returned values."
I'd bet these are people coming from a VB.NET background because both of those are valid in VB.
As to people jumping into the language too quickly (eg biting off more than they can chew), I think all RAD languages suffer from the same thing. The very easy acutally plays against the user in this case.
What's worst is that they don't even bother to search available support sources for solutions. 99 times out of 100, your questions isn't unique, and you're not the first one to have ever run into the issue ;)
The Realbasic Forum (to name one) is loaded with lots of cool and imaginative solutions.
Cheers, Jordan
Jordan, that's universally true (you'll see the same comments on the Cocoa mailing list). Answers are out there if you just do a search in a browser.
However, we also need ot think about the format of that answer. There's always a bump in the road for programmers (in any language) once they get to the intermediate-to-advanced level -- material gets harder to find and it's less comprehensive. The programmer is left more on his/her own to figure it out.
I've also found that there's a gap between beginning and advanced material that's never explained as well. There are too many beginner's books that don't venture beyond this level, and a few wonderful advanced articles or books, but sometimes it's not easy to make the leap between the two. An example is compiler books: some are simple and practical (with code), but only explain toy languages, while a few are highly technical but have no concrete examples of handling classes, multiple inheritance, operator overloading, multithreading, etc. There's no middle level of "here's how to take the beginning material and extend it to get to the advanced material".
Well, in the "olden days" zero was false and non-zero was true, so why should RB flip its nose at tradition? Besides, recently I tried to create a SQL statement for a RealDB table and had to use "...and defval = 1" because "...and defval = true" wouldn't work. And yes, defval was defined as a Boolean column.
And why should I have to use a returned value? Shouldn't the compiler/language be smart enough to toss it aside if I don't explicitly ask for it?
I understand (and somewhat agree) with your point, but the reason I don't usually do many tutorials is because I don't have time -- I typically pick something that I need to create and start putting it together with the new language. It'd be nice to work through all the tutorials first, but who has that much time?
Jay
@Jay -- because it makes the programmer *think* about their code while not "getting in the way." It makes for safer code, basically. Compilers are actually quite stupid things; translation devices, essentially. The progammer is always smarter than the compiler. So making the programmer be explicit about what they mean always equates to better code.
That is why I think that there should be something of a Programmer's FAQ. Answer the 25 most common questions for the following subjects: REALbasic Newbies, Advanced Topics (prior programming experience), Graphics, Cross-Platform development, Databases, etc...
@Jay -- you technically do not *have* to use the return value. There is a "Call" statement in REALbasic which allows you to call the function with the purpose of ignoring the return value.
Oh, and I should have added another topic... differences between REALbasic and other programming languages.