Re: Some Programming And Android Questions
You may wish to look at ruby motion. Ruby motion was working on Android support. You can't share all the code, but you can maybe at least share the language. This is not free, but it's possibly the least painful approach to iOS development. I'm suspicious of anything with the word "basic" in its name. "basic" usually means exactly what it says-programming language minus stuff to make it simpler but less expressive. Java is at least as easy as BGT, possibly easier. Just learn java. If nothing else, it's a marketable skill and it's not that hard.
Edit: I'm putting this here because the rest is kind of off topic. Let's see what I can find that talks about why android is bad. O, I know, how about this: 30 days with Android? Especially see day 18. This is by someone who is very high up in Mozilla's
accessibility department and who was involved in getting Firefox on Android. Or this one, by a former Freedom Scientific employee Testing Android Accessibility: I Give Up. And as for things I can do better than you? Reliably turn on accessibility in the first place, select text, use my phone without installing an alternative web browser, home screen, ebook reader, and probably a few other things I don't know about, crash accessibility services by turning them on in the wrong order? And that's not even getting into the bugs that exist in the core accessibility APIs that developers are supposed to use. I do not count "install the 15 alternative apps", I do not count "but there's workarounds if you do x, y, and z." But that's moot anyway-most blind people are on iOS, end of story.
And the rant about object oriented programmin
g. I have to address this, because it's wrong. If we call this my opinion, we're going against the overwhelming majority, so please keep that in mind.
Upwards of 50 years of people getting it wrong and figuring out that we need something better should just be thrown out, too. I mean, pointers are annoying, so let's get rid of memory allocation. Passwords are annoying, so why not kill those too? C++ is not object oriented programming. C++ has problems, sure. But having a hard-to-remember manual? Not really-unlike many languages (say, java), there's a lot of consistency in it (i.e. every container that can support iteration is going to have a .begin and a .end, and every iterator looks and works the same). Also, documentation for it is much, much better.
Object oriented programming is exactly three features, nothing more. Classes: a method for grouping related functionality together in such a way
that we can basically make multiple copies of it. Inheritance: a method for saying that a dog is an animal and can do all the things animals do. Polymorphism: the ability to treat dogs as animals in all places of the code wherein an animal is needed in such a way that the code has no idea it's a dog (all animals can move, for example). You may implement this much with macros, but 99% of object oriented programming languages allow you to automatically run code when objects "die" and, in many cases, you don't even have to worry about when this happens. They also typically offer other stuff that makes life easier--for example, interfaces. Here's a pretty typical thing in C++, other languages like BGT and Java make the syntax much cleaner and the semantics much simpler, but I'm not set up to trivially test code in them and I don't know the syntaxes off the top of my head:
//this cl
ass represents tickable things.
//notice that we do not say what it means to tick.
class Tickable {
public:
tick() {
registerTicker(this);
}
~tick() {
unregisterTicker(this);
}
virtual void tick() {
}
};
class Thing: public Tickable {
virtual void tick() {
cout<<"Ticked!"<<endl;
}
};I leave the implementations of registerTicker and unregisterTicker as an exercise. But any creation of any class that inherits from Ticker could now automatically begin ticking as needed. If you then implemented a mainLoop function, you could create your ticking game objects and call it, and they'd all automatically just work. In java and most other languages, the distinction between pointer, object, and reference to object is all gone-it's even simpler there and, for example, you'd not need to unregister. The biggest point here from a practical standpoint is that you don't have to remember to unregister objects anymore-in a language with a GC, you needn't even remember to delete them.
For a really good concrete example of why object oriented programming is good, look at Diku: almost every function has at least 10 or so ch-> in it. If nothing else, object oriented programming provides a very, very
nice way to not have to put all the ch-> in. Wrap them in a class and remove all of them, no problem. The other benefits can come later when you understand why you want them.
Its pretty clear that you don't see why a bunch of stuff would be useful, and are consequently assuming that that means that they aren't. Lack of understanding is not lack of use. If I said that algebra was useless because I didn't understand it and then refused to even study it at all, I'd be missing out on a great deal. Having conceptual difficulty with something is not the same as that something being pointless and, in this case, 90% of programmers will disagree with you.
But really, since at least 80% of programming languages are object oriented and since at least90% of them support it in some manner, I feel very justified when I say that you're wrong in the objective case. Do you always need or want object oriented programming?
no. But do you want to live without it, especially since 50% or so of problems are trivially cleaner when written using classes? I doubt it. Until you get it, you can just look at it as very helpful syntax for a very common task.
Object oriented programming is not C++. I think that everyone agrees that C++ is really bad, in a way. C++ and all the languages "like" c++ are two very different things-people realized this and most efforts these days end up with something much better. I'm sorry C++ bit you, but it wasn't because it has classes. It was probably because C++ is about 25 years old, is close to the machine, believes that it should never make programmers pay for features they don't want, and intentionally refuses to hide machine architecture. You can program exactly as you do in PB in C++--no classes, no problem.
Assuming that you're not going to have to look at the manual is naive, however
-anything capable of doing all the things you're talking about wanting to do is going to virtually require having the manuals open while you code. You're not supposed to memorize them. You're supposed to simply know the high-level picture (there's a package for linked lists) and when each piece might be useful (we're going to add stuff to this array all the time, that involves copying all the items, o, look linked lists). You then go and figure out that part, with a careful thought to whether or not you're using too much of the language. Or you bring in some external libraries if it's not there. C++'s stdlib is actually pretty small: BGT's is bigger. So is Go. Java's is huge, probably the biggest of them all (Java gives you everything, and I mean it. 2 ways to do GUIs, sound, 3 or 4 ways to do network I/O, xml, adding other scripting languages...).
I'm going to close with this
. Suppose we have two languages. One language doesn't have classes. The other has classes, but it also has all the other things from the first. These two languages can accomplish the same sorts of tasks. While this can be taken too far, there's no reason why you wouldn't take the language that also has classes, especially since classes are a tool with a lot of uses. If you can admit that C is more expressive and powerful than assembly, you are more than 75% to realizing that some languages are more expressive than others. This is one of those cases, hands down. There's no argument.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
