Slashdot Mirror

And yet again you uncritically take promotional language as true. As someone who actually uses one of the languages supposedly supported by Dragonegg, I would say it would behoove you to look beyond the advertising copy.

Interesting, so you knew non-C languages were supported when you claimed otherwise. From dragon egg's current status, it works very well with Fortran and works well with Ada when using gcc 4.6. http://dragonegg.llvm.org/

Some benchmarks from 2011, so working with Fortran isn't a recent achievement. http://lists.cs.uiuc.edu/piper...

MacRuby (Apple is a contributor to the project) would be another example. http://macruby.org/

Me calling you a dumb fanboi is not angry name calling. It's a statement of fact, which you thankfully keep proving with every post.

As unreliable a "fact" as your "fact" of not being able to use non-C languages. Seriously, what gets you so outraged over the idea of being able to use either gcc or llvm, over the idea that llvm is usable with Fortran, Ruby, etc?

In the present context at least, Objective-C seems like an even better counterexample, given that its syntax, however convenient, is not required to use the underlying object system provided by the lightweight runtime.

On reflection, you're right, I was being sloppy and imprecise with a point that was tangential to the main topic I was discussing. My apologies.

(But I will point out, you are wrong to accuse me of being "so convinced" that every single indie game is developed in C# -- I explicitly wrote "as far as I'm aware", because I was perfectly aware that my information could have been incomplete. Thank you for the very specific pointer for the IronPython example. I have been keeping an eye on XNA for a few years now, contemplating whether or not to "dive in", and that's the first reference I've seen to anything other than C#.)

So, here's the situation as I now understand it, with more precision:

If you just say "XNA", you're being imprecise. There are XNA frameworks. There are asset management tools. There's "XNA Game Studio". There is (was?) "XNA Creator's Club".

It's built on the .Net CLR. That is, at its core there's a VM, similar to the JVM, the "common language runtime" one that .Net uses. The frameworks are available via CLR -- if you want to use them, you need a language that "participates" in the CLR fully, seeing the objects and methods that are available in it.

The frameworks are analogous to the iPhone OS frameworks (Cocoa Touch, Core Foundation, Core Data, et cetera). The "Game Studio" is analogous to Xcode.

Here's the thing that's important to get: the "niche" occupied by the CLR in XNA is occupied by the Objective-C runtime in the iPhone OS. If you use most languages other than Objective-C, you're doing the equivalent of using a language that can't participate fully in the CLR, that can't see objects in it, that can't directly invoke methods on the frameworks exposed through it.

I had thought that C# was the only language in actual real-world use by XNA hobbyists. I will say it's certainly the one I see being discussed the most, documented the most -- heck, the "getting started" instructions I've seen all discuss using "Visual C# 2008 Express". In all the discussions about XNA I've seen or participated in, C# was assumed. But other languages aren't explicitly forbidden, and apparently they do get some use.

That is in fact the situation I'd like to see with Apple, if you're careful to keep the analogy intact. You can use any .Net-ish CLR-ish language with XNA. You should be able to use any non-interpreted language that uses the Objective-C runtime as its runtime for iPhone development.

Now, this isn't in fact a large set of languages right now. The reason C gets included is because Objective-C is pretty much a superset of C. The reason C++ gets included is simply because how trivial it is to link between C and C++. I do not recommend doing much iPhone development in C++ -- the OO systems are not compatible. This is not a way to avoid Objective-C. You end up using both, in order to get any work done, and the objects that the frameworks see and interface with are going to be the Objective-C ones. But you can use C++ for your "model" objects if you're careful, and this is actually valuable because of C++-based computational libraries/frameworks that exist out there.

(This is why things that map between a language's objects and C++ objects would not be sufficient. You're not getting the required Objective-C-like behaviors that way. You don't even get them in C++ itself, and Apple has been mixing C++ and Objective-C for many years now!)

Beyond those, MacRuby is the most obvious one. It actually compiles Ruby, and uses the Objective-C runtime and garbage collector to get its job done. It's also by Apple. There's no reason it shouldn't be supported... except that it's only up to version 0.6 right now.

http://www.macruby.org/

The limited information I have regarding MonoTouch leads me to believe something similar i

#1 and #2 don't seem like they would be a problem, and again, I don't necessarily have a problem with this. It's not ideal, but it works -- though I would much rather they enforce the runtime than the language, so we can use things like MacRuby.

#3 is the retarded part. Xcode uses gcc as a compiler anyway. Why shouldn't I be able to use a third-party IDE, or even a third-party language that has Xcode support?

Honestly, I have never seen the Flash converted projects so I can't comment.

That's beside the point. It would hardly be less asinine for Apple to simply ban Flash-converted projects, but they don't even need that. They could easily reject projects which have been Flash-converted on the basis of the actual shoddy code, not simply because they've been Flash-converted.

The real point here is that they're now dictating what tools you can use to an insane, OCD, micromanaging level. This means they're now disallowing anyone from using any third-party preprocessor, Flash or not, even one written specifically for the iPhone.

Let me put it this way: If I don't like some aspect of Javascript, I can always write a preprocessor for it. Hell, I don't like working with raw HTML, so I use things like Haml, which actually output better HTML than most people do manually. But if I don't like some aspect of Objective-C, Apple is effectively telling me tough, I either use it exactly as given or leave the iPhone.

They can probably pull it off, but it's a dick move, and they absolutely are swinging their weight around and using and abusing every bit of good will and marketshare they have.

If what others have said is true - Adobe simply wraps Flash run-time into ObjC wrapper - then it is only given that Apple would be pissed. If Adobe really translates Flash project into a ObjC/Cocoa one (what is very highly unlikely) then the Apple's wrath is really unjustified.

Also beside the point.

Again, if there's something wrong with the generated code, they can simply enforce coding standards which disallow it, and reject apps on that basis until Adobe fixes it.

The problem is that with this ruling, they've disallowed any implementation of the latter option, by anyone, for any purpose -- it's not just Flash, it's everything.

Yes, it is used less right now. But it has support from Apple and Sun. I still prefer Python, but it is a fun language and now seems to be a long-term player.

I heard Rich Kilmer talk about the various Ruby implementations once; his take on them were that each would be used to leverage the underlying platform. In other words, if you want to use Java libraries, you'll use JRuby. If you want to use the Mac libraries (e.g., via Hot Cocoa), you'll use MacRuby. And if you want to use C extensions like RMagick and libxml2, you'll use MRI.

I thought that was an interesting way of looking at the various implementations... each one would be appropriate for a different scenario.