Angel is tragically flawed. He cannot ever be human nor a vampire.
Actually, he can be a vampire just fine.
He'll never, ever, ever have a healthy psychology.
He seemed relatively stable to me. Granted, not happy, but stable.
Spike, too. Wants Buffy deeply, though he's technically incapable of love,
Well, actually, vampires are capable of relationships -- Angel and Darla, for example. And he's certainly capable of it once he gets his soul back.
River Tam is super-human. Practically a goddess... Her flaws are a point of empathy and they serve to make her infinitely stronger. It is endearing and intrinsic to her... So yes, River had flaws. But her flaws actually made her SUPERIOR. You won't find that in a male character under Mr Whedon.
Well, let's see:
Angel is super-human. Practically a god... His flaws are a point of empathy and they serve to make him infinitely stronger. It is endearing and intrinsic to him... So yes, Angel had flaws. But his flaws actually made him SUPERIOR.
The only two points missing are that Angel is not always surrounded by non-supers, and Angel didn't have a movie.
Malcom Reynolds is so deeply scarred that he cannot form normal attachments to humans.
Well, define "normal". The bonds he forms seem to be much stronger.
War gave him severe Aspergers,
Where's your evidence for that? Do you understand what Aspergers is?
Mal understands social norms perfectly well, he just doesn't give a fuck most of the time. There's a difference.
alongside damaging the logic part of his brain,
Aspergers would tend to reinforce that, not damage it.
Occasionally he tears up about it.
Duh. He's a war survivor. Zoe does too.
His strength is carried to a fault, even when his being weak would make a better story.
Being weak... like, oh, in Our Mrs. Reynolds?
[Jayne, Wash, Book, Simon] vs [any of the women] - its better to be a girl.
Yes, it would be so much better to be traumatized to the point of severe mood swings, paranoia, hallucination, delusions of grandeur... you know, actual insanity, caused by people cutting open your brain, rather than, say, a little bitterness about losing a war.
In Doctor Horrible... The girl in the story sits squarely in the middle, without any flaws of any kind.
She fell for Hammer, despite obvious flaws. And no, it's not just because we had Dr. Horrible's perspective. Hammer threw her in the trash and she fell for him. Hammer had absolutely no concept of intimacy ("We totally had sex!"), and this is blatantly obvious, yet she thinks he's special.
So, severe naivete -- not a serious problem? It's even a stereotypically female problem.
I mean, aside from native SVG, which also supports scripting, there's the Canvas tag, which seems to pretty much obsoletes everything to like about Flash as a target. I can see liking Flash as a development tool, but I suspect Adobe will just target HTML5 in the end.
We had a much better excuse -- I had a job developing a music widget, and the widget itself had to work on places like Myspace, which didn't allow iframes, only Flash. Even so, as long as we could, we kept it a fully HTML solution, using Flash only for the actual audio playback -- but HTML for everything you actually saw, the UI, the controls, everything.
But in the end I bailed. And slowly but surely the others were trickling out as well.
The problem is that this "trickling" process has been going on for years, probably close to a decade, and it doesn't take many to make an enjoyable game. In particular, the people who leave first tend to be the people least interested in roleplaying and otherwise making the game more enjoyable.
And the game itself is fun, and I would likely play just for the game, or just for the player-run games on top of that.
The real concern, and the entire reason for the item shop in the first place, is that they either need more users (not likely to happen) or more money per user, just to keep the shop afloat. I don't know what their actual finances are, but I ran the numbers, based on the population, and I'd be amazed if they could afford to hire a single person full-time at minimum wage, which is why they leave so much to the players.
And of course, the danger is that whenever they add something new to the game, they can either add it to the game itself (accessible to anyone) or to the item shop. Guess what usually happens? Crafting bags, which expand how much ore, metal, etc can be carried per trip, were added exclusively to the item shop. Pets (purely decorative) have a few crappy-but-expensive in-game options, and the rest can only be found in the item shop. Mounts are either found as horses wandering around, spells in a few player-run subpaths (they summon horses), or much cooler mounts (panthers, armored horses) in the item shop.
It is possible that I'd quit, at least for awhile, especially if I found something "better". It seems unlikely that I'd be gone forever. There's another effect at play here -- no one ever quits Nexus. They think they do, but they always come back.
directly encourage players to drop tens to hundreds of dollars on in-game items and perks, as was once contained to the mental diarrhea that is Second Life.
I actually don't have nearly as much of a problem with it in Second Life. After all, most of our real currency is imaginary, so it doesn't bother me that imaginary things can have value.
But then, Second Life isn't a game so much as a medium, and this kind of shit tends to ruin games.
where the micropayments are supposed to be for "tipping" the developers,
I don't know about that -- seems they could always set up a PayPal "donate" button. Otherwise, I do like that I actually get something out of the micropayments.
It just becomes an issue when that "something" is a decided gameplay advantage. It's similar to, oh, arcade games -- I "beat" Time Crisis 2 by putting quarters into the machine until I won, spent something like $20 on it. That seems to me a bit like expensive cheating -- I actually don't mind it so much in arcade games, any more than I mind cheats in single-player games, but multiplayer, let alone massively multiplayer, shouldn't tolerate that.
So, yes:
Buying a game: fine. Paying a fixed monthly fee for an MMO: fine. Allowing those with too much disposable income to shit on everyone else's game progression: dirty.
And again, I draw a hard line between this and something like Second Life. In Second Life, it's effectively the real world -- if I care about fashion, I can spend tons of money on virtual clothes, or make my own. If I don't care how I look, I can just wear whatever's cheap or free.
The difference would be if Second Life added working guns and kevlar vests.
I think mixing subscription play with micropayments is sort of double dipping that players won't appreciate.
It's not so much that as that it slowly erodes the actual gameplay, let alone the immersion. I play this game, and ever since they've added an item shop, people are wandering around Ancient Korea with sunglasses, because they can charge for them (useless item, pure decoration) in the item shop. The idea was that this wouldn't affect gameplay, but of course, it creates games all its own -- there's now an official runway competition to decide whose avatar has the best style, which inevitably entails lots of item-shop items. They've also recently (and kind of inevitably) introduced things which directly affect gameplay, like extra storage for crafting items...
Now, the problem is, I don't know if this actually makes a difference in the business sense. I mean, as a player, I absolutely appreciate what you're doing, but I'm also going to keep playing Nexus because of all the stuff I have there, and the community I'm involved with -- basically, because of network effect and a strange sort of lock-in that all MMOs inherently have.
However, the very existence of this possibility just pisses me off. It's like the bad old days, when there was an app framework which just took a webpage (or web app) and created a thin wrapper around it to make an iPhone app, and Apple banned that entire framework, to where you had to manually replace suspicious-looking strings in the resultant app to fool the review process.
That's what it would be. Given the Flash example, they'd notice that the output looked a lot like what the Flash framework outputted, and they'd start looking for specific makers, so they could filter that app out. Then the developers, and later Adobe, would put some effort into hiding the fact that it's a Flash app, at least long enough to squeeze through the review process.
All of this just turns into a cat-and-mouse game that I really don't want to play. They already have sufficient policy to deal with any such app in somewhat more legitimate terms, like the app being too inefficient, or the generated code being horribly unmaintainable. Or they could've been honest and said, "No matter what Adobe does, we won't allow Flash."
Instead, they've adopted a policy which, enforceable or not, is a giant "fuck you" to developers.
Buffer overflows? SQL injection? Yes, developers can inadvertantly allow access to any layer of implementation. However, there are standard techniques to detect and mitigate common lapses. Detecting problems with eval code is much harder and is related to the halting problem.
It depends how much eval would be abused. I'd think it would be sufficient to grep for all cases of eval and have a human evaluate them.
Lots of static resources are created using e.g. Interface Builder.
Sounds a bit like Qt Designer, which creates XML files which are then translated to C++, which can then be linked to other C++ programs...
Or, and this is key, to anything with Qt bindings.
I again don't see why we should be restricted to using Xcode, and even if we are, why we should be restricted to a single language within Xcode.
Additionally "application" on Mac OS X is actually a bundle, compiled program is only part of. Bundling of resources and external frameworks are pure Apple specific part having little to do with compiler or linker.
While true, the "bundle" is something that's existed since NextStep, and I very much doubt that Xcode is the only thing which can create such a bundle. In fact, I'm fairly certain Rawr can create them.
If only you hadn't you ignored technical point in GP...
Which one?
Calling me illiterate and accusing me of ignoring technical points is fine, if you actually point out my mistake. Otherwise, you're clearly trolling.
You are missing the point, just like everyone else. The point is that yes, it is a smart idea, and one that would have been an option... until now. Apple now won't allow it because of the original language doctrine -- it doesn't matter if you translate it to Objective C source, it has to have been originally written in Objective C.
So, for example:
Surely there must be a way to spoof the output of Apple's compiler?
No, that's irrelevant. I'm pretty sure they already weren't allowing third-party compilers. This just means they won't even allow third-party preprocessors.
So what it boils down to (and you're probably right on that) is a choice between inaccurate and ineffective.
Well, maybe. A quick Google found this definition from Wikipedia:
Belief is the psychological state in which an individual holds a proposition or premise to be true.
That sounds pretty correct. We hold these things to be true. If they are shown to be false, we are willing to change our minds, but I don't think we'd go so far as to say that we're unsure about them.
In ordinary, everyday language, we certainly talk as though we're certain about things. (Or do we? Am I 100% certain that that's what happens? No, but I used the word "certainly" anyway.) We even use the word 'belief' a lot -- or so I believe.
More than anything, I want us to avoid these semantic traps because that's just forcing us to play the game the old way.
The game is PR, and it will never die.
More than anything though, the goal should be to avoid falling into the old science vs. religion crap. The idea is not that religion is the enemy - just that it is irrelevant...
I would agree, but it tends to try to make itself relevant, as this story shows.
That is, it absolutely is relevant the way religion is castrating the text books in Texas.
When doing real science, sure, we can pretend it doesn't exist -- but if we want to continue to do real science, we have to deal with religion.
If an application was implemented in a Lisp-like language then any application that inadvertantly allowed access to this implementation could cause havoc,
Oh, bullshit. Applications can inadvertently allow access to anything the developers screw up with.
The covert policy has several business benefits which obscure the technical case.
Exactly.
Seems to me the most obvious one is that any implementation which contains something like 'eval' could theoretically patch itself without the patch going through Apple's review process. But they already have an explicit policy against anything that has this effect, so I don't see why they can't allow 'eval', just enforce that they be used safely.
A Turing complete application would severely undermine this policy. For example, a sufficiently flexible application like Emacs or Eclipse...
Well, again, it seems like they should have a policy against exposing this kind of power to the user, rather than a policy against technologies which might theoretically maybe allow this kind of power, but otherwise make life much easier for developers.
But it sounds like you agree with me -- there isn't a good technical reason, there are a lot of bad business reasons. Good reasons for Apple, I suppose, but reasons which hurt pretty much everyone but Apple who wants to work with the iPhone.
#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.
Consider the problem of python's global interpreter lock.... If you convert a python code to C, this non-parallizable global interprer lock does not go away!
That depends how you do the conversion. There's also nothing stopping you from creating a similar lock in a C program.
What this example shows is that even if you output something into objective-c or whatever, you can create programs that impose huge constraints on the way a code must be executed.
Which you can do even with code originally written in Objective C, or any language, really.
In other words, you're saying it might be the case that compiling another language to Objective C would produce crap code. I'm saying, let's wait till it actually happens -- doesn't Apple already have some standards about crap code anyway? I thought that was the whole theory of the App Store -- that the app review process protects customers by only allowing the best apps through?
while the simple for loop would respond to openMP very well, the second form of nested function calls would not work at all in openMP.
That suggests OpenMP could be smarter, and the conversion layer could be smarter. In either case, I'd again point to the fact that Apple has extensive standards about what kind of apps they'll allow through. If I can produce a quality app using such a compiler, what business does Apple have rejecting me because of what compiler I use?
That's akin to rejecting my app because I wrote it while listening to Daft Punk, when I should've been listening to The Beatles.
If they want to come up with something about the output to criticize, that's one thing -- and it's already something which shouldn't be their business -- but this crosses a line.
I don't think you quite understand what Apple is doing here.
There are essentially two ways for applications to construct the menu: either by adding own items to whatever Cocoa creates automatically (that's official blessed way) or create one from scratch.
So you use Cocoa bindings for whatever language you actually want to use, or you compile from another language into Objective C.
So you still haven't provided a single example of why it must be originally coded in Objective C. By analogy, Google App Engine requires that I use Python or Java, but they certainly don't prevent me from using JRuby.
But Apple with Cocoa (and ObjC - it is the enabler of the magic)
So yeah, your examples don't even preclude this working in other native languages. My problem is that they're effectively saying you cannot use anything which compiles to Objective C, only Objective C itself.
In other words, they're banning third-party preprocessors.
Does a single thing you said explain why they won't allow frameworks which compile to Objective-C?
That's where I'm having trouble. I can see a technical reason to force people to use a single language, or at least a single runtime representation, in the same way that, say, the new Windows Mobile forces you to use.NET. I don't see any technical reason for them to care what language you originally use to produce it.
sensible people would not argue with your meaning of 'believe'. But it has a bad connotation because it has been almost entirely hijacked by the 'faith-based' crowd.
I think the question is whether it still means something close enough to what it originally meant that it's a useful term.
For instance, the word "atheist" has also been hijacked by religion to mean "bad person" (that was actually in the dictionary), "one who affirms that God does not exist", and "satan worshipper", none of which is accurate. Still, they're close enough to open a conversation, even if the first two minutes of that conversation are educating the person on what the term actually means.
In this particular case, it's already a minor victory for your opponent because you have now placed your reasoned arguments and his arguments from faith on an even keel.
I don't see a good option, though, because the alternative is to use less strong language, which would impress scientists, but not really the general public. What they'll see is a scientist who's really not sure, and a religious person who has a very strong conviction, and for purely psychological reasons, the strong conviction wins.
Top post on that is a remark about how things behave weirdly when you redefine certain methods. That's true of other languages I like -- any language that supports operator overloading can create some really weird shit.
The more important question is why you would ever do that? Don't abuse the language, and it won't abuse you.
Next one is about numbers close to infinity. When would I ever see this?
And there is one that's an IE-specific bug. That's an IE bug, not a Javascript bug.
Again, these are interesting warts, but why would I care?
Secondly, Prototype-based OO is quite ugly. Sure, it's workable, and you can argue that it's the more pure way to do OO...
I can and do. I actually like it, because it's simpler, and I think it's far easier and cleaner to build a class-based system on top of prototype-based than the other way around.
any way you try to sugar coat it, Javascript makes it a lot uglier than it needs to be.
I don't think so. There are a few patterns in particular which work very well in Javascript, even elegantly. I certainly agree that it has room for improvement, but the fact that it's prototype-based is the last place I would look.
Thirdly, the fact that it's a defacto standardized language, a lot like the web itself was defacto'd into existence rather than people trying to follow standards (which came later), each implementation is different enough that what will work in one does not necessarily work in another.
There is, however, an official standard now. The differences seem to be largely at the API level, and that's something which can be handled in libraries.
Still, you can point out flaws and inconsistencies in any language, but the web-related technologies tend to be a lot more, well let's call them "special" (just to make them feel better).
Could be. I still don't think it justifies the "even shittier" comment. It's not hard to find many examples of languages shittier than JavaScript -- I'd start with, oh, Java.
I can understand wanting to distinguish between what you believe and dogmatic, unshakable faith, but we do use the word "believe" to refer to psychological certainty, which is appropriate for one of the most well-supported theories in science.
I would say I believe in the big bang and evolution, and I believe that neither will be shown to be entirely wrong, only incrementally wrong. I justify that by example: The Earth is approximately flat, locally -- it's only at a large scale that this becomes inaccurate at best, but we can still pretend it's flat when we do landscaping, city planning, etc. The Earth is also not spherical, but pear-shaped, and so on. While the Earth does revolve around the sun, we still talk about sunrise and sunset, and for much of our lives, it works to think of the Sun as going around the Earth, and it's certainly more convenient to assume the ground beneath our feet is stationary, even when we know it's not.
It's possible that I could be shown to be entirely wrong, but that seems incredibly unlikely. So I could say I don't know with absolute certainty, but I can certainly say that I do know and believe with about as much certainty as it is possible to know or believe any physical fact.
So the question could've been worded better. Even so, if you want the word "belief" to have any meaning whatsoever, it might make sense to apply it to things you admit might one day be shown to be false. While "believe in" sounds stupid, irritating, and demeaning to science, I would still rather be counted in such a poll as believing in evolution, rather than not believing.
Semantic arguments are fun, but at a certain point, for expediency's sake, I might decide to adopt the terminology of my opponent so that we can move forward. I can bitch about the abuse of the word "hacking" as much as I want, but at this point, it's just easier to talk about "hacking" to mean cheating, cracking, or any number of other things.
Slashdot Mirror
Let's see...
Angel is tragically flawed. He cannot ever be human nor a vampire.
Actually, he can be a vampire just fine.
He'll never, ever, ever have a healthy psychology.
He seemed relatively stable to me. Granted, not happy, but stable.
Spike, too. Wants Buffy deeply, though he's technically incapable of love,
Well, actually, vampires are capable of relationships -- Angel and Darla, for example. And he's certainly capable of it once he gets his soul back.
River Tam is super-human. Practically a goddess... Her flaws are a point of empathy and they serve to make her infinitely stronger. It is endearing and intrinsic to her... So yes, River had flaws. But her flaws actually made her SUPERIOR. You won't find that in a male character under Mr Whedon.
Well, let's see:
Angel is super-human. Practically a god... His flaws are a point of empathy and they serve to make him infinitely stronger. It is endearing and intrinsic to him... So yes, Angel had flaws. But his flaws actually made him SUPERIOR.
The only two points missing are that Angel is not always surrounded by non-supers, and Angel didn't have a movie.
Malcom Reynolds is so deeply scarred that he cannot form normal attachments to humans.
Well, define "normal". The bonds he forms seem to be much stronger.
War gave him severe Aspergers,
Where's your evidence for that? Do you understand what Aspergers is?
Mal understands social norms perfectly well, he just doesn't give a fuck most of the time. There's a difference.
alongside damaging the logic part of his brain,
Aspergers would tend to reinforce that, not damage it.
Occasionally he tears up about it.
Duh. He's a war survivor. Zoe does too.
His strength is carried to a fault, even when his being weak would make a better story.
Being weak... like, oh, in Our Mrs. Reynolds?
[Jayne, Wash, Book, Simon] vs [any of the women] - its better to be a girl.
Yes, it would be so much better to be traumatized to the point of severe mood swings, paranoia, hallucination, delusions of grandeur... you know, actual insanity, caused by people cutting open your brain, rather than, say, a little bitterness about losing a war.
In Doctor Horrible... The girl in the story sits squarely in the middle, without any flaws of any kind.
She fell for Hammer, despite obvious flaws. And no, it's not just because we had Dr. Horrible's perspective. Hammer threw her in the trash and she fell for him. Hammer had absolutely no concept of intimacy ("We totally had sex!"), and this is blatantly obvious, yet she thinks he's special.
So, severe naivete -- not a serious problem? It's even a stereotypically female problem.
Your views are interesting, but also very wrong.
I mean, aside from native SVG, which also supports scripting, there's the Canvas tag, which seems to pretty much obsoletes everything to like about Flash as a target. I can see liking Flash as a development tool, but I suspect Adobe will just target HTML5 in the end.
And IMO, digraph (from graphviz) is quicker if it has to be digital or pretty, and whiteboards are quicker still.
Here's why I use Flash on the sites I build:
audio and video
And why don't you use HTML5, then? Or at least HTML5 which gracefully degrades to Flash?
we'll be quite happy to switch to HTML5 media just as soon as MSIE supports it.
It does.
We had a much better excuse -- I had a job developing a music widget, and the widget itself had to work on places like Myspace, which didn't allow iframes, only Flash. Even so, as long as we could, we kept it a fully HTML solution, using Flash only for the actual audio playback -- but HTML for everything you actually saw, the UI, the controls, everything.
But in the end I bailed. And slowly but surely the others were trickling out as well.
The problem is that this "trickling" process has been going on for years, probably close to a decade, and it doesn't take many to make an enjoyable game. In particular, the people who leave first tend to be the people least interested in roleplaying and otherwise making the game more enjoyable.
And the game itself is fun, and I would likely play just for the game, or just for the player-run games on top of that.
The real concern, and the entire reason for the item shop in the first place, is that they either need more users (not likely to happen) or more money per user, just to keep the shop afloat. I don't know what their actual finances are, but I ran the numbers, based on the population, and I'd be amazed if they could afford to hire a single person full-time at minimum wage, which is why they leave so much to the players.
And of course, the danger is that whenever they add something new to the game, they can either add it to the game itself (accessible to anyone) or to the item shop. Guess what usually happens? Crafting bags, which expand how much ore, metal, etc can be carried per trip, were added exclusively to the item shop. Pets (purely decorative) have a few crappy-but-expensive in-game options, and the rest can only be found in the item shop. Mounts are either found as horses wandering around, spells in a few player-run subpaths (they summon horses), or much cooler mounts (panthers, armored horses) in the item shop.
It is possible that I'd quit, at least for awhile, especially if I found something "better". It seems unlikely that I'd be gone forever. There's another effect at play here -- no one ever quits Nexus. They think they do, but they always come back.
directly encourage players to drop tens to hundreds of dollars on in-game items and perks, as was once contained to the mental diarrhea that is Second Life.
I actually don't have nearly as much of a problem with it in Second Life. After all, most of our real currency is imaginary, so it doesn't bother me that imaginary things can have value.
But then, Second Life isn't a game so much as a medium, and this kind of shit tends to ruin games.
where the micropayments are supposed to be for "tipping" the developers,
I don't know about that -- seems they could always set up a PayPal "donate" button. Otherwise, I do like that I actually get something out of the micropayments.
It just becomes an issue when that "something" is a decided gameplay advantage. It's similar to, oh, arcade games -- I "beat" Time Crisis 2 by putting quarters into the machine until I won, spent something like $20 on it. That seems to me a bit like expensive cheating -- I actually don't mind it so much in arcade games, any more than I mind cheats in single-player games, but multiplayer, let alone massively multiplayer, shouldn't tolerate that.
So, yes:
Buying a game: fine. Paying a fixed monthly fee for an MMO: fine. Allowing those with too much disposable income to shit on everyone else's game progression: dirty.
And again, I draw a hard line between this and something like Second Life. In Second Life, it's effectively the real world -- if I care about fashion, I can spend tons of money on virtual clothes, or make my own. If I don't care how I look, I can just wear whatever's cheap or free.
The difference would be if Second Life added working guns and kevlar vests.
I wonder if that makes sense...
I think mixing subscription play with micropayments is sort of double dipping that players won't appreciate.
It's not so much that as that it slowly erodes the actual gameplay, let alone the immersion. I play this game, and ever since they've added an item shop, people are wandering around Ancient Korea with sunglasses, because they can charge for them (useless item, pure decoration) in the item shop. The idea was that this wouldn't affect gameplay, but of course, it creates games all its own -- there's now an official runway competition to decide whose avatar has the best style, which inevitably entails lots of item-shop items. They've also recently (and kind of inevitably) introduced things which directly affect gameplay, like extra storage for crafting items...
Now, the problem is, I don't know if this actually makes a difference in the business sense. I mean, as a player, I absolutely appreciate what you're doing, but I'm also going to keep playing Nexus because of all the stuff I have there, and the community I'm involved with -- basically, because of network effect and a strange sort of lock-in that all MMOs inherently have.
No, the original poster. BadAnalogyGuy.
The hell they don't!
Look at his name.
I think you may be assuming something about D&D players. I never played myself, but I remember seeing people turn it into a full-contact sport.
(Just a matter of fact that I never played it. If I had, I wouldn't be ashamed to say so. Just never really got the chance.)
Oh, and that's a really bad analogy, guy.
Technically, they can't.
However, the very existence of this possibility just pisses me off. It's like the bad old days, when there was an app framework which just took a webpage (or web app) and created a thin wrapper around it to make an iPhone app, and Apple banned that entire framework, to where you had to manually replace suspicious-looking strings in the resultant app to fool the review process.
That's what it would be. Given the Flash example, they'd notice that the output looked a lot like what the Flash framework outputted, and they'd start looking for specific makers, so they could filter that app out. Then the developers, and later Adobe, would put some effort into hiding the fact that it's a Flash app, at least long enough to squeeze through the review process.
All of this just turns into a cat-and-mouse game that I really don't want to play. They already have sufficient policy to deal with any such app in somewhat more legitimate terms, like the app being too inefficient, or the generated code being horribly unmaintainable. Or they could've been honest and said, "No matter what Adobe does, we won't allow Flash."
Instead, they've adopted a policy which, enforceable or not, is a giant "fuck you" to developers.
Buffer overflows? SQL injection? Yes, developers can inadvertantly allow access to any layer of implementation. However, there are standard techniques to detect and mitigate common lapses. Detecting problems with eval code is much harder and is related to the halting problem.
It depends how much eval would be abused. I'd think it would be sufficient to grep for all cases of eval and have a human evaluate them.
XCode is transitioning to Clang/LLVM. It's already included in the package, though GCC is still the default.
I'm fairly sure that's still a free toolkit. So, thanks for that, but I still don't see the advantage of forcing XCode.
Lots of static resources are created using e.g. Interface Builder.
Sounds a bit like Qt Designer, which creates XML files which are then translated to C++, which can then be linked to other C++ programs...
Or, and this is key, to anything with Qt bindings.
I again don't see why we should be restricted to using Xcode, and even if we are, why we should be restricted to a single language within Xcode.
Additionally "application" on Mac OS X is actually a bundle, compiled program is only part of. Bundling of resources and external frameworks are pure Apple specific part having little to do with compiler or linker.
While true, the "bundle" is something that's existed since NextStep, and I very much doubt that Xcode is the only thing which can create such a bundle. In fact, I'm fairly certain Rawr can create them.
If only you hadn't you ignored technical point in GP...
Which one?
Calling me illiterate and accusing me of ignoring technical points is fine, if you actually point out my mistake. Otherwise, you're clearly trolling.
What a smart idea!
You are missing the point, just like everyone else. The point is that yes, it is a smart idea, and one that would have been an option... until now. Apple now won't allow it because of the original language doctrine -- it doesn't matter if you translate it to Objective C source, it has to have been originally written in Objective C.
So, for example:
Surely there must be a way to spoof the output of Apple's compiler?
No, that's irrelevant. I'm pretty sure they already weren't allowing third-party compilers. This just means they won't even allow third-party preprocessors.
So what it boils down to (and you're probably right on that) is a choice between inaccurate and ineffective.
Well, maybe. A quick Google found this definition from Wikipedia:
Belief is the psychological state in which an individual holds a proposition or premise to be true.
That sounds pretty correct. We hold these things to be true. If they are shown to be false, we are willing to change our minds, but I don't think we'd go so far as to say that we're unsure about them.
In ordinary, everyday language, we certainly talk as though we're certain about things. (Or do we? Am I 100% certain that that's what happens? No, but I used the word "certainly" anyway.) We even use the word 'belief' a lot -- or so I believe.
More than anything, I want us to avoid these semantic traps because that's just forcing us to play the game the old way.
The game is PR, and it will never die.
More than anything though, the goal should be to avoid falling into the old science vs. religion crap. The idea is not that religion is the enemy - just that it is irrelevant...
I would agree, but it tends to try to make itself relevant, as this story shows.
That is, it absolutely is relevant the way religion is castrating the text books in Texas.
When doing real science, sure, we can pretend it doesn't exist -- but if we want to continue to do real science, we have to deal with religion.
If an application was implemented in a Lisp-like language then any application that inadvertantly allowed access to this implementation could cause havoc,
Oh, bullshit. Applications can inadvertently allow access to anything the developers screw up with.
The covert policy has several business benefits which obscure the technical case.
Exactly.
Seems to me the most obvious one is that any implementation which contains something like 'eval' could theoretically patch itself without the patch going through Apple's review process. But they already have an explicit policy against anything that has this effect, so I don't see why they can't allow 'eval', just enforce that they be used safely.
A Turing complete application would severely undermine this policy. For example, a sufficiently flexible application like Emacs or Eclipse...
Well, again, it seems like they should have a policy against exposing this kind of power to the user, rather than a policy against technologies which might theoretically maybe allow this kind of power, but otherwise make life much easier for developers.
But it sounds like you agree with me -- there isn't a good technical reason, there are a lot of bad business reasons. Good reasons for Apple, I suppose, but reasons which hurt pretty much everyone but Apple who wants to work with the iPhone.
#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.
Consider the problem of python's global interpreter lock.... If you convert a python code to C, this non-parallizable global interprer lock does not go away!
That depends how you do the conversion. There's also nothing stopping you from creating a similar lock in a C program.
What this example shows is that even if you output something into objective-c or whatever, you can create programs that impose huge constraints on the way a code must be executed.
Which you can do even with code originally written in Objective C, or any language, really.
In other words, you're saying it might be the case that compiling another language to Objective C would produce crap code. I'm saying, let's wait till it actually happens -- doesn't Apple already have some standards about crap code anyway? I thought that was the whole theory of the App Store -- that the app review process protects customers by only allowing the best apps through?
while the simple for loop would respond to openMP very well, the second form of nested function calls would not work at all in openMP.
That suggests OpenMP could be smarter, and the conversion layer could be smarter. In either case, I'd again point to the fact that Apple has extensive standards about what kind of apps they'll allow through. If I can produce a quality app using such a compiler, what business does Apple have rejecting me because of what compiler I use?
That's akin to rejecting my app because I wrote it while listening to Daft Punk, when I should've been listening to The Beatles.
If they want to come up with something about the output to criticize, that's one thing -- and it's already something which shouldn't be their business -- but this crosses a line.
I don't think you quite understand what Apple is doing here.
There are essentially two ways for applications to construct the menu: either by adding own items to whatever Cocoa creates automatically (that's official blessed way) or create one from scratch.
So you use Cocoa bindings for whatever language you actually want to use, or you compile from another language into Objective C.
So you still haven't provided a single example of why it must be originally coded in Objective C. By analogy, Google App Engine requires that I use Python or Java, but they certainly don't prevent me from using JRuby.
But Apple with Cocoa (and ObjC - it is the enabler of the magic)
Yeah, clearly Cocoa couldn't work in any other language...
So yeah, your examples don't even preclude this working in other native languages. My problem is that they're effectively saying you cannot use anything which compiles to Objective C, only Objective C itself.
In other words, they're banning third-party preprocessors.
Does a single thing you said explain why they won't allow frameworks which compile to Objective-C?
That's where I'm having trouble. I can see a technical reason to force people to use a single language, or at least a single runtime representation, in the same way that, say, the new Windows Mobile forces you to use .NET. I don't see any technical reason for them to care what language you originally use to produce it.
sensible people would not argue with your meaning of 'believe'. But it has a bad connotation because it has been almost entirely hijacked by the 'faith-based' crowd.
I think the question is whether it still means something close enough to what it originally meant that it's a useful term.
For instance, the word "atheist" has also been hijacked by religion to mean "bad person" (that was actually in the dictionary), "one who affirms that God does not exist", and "satan worshipper", none of which is accurate. Still, they're close enough to open a conversation, even if the first two minutes of that conversation are educating the person on what the term actually means.
In this particular case, it's already a minor victory for your opponent because you have now placed your reasoned arguments and his arguments from faith on an even keel.
I don't see a good option, though, because the alternative is to use less strong language, which would impress scientists, but not really the general public. What they'll see is a scientist who's really not sure, and a religious person who has a very strong conviction, and for purely psychological reasons, the strong conviction wins.
wtfjs [wtfjs.com]
Top post on that is a remark about how things behave weirdly when you redefine certain methods. That's true of other languages I like -- any language that supports operator overloading can create some really weird shit.
The more important question is why you would ever do that? Don't abuse the language, and it won't abuse you.
Next one is about numbers close to infinity. When would I ever see this?
And there is one that's an IE-specific bug. That's an IE bug, not a Javascript bug.
Again, these are interesting warts, but why would I care?
Secondly, Prototype-based OO is quite ugly. Sure, it's workable, and you can argue that it's the more pure way to do OO...
I can and do. I actually like it, because it's simpler, and I think it's far easier and cleaner to build a class-based system on top of prototype-based than the other way around.
any way you try to sugar coat it, Javascript makes it a lot uglier than it needs to be.
I don't think so. There are a few patterns in particular which work very well in Javascript, even elegantly. I certainly agree that it has room for improvement, but the fact that it's prototype-based is the last place I would look.
Thirdly, the fact that it's a defacto standardized language, a lot like the web itself was defacto'd into existence rather than people trying to follow standards (which came later), each implementation is different enough that what will work in one does not necessarily work in another.
There is, however, an official standard now. The differences seem to be largely at the API level, and that's something which can be handled in libraries.
Still, you can point out flaws and inconsistencies in any language, but the web-related technologies tend to be a lot more, well let's call them "special" (just to make them feel better).
Could be. I still don't think it justifies the "even shittier" comment. It's not hard to find many examples of languages shittier than JavaScript -- I'd start with, oh, Java.
I can understand wanting to distinguish between what you believe and dogmatic, unshakable faith, but we do use the word "believe" to refer to psychological certainty, which is appropriate for one of the most well-supported theories in science.
I would say I believe in the big bang and evolution, and I believe that neither will be shown to be entirely wrong, only incrementally wrong. I justify that by example: The Earth is approximately flat, locally -- it's only at a large scale that this becomes inaccurate at best, but we can still pretend it's flat when we do landscaping, city planning, etc. The Earth is also not spherical, but pear-shaped, and so on. While the Earth does revolve around the sun, we still talk about sunrise and sunset, and for much of our lives, it works to think of the Sun as going around the Earth, and it's certainly more convenient to assume the ground beneath our feet is stationary, even when we know it's not.
It's possible that I could be shown to be entirely wrong, but that seems incredibly unlikely. So I could say I don't know with absolute certainty, but I can certainly say that I do know and believe with about as much certainty as it is possible to know or believe any physical fact.
So the question could've been worded better. Even so, if you want the word "belief" to have any meaning whatsoever, it might make sense to apply it to things you admit might one day be shown to be false. While "believe in" sounds stupid, irritating, and demeaning to science, I would still rather be counted in such a poll as believing in evolution, rather than not believing.
Semantic arguments are fun, but at a certain point, for expediency's sake, I might decide to adopt the terminology of my opponent so that we can move forward. I can bitch about the abuse of the word "hacking" as much as I want, but at this point, it's just easier to talk about "hacking" to mean cheating, cracking, or any number of other things.