Both id and void* are part of the language. Both are avoidable. But of course we end up using them if the library uses them.
With Obj-C you end up using id when you use Apple's Foundation library collection classes.
OK, technically the standard library is not Obj-C, but you'll have a pretty hard time not using it for most purposes.
With C++ you are using them with printf. The first parameter is a char*, and then you implicitly have an unlimited number of void* parameters. And if you get the type wrong, they'll only fail at run time.
Technically printf is a variadic function, not one which takes a void pointer. The functions dealing with direct memory access (memset/cpy etc.) use void pointers obviously, but I can't think of any others off the top of my head. Using void pointers is a choice. Random aside: you can write a completely statically type safe printf using variadic templates.
Obj-C for example has categories, which allow you to extend the functionality of a library class - even if you don't have the source for it. C++ can't do that. It can only subclass. Which doesn't help if someone else's code is creating the class in the first place.
C# and Java can do this. Not really sure what you're getting at to be honest...
Not necessarily. id is what makes Obj-C somewhat weakly typed. But C++ has void* which has less type information than id does.
Yes, you can choose to use void pointers and subvert the type system if you so wish. That's a pretty dumb choice though and you deserve everything you get if your programs end up error prone. Obj-C's id type is an integral and unavoidable part of the language. Comparing the two things is a bit silly I think.
For sure, they both smell of the 80s. Obj-C is far from perfect. But it's much nicer than C++.
I think we'll have to agree to disagree. Both languages need to die off, but potential successors should resemble C++ far more than Obj-C.
You treat a pointer to foo as if it's a pointer to unrelated class bar, it'll fail more often at runtime in C++ than in Obj-C.
Of course strongly typed languages can fail at runtime; I'm not suggesting they don't. What I am saying is that having a strong type system makes you more likely to catch the failures at compile time. The hypothetical you've just stated would require an explicit reinterpret_cast to get a foo pointer to point to a bar i.e. you're asking the compiler not to point out your mistake.
What I think you meant is that the C++ compiler will catch more programmer errors at compile time than Obj-C the compiler will. But with the standard Obj-C compiler front end being LLVM now, the reverse is true. LLVM Obj-C compiler will catch far more programmer errors than the standard GCC C++ compiler.
I said it elsewhere, but the compiler can only compensate for the failures of the language -- it can't fix them. When the language allows you to fail exotically at runtime in ways that are statically unpredictable, the compiler is irrelevant. Almost all languages except for the strictest functional ones have these failure modes, but weakly typed languages have them more. Out of interest how would you rank LLVM Obj-C against LLVM C++?
On top of this, Obj-C allows techniques such as introspection that are just not available on C++.
That's not entirely true. Qt (the widget library) is an example of a C++ based code base that does introspection. To be honest though in my career I can only think of a handful of times where introspection has been useful and in most of those cases there were better solutions to the problem that didn't need it.
I'm kind of coming out of this sounding like a C++ apologist; I'm really not. Objective-C is not the answer though. It smells of the 80s.
To some extent I guess; it depends how confident you are in your code. At the extreme end of functional programming you can prove that a certain program is correct before you even run it. This is very hard to do with a dynamic language.
It gives it scripting-language agility and introspection with compiled language speeds, and still most of the type checking features are available when you want them, it just doesn't compel them.
C# has reflection whilst being strongly-typed. The two things aren't mutally exclusive.
You sometimes hear this said about Obj-C and it is somewhat true. It's syntax is a little outdated in comparison to some of the more modern languages but other things like the dynamic typing being a big issue are long since history; Objective-C compilers will now give you a lot more compile time information and make these kind of runtime errors largely a thing of the past. Obj-C is far from perfect but it's a much nicer language than the bloated hell that is C++.
Compilers can only compensate for the language's failures, not fix them. Having said that, the 'Analyze' option in Xcode 4 is pretty good.
Language bloat isn't a problem in itself. You are free not to use the features you consider bloat, at no cost. Where it does become a problem is when new language features are shoe-horned with every effort not to break compatibility. The result is obscure new syntax and existing features that should have gone the way of the Dodo. This is where C++11 is, if you ask me.
If you substitute 'uses' for 'requires', the GP is quite correct. It's not like there has been a mass adoption of the language because of the merits of the language itself.
...is obviously because of iOS. More specifically it's because when Steve Jobs rejoined Apple in 1996 he brought with his a lot of NeXTStep tech, including Obj-C. That's why many of the system types have the 'NS' prefix. History lesson aside, it's rather a shame as it's (in my opinion) a rather poor and outdated language. If I'm ever asked by people who aren't familiar with it what it's like I say that it's the anti-sibling to C++. By this I mean that it has the same parentage as C++, but where C++ went down one path, Obj-C took the other. The fact that most well regarded modern languages have more in common with C++ than Obj-C should indicate that they made mistakes in its design. Obj-C's biggest failing is its tendency to fail at runtime rather than during compilation. This is mostly down to its weak type system.
Don't get me wrong, I think C++ is getting pretty creaky too. I'm quite fond of D; in a fantasy world, some big commercial player will start using it and make it popular.
With C++0x we have the mutually exclusive aims of nice syntax and new features. The comes a point where maintaining legacy support impinges on the cleanliness of the language to such an extent that it becomes counter-productive. The whole point of a programming language is to express problems in a legible way. The new "enum class" syntax is a good example of how things can go wrong.
It's not C++ itself I have a problem with; it's that improvements to the language are made without breaking legacy support -- no compromise and at any cost. I'm not singling out C++ either; pretty much every language is upgraded in the same way. The difference with C++ is that it's that old and the changes are that great that the syntax additions become plain ridiculous in some cases. It would be better to start with a relatively clean slate and just-do-it-fucking-right.
I like the look of D as a succesor to C++, but unfortunately it doesn't seem to be getting any traction.
...I'm amazed at how obtuse (and in some cases, downright insulting) the majority of the comments on this story are. I think it's highly likely that if.NET didn't come from Microsoft, nobody would be getting quite so emotional about the whole thing.
For the record, I'm categorically not Microsoft's greatest fan, but you cannot deny that.NET/C# is a damn good platform. Having a portable version of said good platform is therefore a Good Thing. It doesn't matter if Microsoft decide to fuck Mono over; it's still a good platform and therefore still a Good Thing. If you disagree and you don't like it, then fine; don't use it and stop whining.
The common factor with all the games listed is that their code is GPL. UrT doesn't qualify as its game code is still closed source. Depending on your reading of the license, this may constitute a GPL violation.
Alternatively, it could just have been left off as it was written before UrT was released as a single (legally ambiguous, IMHO) package.
I'm not trying to start a war or flaming. I'm trying to point out why people react to you the way they do in the hope that you'll stop making such a pillock of yourself in future. I don't think it's working.
Who is being bitter? It's not me. I don't really understand why you don't get this. It's utterly hypocritical to go complaining about other people posting links to whatever games they like when YOUR post to a GLOBAL website PUBLICLY denounces one particular game in favour of your own. Now this doesn't really bother me in itself, I just find it a bit rich that you apparently want some kind of moratorium on other people posting their own thoughts on whatever game they like, when you're seemingly allowed to say whatever you like.
"When Tremulous was reviewed by this same guy last year, you didn't see *me* posting links to Alien Arena and trashing Trem."
Is the insinuation here that I have been trashing Alien Arena? I certainly don't remember doing so, maybe you can point it out. The only people that are making judgemental comments here are the players themselves; these are the people that you're ultimately trying to appease. If you're not satisfying them, you need to address their concerns, rather than criticising and blaming other developers.
And another thing. You have a pretty strong victim complex going on there. You seem to think that it's only Alien Arena which gets criticism. Look at any other news posting for any other game and you'll find the same repetitive drone of "this game sucks! X is much better!". Get over it, that's just the way it is. By complaining about this phenomenon, you do yourself no favours. You're not engendering yourself toward the players and especially not to other developers. Just let it wash over you and concentrate on making the game better.
Dude, the story that YOU posted unnecessarily quotes, "Alien Arena is now the very best of the freeware FPS games, surpassing even Tremulous."
The vast majority of this "jealously and bitterness" is created by you. If I were you I'd spend some more time working on the game rather than promoting it. Then it will perhaps get judged on merit rather than by proxy via vacuous articles such as this.
I disagree. I'm not an audiophile; my conventional amp and speakers are some 20 year old hunk of junk. Guitar cable quality is important however. It boils mainly down to capacitance, the more of which a cable has, the more it has the effect of making the cable act like a low pass filter. If you put a guitar on the neck pickup with all the controls turned up, and feed it through a bright amp, there is a noticeable and obvious difference between a short cable (low capacitance) and a long cable (higher capacitance) of the same type.
$100 speaker cables?... yeah.. right. Guitar cables? Worth spending a little bit extra. Obviously build quality is also of importance as you point out, but it's worth paying attention to electrical properties too.
For Tremulous (incidentally, based on Quake^H^H^H^H^Hid tech 3), the OS breakdown is as follows:
Windows: 78%
x86 Linux: 16%
ppc OS X: 4%
x86 OS X: 1%
x86_64 Linux: less than 1%
Freebsd: much less than 1%
This is based on approximately 370000 clients. Admittedly the figures are a bit skewed in favour of Windows and Linux as the OS X build is only available from apple.com. The same is true of x86_64 and Freebsd -- those are built manually by whoever is running them (I assume). There are other issues as well as it could be argued that the Linux version is potentially easier to get than the other versions since it has made its way into various packaging systems.
Even if you take this data with a pinch of salt, I think it does reinforce that there is a demand for gaming on Linux. What it doesn't indicate (and I'm not convinced exists) is a demand to pay for gaming on Linux.
Slashdot Mirror
Using void pointers is a choice.
As is using ids.
If you're prepared to not use the standard library; and that is impractical.
Anyway... Nazis etc.
Spoken like someone that has never needed to maintain other people's code.
This is actually ~80% of my job, for what it's worth.
You might not write code using these features, but if they're there, you must be able to read and understand them because someone else will use them.
But I do agree. My point was more than a language shouldn't be discounted because it's perceived to have "too many" features.
Both id and void* are part of the language. Both are avoidable. But of course we end up using them if the library uses them.
With Obj-C you end up using id when you use Apple's Foundation library collection classes.
OK, technically the standard library is not Obj-C, but you'll have a pretty hard time not using it for most purposes.
With C++ you are using them with printf. The first parameter is a char*, and then you implicitly have an unlimited number of void* parameters. And if you get the type wrong, they'll only fail at run time.
Technically printf is a variadic function, not one which takes a void pointer. The functions dealing with direct memory access (memset/cpy etc.) use void pointers obviously, but I can't think of any others off the top of my head. Using void pointers is a choice. Random aside: you can write a completely statically type safe printf using variadic templates.
Obj-C for example has categories, which allow you to extend the functionality of a library class - even if you don't have the source for it. C++ can't do that. It can only subclass. Which doesn't help if someone else's code is creating the class in the first place.
C# and Java can do this. Not really sure what you're getting at to be honest...
Not necessarily. id is what makes Obj-C somewhat weakly typed. But C++ has void* which has less type information than id does.
Yes, you can choose to use void pointers and subvert the type system if you so wish. That's a pretty dumb choice though and you deserve everything you get if your programs end up error prone. Obj-C's id type is an integral and unavoidable part of the language. Comparing the two things is a bit silly I think.
For sure, they both smell of the 80s. Obj-C is far from perfect. But it's much nicer than C++.
I think we'll have to agree to disagree. Both languages need to die off, but potential successors should resemble C++ far more than Obj-C.
You treat a pointer to foo as if it's a pointer to unrelated class bar, it'll fail more often at runtime in C++ than in Obj-C.
Of course strongly typed languages can fail at runtime; I'm not suggesting they don't. What I am saying is that having a strong type system makes you more likely to catch the failures at compile time. The hypothetical you've just stated would require an explicit reinterpret_cast to get a foo pointer to point to a bar i.e. you're asking the compiler not to point out your mistake.
What I think you meant is that the C++ compiler will catch more programmer errors at compile time than Obj-C the compiler will. But with the standard Obj-C compiler front end being LLVM now, the reverse is true. LLVM Obj-C compiler will catch far more programmer errors than the standard GCC C++ compiler.
I said it elsewhere, but the compiler can only compensate for the failures of the language -- it can't fix them. When the language allows you to fail exotically at runtime in ways that are statically unpredictable, the compiler is irrelevant. Almost all languages except for the strictest functional ones have these failure modes, but weakly typed languages have them more. Out of interest how would you rank LLVM Obj-C against LLVM C++?
On top of this, Obj-C allows techniques such as introspection that are just not available on C++.
That's not entirely true. Qt (the widget library) is an example of a C++ based code base that does introspection. To be honest though in my career I can only think of a handful of times where introspection has been useful and in most of those cases there were better solutions to the problem that didn't need it.
I'm kind of coming out of this sounding like a C++ apologist; I'm really not. Objective-C is not the answer though. It smells of the 80s.
I'm curious how you explain the meteoric rise of Objective-C then, if it's not down to the proliferation of iOS?
Are you sure this isn't just a matter of taste?
To some extent I guess; it depends how confident you are in your code. At the extreme end of functional programming you can prove that a certain program is correct before you even run it. This is very hard to do with a dynamic language.
It gives it scripting-language agility and introspection with compiled language speeds, and still most of the type checking features are available when you want them, it just doesn't compel them.
C# has reflection whilst being strongly-typed. The two things aren't mutally exclusive.
You sometimes hear this said about Obj-C and it is somewhat true. It's syntax is a little outdated in comparison to some of the more modern languages but other things like the dynamic typing being a big issue are long since history; Objective-C compilers will now give you a lot more compile time information and make these kind of runtime errors largely a thing of the past. Obj-C is far from perfect but it's a much nicer language than the bloated hell that is C++.
Compilers can only compensate for the language's failures, not fix them. Having said that, the 'Analyze' option in Xcode 4 is pretty good.
Language bloat isn't a problem in itself. You are free not to use the features you consider bloat, at no cost. Where it does become a problem is when new language features are shoe-horned with every effort not to break compatibility. The result is obscure new syntax and existing features that should have gone the way of the Dodo. This is where C++11 is, if you ask me.
If you substitute 'uses' for 'requires', the GP is quite correct. It's not like there has been a mass adoption of the language because of the merits of the language itself.
...is obviously because of iOS. More specifically it's because when Steve Jobs rejoined Apple in 1996 he brought with his a lot of NeXTStep tech, including Obj-C. That's why many of the system types have the 'NS' prefix. History lesson aside, it's rather a shame as it's (in my opinion) a rather poor and outdated language. If I'm ever asked by people who aren't familiar with it what it's like I say that it's the anti-sibling to C++. By this I mean that it has the same parentage as C++, but where C++ went down one path, Obj-C took the other. The fact that most well regarded modern languages have more in common with C++ than Obj-C should indicate that they made mistakes in its design. Obj-C's biggest failing is its tendency to fail at runtime rather than during compilation. This is mostly down to its weak type system.
Don't get me wrong, I think C++ is getting pretty creaky too. I'm quite fond of D; in a fantasy world, some big commercial player will start using it and make it popular.
That's basically what I said using more words.
Yep, I have humour.
Can't tell if troll or not. HDMI is a digital interface so cable quality isn't all that important.
In the domain in which it's dominant, the only viable alternative (IMHO) is D and that hasn't achieved critical mass.
With C++0x we have the mutually exclusive aims of nice syntax and new features. The comes a point where maintaining legacy support impinges on the cleanliness of the language to such an extent that it becomes counter-productive. The whole point of a programming language is to express problems in a legible way. The new "enum class" syntax is a good example of how things can go wrong.
It's not C++ itself I have a problem with; it's that improvements to the language are made without breaking legacy support -- no compromise and at any cost. I'm not singling out C++ either; pretty much every language is upgraded in the same way. The difference with C++ is that it's that old and the changes are that great that the syntax additions become plain ridiculous in some cases. It would be better to start with a relatively clean slate and just-do-it-fucking-right.
I like the look of D as a succesor to C++, but unfortunately it doesn't seem to be getting any traction.
...I'm amazed at how obtuse (and in some cases, downright insulting) the majority of the comments on this story are. I think it's highly likely that if .NET didn't come from Microsoft, nobody would be getting quite so emotional about the whole thing.
For the record, I'm categorically not Microsoft's greatest fan, but you cannot deny that .NET/C# is a damn good platform. Having a portable version of said good platform is therefore a Good Thing. It doesn't matter if Microsoft decide to fuck Mono over; it's still a good platform and therefore still a Good Thing. If you disagree and you don't like it, then fine; don't use it and stop whining.
I don't agree with you.
The common factor with all the games listed is that their code is GPL. UrT doesn't qualify as its game code is still closed source. Depending on your reading of the license, this may constitute a GPL violation.
Alternatively, it could just have been left off as it was written before UrT was released as a single (legally ambiguous, IMHO) package.
> Take some of your own advice then - concentrate on Tremulous
What makes you think I'm not?
> If you want to discuss this privately in email, then please let's, because this public pissing contest has gone too far IMO.
If you say things in public they should stay in public.
I'm not trying to start a war or flaming. I'm trying to point out why people react to you the way they do in the hope that you'll stop making such a pillock of yourself in future. I don't think it's working.
Finding promotional screenshots such as this doesn't indicate to me that you're really taking on board anything I've said.
Oh well, have a nice day.
Who is being bitter? It's not me. I don't really understand why you don't get this. It's utterly hypocritical to go complaining about other people posting links to whatever games they like when YOUR post to a GLOBAL website PUBLICLY denounces one particular game in favour of your own. Now this doesn't really bother me in itself, I just find it a bit rich that you apparently want some kind of moratorium on other people posting their own thoughts on whatever game they like, when you're seemingly allowed to say whatever you like.
"When Tremulous was reviewed by this same guy last year, you didn't see *me* posting links to Alien Arena and trashing Trem."
Is the insinuation here that I have been trashing Alien Arena? I certainly don't remember doing so, maybe you can point it out. The only people that are making judgemental comments here are the players themselves; these are the people that you're ultimately trying to appease. If you're not satisfying them, you need to address their concerns, rather than criticising and blaming other developers.
And another thing. You have a pretty strong victim complex going on there. You seem to think that it's only Alien Arena which gets criticism. Look at any other news posting for any other game and you'll find the same repetitive drone of "this game sucks! X is much better!". Get over it, that's just the way it is. By complaining about this phenomenon, you do yourself no favours. You're not engendering yourself toward the players and especially not to other developers. Just let it wash over you and concentrate on making the game better.
Dude, the story that YOU posted unnecessarily quotes, "Alien Arena is now the very best of the freeware FPS games, surpassing even Tremulous."
The vast majority of this "jealously and bitterness" is created by you. If I were you I'd spend some more time working on the game rather than promoting it. Then it will perhaps get judged on merit rather than by proxy via vacuous articles such as this.
I disagree. I'm not an audiophile; my conventional amp and speakers are some 20 year old hunk of junk. Guitar cable quality is important however. It boils mainly down to capacitance, the more of which a cable has, the more it has the effect of making the cable act like a low pass filter. If you put a guitar on the neck pickup with all the controls turned up, and feed it through a bright amp, there is a noticeable and obvious difference between a short cable (low capacitance) and a long cable (higher capacitance) of the same type.
$100 speaker cables?... yeah.. right. Guitar cables? Worth spending a little bit extra. Obviously build quality is also of importance as you point out, but it's worth paying attention to electrical properties too.
For Tremulous (incidentally, based on Quake^H^H^H^H^Hid tech 3), the OS breakdown is as follows:
Windows: 78%
x86 Linux: 16%
ppc OS X: 4%
x86 OS X: 1%
x86_64 Linux: less than 1%
Freebsd: much less than 1%
This is based on approximately 370000 clients. Admittedly the figures are a bit skewed in favour of Windows and Linux as the OS X build is only available from apple.com. The same is true of x86_64 and Freebsd -- those are built manually by whoever is running them (I assume). There are other issues as well as it could be argued that the Linux version is potentially easier to get than the other versions since it has made its way into various packaging systems.
Even if you take this data with a pinch of salt, I think it does reinforce that there is a demand for gaming on Linux. What it doesn't indicate (and I'm not convinced exists) is a demand to pay for gaming on Linux.