Wouldn't the code simply be considered a trade secret whenever disclosure of it was not allowed? They copyright per se may be expired, but in the formal legal sense, a trade secret can be maintained indefinitely. (Much like the oft-abused example of KFC or Coke's secret recipes). So, given the proper controls that maintaining a trade secret requires, a company could still keep their source code to themselves.
I'm extremely tardy to this discussion, but I feel it's worth pointing that if any other language out there supported true macros, then Lisp would most likely be dead by now.
Now, I don't see how any other language (that isn't Lisp based itself) could actually support true macros without adopting the same syntax Lisp uses.
But then it would be "Lisp based" (at least superficially) and then you're back where you started (i.e. it's impossible to invent something better than Lisp because Lisp is perfect already).
As someone who is now endeavoring to learn Lisp for fun (and who knows, maybe profit someday), this point has been made very clear to me by what I've been reading.
So, on that note: Do you know of a language besides Lisp that supports true macros? If so, I'll be there in a heartbeat as I don't really want to associate with such a conspicuously smug community if I can help it. If not, then I guess that's that.
The bad thing about macros, is that it can slide out of your control, thus making a language not even you yourself can understand.
OK, now I think you've hit the nail on the head with this observation; as I've heard this difficulty related to me by long time LISPers before. I've read some LISP macro code, and it looks anything but simple. It's just not a pleasure to look at. So, I'm wondering, is there a way to make this a more pleasant task (with or without LISP)?
Really, if Python, Ruby, or the like really supported macro expansion (and truly compiled executables, etc. (and no py2exe and its ilk doesn't actually count)), we wouldn't be having this conversation. But since this appears to be "The Last Great Feature" of LISP (aside from that sexy parenthesis based syntax you all seem to love:), that newer languages don't really support yet, I'm wondering how I can partake of the macro magic goodness without having to immerse myself in a positively opaque and smug community of folks who, for the most part, only get to practice this magic as a hobby.
So, am I making sense? I want to be able to take this into my work life (.NET and J2EE preferably - hold yer fire; I have a family to feed!). Please, save me from the upcoming trend of code generation that is going to drown us all in a mountain of unintelligible code!!!
That is cool. Now I get it. Don't lose that example; it works.
I heard some vague talking up of macros before and I sort of understood the superficial impact of it, but I hadn't seen an example like that before that kind of hits home.
Now, having said that, I can easily come back with something like "yeah, but I can do the same thing in Java with a helper class that has a bunch of methods; then instead of using my mystical magical LISP macro thingy that no one will understand, I just call my methods when I need them". And that would be true. But I think the "magic" here in LISP is that by going at it with macros and using those to change the appearance of your programs, you're providing a sort of cognitive shift to the programmer where they can think about each category of problem in the system as a "mini-language". That renders a way for the programmer to feel like they're in control and like the solution feels more elegant, because it's less encumbered by syntactical baggage. Is that about right in your experience?
Well, between this and Ruby, I'll have my hands full for a while. Who knows, I may even do something useful with them someday. (Heck, it worked out that way when I went and learned Python on a lark.)
He did not say that the article would convince them, merely that they would be convinced-he doesn't even say when that would be.
I'm not going to waste a lot of time on this, but since we're being picky, it's probably worth noting that he also did not state what the reader ought to be convinced of.
Also, I'm not a believer in relativism, though it could appear that way based on how I talk and write. I do believe however that everyone's perspective is unique (yes, it's relative) because that perspective is complex as it's constituted by many, many conditions (absolutes). So, no I don't believe in relativism as it's usually understood, but I do believe in 'perspectivism' in that an outsider to another's perspective/context usually does not (and usually can not) have enough information to decide whether a given statement really applies to another individual or group.
To use your above example: assembler may indeed be the best tool for a given string processing task under Unix given certain conditions (such as - absolutely huge amounts of data to be processed in a complex way where developer productivity doesn't matter, but processing time does; as such as the programmer in question only knows assembler and can get the job done pretty quickly that way and doesn't want to take the time to learn Perl or Tcl). That doesn't mean that it would always be the best choice, but the determination of the best choice is ultimately a locally objective judgement (what most people mean when they say "it's subjective") based on a complex situation.
Relativism (as most people use it), you can't live with it; and you can't live without it (as I think it ought to be understood).
This article [paulgraham.com] will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.
And if you are smart and open minded, you might just be able to accept that it wouldn't convince a smart and open minded person. For instance: they might already be convinced so, despite the merits of the article, it can not convince them.
I'd elaborate but people attached to their own languages won't believe.
Please do elaborate. Anyone I know who loves LISP (especiall the macros) has seen it as the "one true way", but I've never had anyone be able to explain the magic to me. Heck, I did some LISP programming for a graduate AI course I did a few years ago, and I still didn't see the magic.
So, if you could finally clear this up for me, I'd appreciate it.
During his interview with 60 Minutes a couple weeks or so ago, he flat out said that he would not be making 7,8, & 9. Not only that, he doesn't see anyone carrying that torch either.
You may claim you can take it or leave it, but you really do project a sort of disappointed wistfulness about the subject. Maybe you just expected too much?
As far as his vanishing goes - all in good time. To my knowledge, we all die sometime. Till then, we may as well have some options. New talent will emerge with the usual noise to signal ratio.
I think not. The only people struggling here are the ones coming to grips that Lucas doesn't owe them anything. He's got nothing left to prove. He doesn't have to care what anyone thinks. If he wants to spend the rest of his days commissioning high-end corporate campuses for his pet projects (a hobby of his), that's his prerogative.
My only "regret" about his career is that he's not going to make the last 3 movies in the series of original 9 books. I have confidence though, that if he thought they would be worth making, that he would have already done that.
Notice this quote from his interview: "I've earned the right to fail, which means making what I think are really great movies that no one wants to see."
And kudos to him. Hopefully, he can squeeze off some more masterpieces before that heart supporting that great furry frame of his gives out.
Linus sided with Larry, despite the fact that Linux, GNU, Samba, and everything else we run has had to rely on reverse engineering of proprietary formats, devices, and protocols since forever just to function.
Enlighten me here... Linus focuses on Linux. He doesn't work on Samba, WINE, or anything else that attempts to emulate something else in order to function. He doesn't really even reverse engineer (to my knowledge) any specific flavor of Unix. He just works on improving Linux.
The heart of this conflict is the idea of using reverse engineering to ride on the research and development of an industry player who has chosen to remain proprietary in order to compete with that entity. Granted, defending against this is really the domain of patents, but I think I understand where Linus is coming from here by defending Larry.
To answer to your examples - Samba was needed to get interoperation with the product of a company that exerts an effective monopoly. Reverse engineering of existing device drivers has been done in order to interoperate with those drivers, not compete with those driver makers.
BitKeeper has no monopoly. It may in fact be THE best of breed implementation, but that's irrelevant. Samba had to be done. A reverse-engineering of the BitKeeper protocol just to save time on developing a good approach using OSS is an endeavor with questionable ethical status and really isn't necessary. Also, reverse engineering BitKeeper just so people can access the data is obviated by the fact that they can (someone correct me here if I'm wrong as I haven't tried this myself) use CVS instead to access that data. BitKeeper doesn't need to be reverse engineered to get to the data. Right?
Now, please tell me how Linus is acting inconsistently?
In short, I would say that reverse engineering something in order to interoperate with it is a completely different ethical matter than trying to reverse engineer something in order to effectively clone it then compete with it. Saying that Linus' position is "inconsistent" because he does not approve of all uses of reverse engineering does not show an appreciation of the fact that not all uses of reverse engineering are ethically equivalent (just as not all uses of firearms, chemicals, matches, etc. are ethically equivalent).
If one of the goals of OSS is to effectively steal the R&D of industry players, then it will receive the fate it would so richly deserve. But, if the goals of OSS include making established non-novel technologies widely available to everyone (e.g. Linux), or even promoting new R&D to create new novel technologies (e.g. BitTorrent), it will thrive and be better than what could possibly be achieved in a proprietary environment.
If he had, he would have at least made some mention of WoW's guilds and friends list and on what an impact that can have on player activities in the game. Regularily scheduled guild events, consistent contact with the same people, getting to know other folks over time through chat, etc. are, for me, turning out to be more interesting parts of the WoW experience than I expected.
But the author didn't discuss any of that. Witness this key quote:
Though the subscriptions support my theory, my primary reasoning is that this is due to the kind of game World of Warcraft is. Most players in World of Warcraft have no reason to engage in long-term socialization. Without socialization, the main draw the game has always been the novelty of the game play. This is so evident that even the world, with its nice variety between zones, doesn't feel worldly enough: it lacks "epic" and feels like a game.
If the only loyalty that players have to World of Warcraft is in the novelty of the game mechanic, this leaves it vulnerable on at least two very important fronts. The first front: once players grow bored of the game mechanic, there's no reason to hang around anymore. The second front: Players will be easily distracted by another game with better core mechanics.
Maybe he's just approaching the game "all wrong", but I think he's missed something here.
One last thing, it does not take a genius to predict that "what goes up, must come down". The real question isn't whether WoW will be a top 5 game for a long period of time, the real question is whether it will be fantastically profitable to Blizzard and give them the breathing room they need to indulge in creating rich new content, game mechanics, social situations in the game, etc.
I think you hit the nail on the head. I wish I had mod points for your post.
Being impressionable and in a sensitive position means you are ripe for the harvest in a counter intelligence situation. You will be much easier to convert to the opposition's cause as it will be much easier to have you see the issue from their point of view and develop sympathy for their position.
A flexible mindset isn't automatically an overly flexible mindset; it's just that much more prone to changes over time. A changed mindset and set of beliefs can manifest as treason.
So, in a way, the IDF is doing those soldiers a favor. They protecting Israel from an increased likelihood of treason, and they're protecting those soldiers from themselves.
Yeah, it's kind of a control freak thing, but it *is* a military organization.
Synchronizing with Oracle light would definitely be easier with Oracle; can't dispute that. I imagine that one could make that easier when doing it from SQL Server by using a data pump product, but then the cost goes up.
As far as querying XML files goes, that's actually a pet peeve of mine. While one could maybe build some cool stuff around XML storage, the whole idea is just wrong-headed IMO as one ought to be querying a database and not flat text files. But then, I may just be prejudiced.:+)
I would think the bigger problem with forcing your team to use SQL Server would be the fact that they prefer and are skilled with Oracle. I'm a little surprised that no one seems to have taken that into consideration when choosing database products.
Just out of curiosity, what missing features are you talking about? I know Oracle has a far richer history and therefore feature set, but I had dismissed most of those as curiosities rather than essential.
Actually, Gabe has apologized about the September 2003 fiasco. AFAIK, he originally put that date together in good faith with the information he had at the time. As things slipped more and more in the project, he just didn't want to face it. So, he ostrich'ed. According to what I've read, it's one of his big regrets and he has acknowledged that it was stupid.
No, I don't know the guy, but that's what I know about the situation.
I will agree that the gaming industry is weird. But it's not any weirder that any other entertainment industry. Eccentricity is bound to run rampant in an industry where entertainment is the key deliverable. Creativity has to be given a safe zone in which to flourish; which only occurs through failure and learning from mistakes.
As far as DRM in general goes, I agree with that too. People in general won't put up with security related inconveniences where their entertainment is concerned. What's scary though is that we'll probably all just throw all of our rights away the very moment that DRM and other security initiatives becomes effectively transparent. Now THAT I care about.
I did check that out a while back. It looks very nice, but I found myself wondering if it could be used for "real work". By that I mean the sorts of hideously feature rich corporate intranet applications that I typically work on. It seemed like it would be a nice start, but more complex features seemed like they would require a chunk more of work on the rails framework.
Anyway, I hope Ruby On Rails (and frameworks like it) become such obvious no-brainers that there will be no good excuse to use things like ASP.NET and JSP in the future. I know there is hope! My last project was a Java web application (one of those hideously complex intranet ones) and I managed to get us to use the Jakarta Tapestry framework for the UI layer. The OSS world keeps on getting better and better.
Umm... yeah, well *I* predicted that XML would never get adopted because it was so expensive (CPU-wise) to use. But, gee, I guess I was wrong.
So, apparently, the cost of XML parsing is acceptable. Which makes all of the so-called dumbasses the decision makers and you and I, the peons. So take your superior attitude and shove it.
I happen to be painfully aware of the tradeoffs XML makes. But the industry chose to embrace it. Now that we've embraced XML, it's suddenly not efficient enough. I'm just trying to make sense of all this. Given that XML is meant to be human readable and self-describing, there really is NO TECHNICAL REASON WHATSOEVER to use it. So, we're back to human factors, where compiler theory doesn't matter one whit.
You know, it's probably good you posted as AC. That way no one would know that you chose to disengage the more important parts of your brain before firing a full salvo of completely correct and completely irrelevant trivia. Typical nerd...
The other side to this coin is that most of the time XML is being used, it doesn't need to be used. If the primary benefits of XML are 1) human readable format and 2) self-describing data and your project doesn't need either of those, then why use XML at all?
XML's performance will always pale in comparison to flat data or binary data, but then it has advantages that come with the trade-off.
To my way of thinking, XML is to ease data interchange and make data portable. It's mainly useful when you want to have data that's 1) human readable and 2) self-describing. There are inherent advantages in those two characteristics that lend themselves to open standards, easy modification, etc.
So, if you don't need those characteristics, why use XML at all? Do you need those characteristics on small devices? Aren't we just talking about all the ways XML falls apart when it's abused?
I don't understand why you wanted to use XML for a game anyway. Aside from easy file validation with a schema or DTD, you wouldn't benefit from it anyway.
To my way of thinking, XML is to ease data interchange and make data portable. It's mainly useful when you want to have data that's 1) human readable and 2) self-describing. There are inherent advantages in those two characteristics that lend themselves to open standards, easy modification, etc. But those aren't advantages that I would expect any game to need.
Has your project experienced any advantages from using XML or binary XML? Just curious. Your project isn't using XML for interchange of data at all (is it?) and data portability wouldn't appear to be a concern, so if you're experiencing other benefits from XML, that would be interesting.
I think part of the problem here is classic industry hype. XML really doesn't solve very many problems, but it sure got sold that way.
On another note, when is 0 A.D. going to be playable? (I loved AOM!):+)
Are you certain that application was implemented well? I find it hard to believe that XML can't handle a mere 20MB of data?! I would be shocked if a dataset 10x that large couldn't be processed as XML.
Now, I totally understand how standard flat files are going to outperform XML every time, but they do serve a different need (i.e. large homogeneous datasets) than XML (i.e. many heterogeneous datasets). So, maybe XML really isn't appropriate for large datasets anyway. Besides, do you really need your large datasets to be self-describing?
Do you have proof? Because this is something I'm actually interested in, and no one I know has a beef with XML's performance and a proof to back up their claims.
Slashdot Mirror
Wouldn't the code simply be considered a trade secret whenever disclosure of it was not allowed? They copyright per se may be expired, but in the formal legal sense, a trade secret can be maintained indefinitely. (Much like the oft-abused example of KFC or Coke's secret recipes). So, given the proper controls that maintaining a trade secret requires, a company could still keep their source code to themselves.
That may be OT, but FWIW, that was frickin funny. :+)
I'm extremely tardy to this discussion, but I feel it's worth pointing that if any other language out there supported true macros, then Lisp would most likely be dead by now.
Now, I don't see how any other language (that isn't Lisp based itself) could actually support true macros without adopting the same syntax Lisp uses.
But then it would be "Lisp based" (at least superficially) and then you're back where you started (i.e. it's impossible to invent something better than Lisp because Lisp is perfect already).
As someone who is now endeavoring to learn Lisp for fun (and who knows, maybe profit someday), this point has been made very clear to me by what I've been reading.
So, on that note: Do you know of a language besides Lisp that supports true macros? If so, I'll be there in a heartbeat as I don't really want to associate with such a conspicuously smug community if I can help it. If not, then I guess that's that.
Thanks in advance for your response.
The bad thing about macros, is that it can slide out of your control, thus making a language not even you yourself can understand.
:), that newer languages don't really support yet, I'm wondering how I can partake of the macro magic goodness without having to immerse myself in a positively opaque and smug community of folks who, for the most part, only get to practice this magic as a hobby.
:+)
OK, now I think you've hit the nail on the head with this observation; as I've heard this difficulty related to me by long time LISPers before. I've read some LISP macro code, and it looks anything but simple. It's just not a pleasure to look at. So, I'm wondering, is there a way to make this a more pleasant task (with or without LISP)?
Really, if Python, Ruby, or the like really supported macro expansion (and truly compiled executables, etc. (and no py2exe and its ilk doesn't actually count)), we wouldn't be having this conversation. But since this appears to be "The Last Great Feature" of LISP (aside from that sexy parenthesis based syntax you all seem to love
So, am I making sense? I want to be able to take this into my work life (.NET and J2EE preferably - hold yer fire; I have a family to feed!). Please, save me from the upcoming trend of code generation that is going to drown us all in a mountain of unintelligible code!!!
(Yeah, I want it all!
That is cool. Now I get it. Don't lose that example; it works.
I heard some vague talking up of macros before and I sort of understood the superficial impact of it, but I hadn't seen an example like that before that kind of hits home.
Now, having said that, I can easily come back with something like "yeah, but I can do the same thing in Java with a helper class that has a bunch of methods; then instead of using my mystical magical LISP macro thingy that no one will understand, I just call my methods when I need them". And that would be true. But I think the "magic" here in LISP is that by going at it with macros and using those to change the appearance of your programs, you're providing a sort of cognitive shift to the programmer where they can think about each category of problem in the system as a "mini-language". That renders a way for the programmer to feel like they're in control and like the solution feels more elegant, because it's less encumbered by syntactical baggage. Is that about right in your experience?
Well, between this and Ruby, I'll have my hands full for a while. Who knows, I may even do something useful with them someday. (Heck, it worked out that way when I went and learned Python on a lark.)
Thank you!
He did not say that the article would convince them, merely that they would be convinced-he doesn't even say when that would be.
I'm not going to waste a lot of time on this, but since we're being picky, it's probably worth noting that he also did not state what the reader ought to be convinced of.
Also, I'm not a believer in relativism, though it could appear that way based on how I talk and write. I do believe however that everyone's perspective is unique (yes, it's relative) because that perspective is complex as it's constituted by many, many conditions (absolutes). So, no I don't believe in relativism as it's usually understood, but I do believe in 'perspectivism' in that an outsider to another's perspective/context usually does not (and usually can not) have enough information to decide whether a given statement really applies to another individual or group.
To use your above example: assembler may indeed be the best tool for a given string processing task under Unix given certain conditions (such as - absolutely huge amounts of data to be processed in a complex way where developer productivity doesn't matter, but processing time does; as such as the programmer in question only knows assembler and can get the job done pretty quickly that way and doesn't want to take the time to learn Perl or Tcl). That doesn't mean that it would always be the best choice, but the determination of the best choice is ultimately a locally objective judgement (what most people mean when they say "it's subjective") based on a complex situation.
Relativism (as most people use it), you can't live with it; and you can't live without it (as I think it ought to be understood).
This article [paulgraham.com] will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.
And if you are smart and open minded, you might just be able to accept that it wouldn't convince a smart and open minded person. For instance: they might already be convinced so, despite the merits of the article, it can not convince them.
Nice (unintentional?) troll...
I'd elaborate but people attached to their own languages won't believe.
Please do elaborate. Anyone I know who loves LISP (especiall the macros) has seen it as the "one true way", but I've never had anyone be able to explain the magic to me. Heck, I did some LISP programming for a graduate AI course I did a few years ago, and I still didn't see the magic.
So, if you could finally clear this up for me, I'd appreciate it.
During his interview with 60 Minutes a couple weeks or so ago, he flat out said that he would not be making 7,8, & 9. Not only that, he doesn't see anyone carrying that torch either.
You may claim you can take it or leave it, but you really do project a sort of disappointed wistfulness about the subject. Maybe you just expected too much?
As far as his vanishing goes - all in good time. To my knowledge, we all die sometime. Till then, we may as well have some options. New talent will emerge with the usual noise to signal ratio.
I think not. The only people struggling here are the ones coming to grips that Lucas doesn't owe them anything. He's got nothing left to prove. He doesn't have to care what anyone thinks. If he wants to spend the rest of his days commissioning high-end corporate campuses for his pet projects (a hobby of his), that's his prerogative.
My only "regret" about his career is that he's not going to make the last 3 movies in the series of original 9 books. I have confidence though, that if he thought they would be worth making, that he would have already done that.
Notice this quote from his interview: "I've earned the right to fail, which means making what I think are really great movies that no one wants to see."
And kudos to him. Hopefully, he can squeeze off some more masterpieces before that heart supporting that great furry frame of his gives out.
Linus sided with Larry, despite the fact that Linux, GNU, Samba, and everything else we run has had to rely on reverse engineering of proprietary formats, devices, and protocols since forever just to function.
Enlighten me here... Linus focuses on Linux. He doesn't work on Samba, WINE, or anything else that attempts to emulate something else in order to function. He doesn't really even reverse engineer (to my knowledge) any specific flavor of Unix. He just works on improving Linux.
The heart of this conflict is the idea of using reverse engineering to ride on the research and development of an industry player who has chosen to remain proprietary in order to compete with that entity. Granted, defending against this is really the domain of patents, but I think I understand where Linus is coming from here by defending Larry.
To answer to your examples - Samba was needed to get interoperation with the product of a company that exerts an effective monopoly. Reverse engineering of existing device drivers has been done in order to interoperate with those drivers, not compete with those driver makers.
BitKeeper has no monopoly. It may in fact be THE best of breed implementation, but that's irrelevant. Samba had to be done. A reverse-engineering of the BitKeeper protocol just to save time on developing a good approach using OSS is an endeavor with questionable ethical status and really isn't necessary. Also, reverse engineering BitKeeper just so people can access the data is obviated by the fact that they can (someone correct me here if I'm wrong as I haven't tried this myself) use CVS instead to access that data. BitKeeper doesn't need to be reverse engineered to get to the data. Right?
Now, please tell me how Linus is acting inconsistently?
In short, I would say that reverse engineering something in order to interoperate with it is a completely different ethical matter than trying to reverse engineer something in order to effectively clone it then compete with it. Saying that Linus' position is "inconsistent" because he does not approve of all uses of reverse engineering does not show an appreciation of the fact that not all uses of reverse engineering are ethically equivalent (just as not all uses of firearms, chemicals, matches, etc. are ethically equivalent).
If one of the goals of OSS is to effectively steal the R&D of industry players, then it will receive the fate it would so richly deserve. But, if the goals of OSS include making established non-novel technologies widely available to everyone (e.g. Linux), or even promoting new R&D to create new novel technologies (e.g. BitTorrent), it will thrive and be better than what could possibly be achieved in a proprietary environment.
If he had, he would have at least made some mention of WoW's guilds and friends list and on what an impact that can have on player activities in the game. Regularily scheduled guild events, consistent contact with the same people, getting to know other folks over time through chat, etc. are, for me, turning out to be more interesting parts of the WoW experience than I expected.
But the author didn't discuss any of that. Witness this key quote:
Though the subscriptions support my theory, my primary reasoning is that this is due to the kind of game World of Warcraft is. Most players in World of Warcraft have no reason to engage in long-term socialization. Without socialization, the main draw the game has always been the novelty of the game play. This is so evident that even the world, with its nice variety between zones, doesn't feel worldly enough: it lacks "epic" and feels like a game.
If the only loyalty that players have to World of Warcraft is in the novelty of the game mechanic, this leaves it vulnerable on at least two very important fronts. The first front: once players grow bored of the game mechanic, there's no reason to hang around anymore. The second front: Players will be easily distracted by another game with better core mechanics.
Maybe he's just approaching the game "all wrong", but I think he's missed something here.
One last thing, it does not take a genius to predict that "what goes up, must come down". The real question isn't whether WoW will be a top 5 game for a long period of time, the real question is whether it will be fantastically profitable to Blizzard and give them the breathing room they need to indulge in creating rich new content, game mechanics, social situations in the game, etc.
I think you hit the nail on the head. I wish I had mod points for your post.
Being impressionable and in a sensitive position means you are ripe for the harvest in a counter intelligence situation. You will be much easier to convert to the opposition's cause as it will be much easier to have you see the issue from their point of view and develop sympathy for their position.
A flexible mindset isn't automatically an overly flexible mindset; it's just that much more prone to changes over time. A changed mindset and set of beliefs can manifest as treason.
So, in a way, the IDF is doing those soldiers a favor. They protecting Israel from an increased likelihood of treason, and they're protecting those soldiers from themselves.
Yeah, it's kind of a control freak thing, but it *is* a military organization.
Just out of curious (cause I'm that sort): how low are we talking here? And why?
I'm your typical not-so-low-budget sort and while I can understand most of the "hows", I don't think I understand most of the "whys".
Synchronizing with Oracle light would definitely be easier with Oracle; can't dispute that. I imagine that one could make that easier when doing it from SQL Server by using a data pump product, but then the cost goes up.
:+)
As far as querying XML files goes, that's actually a pet peeve of mine. While one could maybe build some cool stuff around XML storage, the whole idea is just wrong-headed IMO as one ought to be querying a database and not flat text files. But then, I may just be prejudiced.
I would think the bigger problem with forcing your team to use SQL Server would be the fact that they prefer and are skilled with Oracle. I'm a little surprised that no one seems to have taken that into consideration when choosing database products.
Oh well. Best of luck!
Just out of curiosity, what missing features are you talking about? I know Oracle has a far richer history and therefore feature set, but I had dismissed most of those as curiosities rather than essential.
Actually, Gabe has apologized about the September 2003 fiasco. AFAIK, he originally put that date together in good faith with the information he had at the time. As things slipped more and more in the project, he just didn't want to face it. So, he ostrich'ed. According to what I've read, it's one of his big regrets and he has acknowledged that it was stupid.
No, I don't know the guy, but that's what I know about the situation.
I will agree that the gaming industry is weird. But it's not any weirder that any other entertainment industry. Eccentricity is bound to run rampant in an industry where entertainment is the key deliverable. Creativity has to be given a safe zone in which to flourish; which only occurs through failure and learning from mistakes.
As far as DRM in general goes, I agree with that too. People in general won't put up with security related inconveniences where their entertainment is concerned. What's scary though is that we'll probably all just throw all of our rights away the very moment that DRM and other security initiatives becomes effectively transparent. Now THAT I care about.
I did check that out a while back. It looks very nice, but I found myself wondering if it could be used for "real work". By that I mean the sorts of hideously feature rich corporate intranet applications that I typically work on. It seemed like it would be a nice start, but more complex features seemed like they would require a chunk more of work on the rails framework.
Anyway, I hope Ruby On Rails (and frameworks like it) become such obvious no-brainers that there will be no good excuse to use things like ASP.NET and JSP in the future. I know there is hope! My last project was a Java web application (one of those hideously complex intranet ones) and I managed to get us to use the Jakarta Tapestry framework for the UI layer. The OSS world keeps on getting better and better.
Anyway, best of luck on your snowboard shop!
Umm... yeah, well *I* predicted that XML would never get adopted because it was so expensive (CPU-wise) to use. But, gee, I guess I was wrong.
So, apparently, the cost of XML parsing is acceptable. Which makes all of the so-called dumbasses the decision makers and you and I, the peons. So take your superior attitude and shove it.
I happen to be painfully aware of the tradeoffs XML makes. But the industry chose to embrace it. Now that we've embraced XML, it's suddenly not efficient enough. I'm just trying to make sense of all this. Given that XML is meant to be human readable and self-describing, there really is NO TECHNICAL REASON WHATSOEVER to use it. So, we're back to human factors, where compiler theory doesn't matter one whit.
You know, it's probably good you posted as AC. That way no one would know that you chose to disengage the more important parts of your brain before firing a full salvo of completely correct and completely irrelevant trivia. Typical nerd...
The other side to this coin is that most of the time XML is being used, it doesn't need to be used. If the primary benefits of XML are 1) human readable format and 2) self-describing data and your project doesn't need either of those, then why use XML at all?
XML's performance will always pale in comparison to flat data or binary data, but then it has advantages that come with the trade-off.
If you're spending 100 hours/week working with Ruby, you'd better have feature points coming out of your ears! :+)
Anything you can say about the project? It sounds cool. Just curious.
To my way of thinking, XML is to ease data interchange and make data portable. It's mainly useful when you want to have data that's 1) human readable and 2) self-describing. There are inherent advantages in those two characteristics that lend themselves to open standards, easy modification, etc.
So, if you don't need those characteristics, why use XML at all? Do you need those characteristics on small devices? Aren't we just talking about all the ways XML falls apart when it's abused?
I don't understand why you wanted to use XML for a game anyway. Aside from easy file validation with a schema or DTD, you wouldn't benefit from it anyway.
:+)
To my way of thinking, XML is to ease data interchange and make data portable. It's mainly useful when you want to have data that's 1) human readable and 2) self-describing. There are inherent advantages in those two characteristics that lend themselves to open standards, easy modification, etc. But those aren't advantages that I would expect any game to need.
Has your project experienced any advantages from using XML or binary XML? Just curious. Your project isn't using XML for interchange of data at all (is it?) and data portability wouldn't appear to be a concern, so if you're experiencing other benefits from XML, that would be interesting.
I think part of the problem here is classic industry hype. XML really doesn't solve very many problems, but it sure got sold that way.
On another note, when is 0 A.D. going to be playable? (I loved AOM!)
Are you certain that application was implemented well? I find it hard to believe that XML can't handle a mere 20MB of data?! I would be shocked if a dataset 10x that large couldn't be processed as XML.
Now, I totally understand how standard flat files are going to outperform XML every time, but they do serve a different need (i.e. large homogeneous datasets) than XML (i.e. many heterogeneous datasets). So, maybe XML really isn't appropriate for large datasets anyway. Besides, do you really need your large datasets to be self-describing?
Do you have proof? Because this is something I'm actually interested in, and no one I know has a beef with XML's performance and a proof to back up their claims.