Yeah, it was just last week I overheard my IT director asking the CIO, "Do you really want to be Bill's bitch?"
Wouldn't have minded, but he said, "Sure, I get a pink diamond studded collar to wear"
Re:Piracy is going to strengthen subscription mode
on
GTA: San Andreas Leaked
·
· Score: 2, Insightful
Yeah, because companies that produce high quality games never make any money from them at all. Ever.
I'm not saying you're necessarily wrong - but if that does happen, it's due to corporate greed and not because of an inability to fund development through standard sales.
Whether the market stands for it is an interesting question.. I haven't played Rome Total War for a week - I'd be very resentful if I'd had to pay for a week's subscription to be unable to play it - especially since I am playing Battlefield Vietnam instead. Seeing as 'per use' payments are definitely not accepted by the mass market (notice all the MMORPGs charging flat rates) the average gamer can not and will not pay for multiple subscriptions just because he has several games that he hasn't finished playing yet. So it may well be that such a subscription model wont fly anyway..
MMORPGs are an interesting counter to my argument - they are indeed charging per-month subscriptions and making a lot of money (collectively) by doing so. However, they are all also continually evolving and adding new content, and also providing a compelling social experience - that social experience is fundamental to their product, and not present in a single-player game.
Thing is, almost nobody ever designs up-front to the level of detail where they know precisely and exactly what their code is doing.
So you may well know at a macro level "This code is calculating tax" but while writing your code you need considerably more detail than that. Most people will go horribly wrong if they stop at that macro level; constant compile/test cycles help you break down the coding itself into small tasks, each of which you can then apply adequate thought to and perform the detailed design of that tiny piece of the puzzle - and then validate that you've implemented it correctly and it does what you expect.
The sales tax calculation may be a 20 line block of code. I don't need a novel describing it to me - the method name is pretty comprehensive all by itself.
I agree it may be useful to have some method documentation though - what is the parameter, what will be returned, are there any error conditions (in which case when will they occur and how will they be reported), etc.
What I don't want is all that documentation preventing readability of the code. The line of code above is simple, concise and can be interpreted by a non-programmer. If all code is written in such a manner then it makes grokking an entire system far simpler, and thus reduces the need for extensive documentation.
I'd far rather have easy to read code than excessive reams of developer ramblings describing it.
If you don't compile every few minutes, you're running your tests every few minutes.
If you're not running your tests, how do you know your code works?
If you're not compiling and testing, how are you figuring out what the code you're writing is meant to be doing?
I used to code for a day without compiling, then sit in amazement as my code compiled first time. Luckily computers are faster now and it doesn't take the better part of an hour to recompile - it takes a few seconds - long enough to pick up my coffee, take a sip and think about the next test I'm going to write.
Now that I compile more often, and run tests several times an hour, my code is immensely higher quality, I write it faster, I spend far less time sorting out compile errors and random bugs and I can safely walk away from the computer with just a couple of minutes notice without worrying about leaving a nasty mess that it'll take me a couple of hours to understand, finish and compile the next day.
In other words, thanks for the advice, I'll follow it if I want to return to where I was a decade ago.
In the UK it's illegal to rip your own mp3 collection. There is no 'fair use' provision in law.
What I'm far less sure about is the legality of sharing such material over the 'net. I suspect that's also covered. Heck, you get charged with "producing child pornography" if you just view such an image, because you've had to create a new copy of that image in the memory of your computer. The dastards will stop at nothing to get you.
~Cederic (who has a need for Britney Spears, but it's nothing to do with music)
I have to stop at 17 junctions and/or traffic lights, in addition to general changes in speed: that's a lot of going into neutral and/or changing gears; that's also just my first three miles on the 55 miles home in an evening.
So whether I drive like an idiot or not, there's a tremendous amount of clutch work required. Being able to avoid braking is utterly irrelevant; when the car is stationary it must be in neutral (or clutch depressed) or the engine will stall. To move again that situation must change.
Operating a clutch hurts my knee. I'd rather skip the pain and drive an automatic - idiotically or otherwise.
Some people probably picked up on the "Even driving an automatic I get constant pain from my knee" part of my message.
Simple fact: Working the clutch on a 12 minute commute did noticeable damage to my knee.
I'm now doing a 55 mile commute. For most of that my left leg would be idle even driving a manual. For the rest (which accounts for 20-50 minutes, depending on time of day, roadworks, accidents, etc) my car is constantly either in stop-go traffic, or changing speed.
Manuals are not FAR superior to automatics when using a manual means walking on crutches your whole life. I'd rather use an automatic and retain the ability to actually walk. Trust me, I would drive a manual out of reference, were it not for my knee. However, that preference isn't strong enough for me to cripple myself.
~Cederic ps: I also broke my left ankle in July. Two days after the break I was driving again - something I suspect I wouldn't have been doing in a manual. Not to put too fine a point on it "every way possible" is clearly bullshit.
>> anybody who'd buy an auto trans where a manual was availible would steal sheep
If I drove a manual for my daily commute I'd be registered disabled, permanently limping and in constant pain - due to the wear and tear on my left knee.
By driving an automatic I get to avoid all that (well, except the constant pain).
>> Java generics don't provide any performance benefit
On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.
That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.
>> Autoboxing: this feature removes clarity from the language.
I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with
List listOfNumbers = new List(); listOfNumbers.add(5); System.out.println ("Number added = " + listOfNumbers.get(0));
Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.
>> Enums
That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on.equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be.equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.
>> Annotations: I really don't see the point of this.
It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.
See the Apache Beehive project for an indication of what can be achieved with these things. (e.g. a one line annotation to turn a class into a web service - that's a lot of code you didn't have to write).
Personally I think they add a lot of complexity to the language, and that does (as your post's main thrust seems to suggest) make the language weaker - not because it's less capable, but because it's harder to understand and to write. Note that I'm not lazy, I'm not looking for a language that does everything for me and doesn't make me think; I'm looking for a language that lets me think about the logic I'm writing, rather than the language mechanics being used to express that logic.
>> New for: This simply makes the code harder to read.
I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the current 'for'. If anything, potentially simpler..
>> Static imports and variable length parameter lists: I think these are well done.
At risk of sounding argumentative, I'm even going to disagree with your only positive comment on the changes.
Static imports add no value that I can perceive. They are there purely to entice users of other languages. I like having use of statically declared values qualified by a classname, it makes the code more readable and adds a little context.
So some of the changes I welcome, others I am more uncertain about, and a couple I'll dissuade people from using (to prevent misuse and aid code readability - where I am, maintainable code counts for a lot). I wouldn't however agree that "They fucked up Java".
You have my sympathy. I've not yet dared try running our J2EE application deployed in Weblogic 6.1 on Java 1.3 in Java 5 - heck, I don't even dare try and compile it:)
Later today perhaps, once I have a little more time.. ~Stuart
Help me out here. Are you after a specifically IBM implementation of the Java VM for Windows, or is there another reason why you can't go to http://java.sun.com/j2se/1.5.0/download.jsp and download the Windows version from there?
No intent here to flame, just curious about your reasoning..
>> it's one of the major drawbacks of java on the desktop....
>> java is in for a tough fight.
Java is already established, both for server-side code (where it has a major presence) and on the desktop (albeit mostly in the form of tools for people writing server-side Java code).
I don't really care about Java on the desktop, but Eclipse using SWT is an example of very performant Java desktop software. Maybe you wont write the next SETI @Home client in Java, but it has reached usable levels.
Of course, Mono supports other languages, a different set of libraries, and perhaps lacks the maturity of Java - there are too many trade-offs involved for me to recommend one over another, so use whatever makes you happiest.
You stay pragmatic, yet cunningly manage to deride the language for certain low level developments and pigeonhole its use for lightweight temporary code.
Fortunately the rest of the industry recognise that most code fits somewhere in between and thus values the language rather more than you.
Java is less capable than other languages at certain types of development. It is more capable than other languages for other types of development. It is comparable to some languages for some types of development.
Language choice is dependent on language availability, performance characteristics, ease of development, skillset availability, overall costs, portability, personal preference and a few other criteria. It would be unfortunate to label a language as good or bad in all circumstances.
I would hope that 1.2, 1.3 and 1.4 bytecode would run in the 1.5 JRE. I think it's ambitious to expect 1.5 bytecode to run in a pre-1.5 JRE - the language has new features that such JREs don't know about or support.
While you could obviously write code that interprets 1.5 bytecode so that it will run on a 1.4 JRE, and make it possible to automagically create that code at compile-time, including it by default in the compiled 1.5 code would be wasteful as it's not required to run in a 1.5 environment.
So yes, it will inhibit the use of Java 5 by projects that wish to run on JRE1.4. And trust me, I'm extremely distressed that my company is still stuck on Weblogic 6.1 as that only works with JRE1.3, so I haven't even been able to make use of J2SE 1.4 capabilities in code, but life goes on.
Rather than mod you troll, here's a simple answer.
>> Does anyone think it will ever take?
What makes you think it hasn't? A single example: What percentage of Apache Foundation products are written in and/or for Java. Note that Apache Foundation products are used extensively in Enterprise software development, deployment and systems.
Slashdot Mirror
I know a lot of people (read: More than a dozen) who have done the meet, the marry and/or the divorce thing on that particular mud.
~Cederic, wondering who the grandparent Anon Coward is
Yeah, it was just last week I overheard my IT director asking the CIO, "Do you really want to be Bill's bitch?"
Wouldn't have minded, but he said, "Sure, I get a pink diamond studded collar to wear"
Yeah, because companies that produce high quality games never make any money from them at all. Ever.
I'm not saying you're necessarily wrong - but if that does happen, it's due to corporate greed and not because of an inability to fund development through standard sales.
Whether the market stands for it is an interesting question.. I haven't played Rome Total War for a week - I'd be very resentful if I'd had to pay for a week's subscription to be unable to play it - especially since I am playing Battlefield Vietnam instead. Seeing as 'per use' payments are definitely not accepted by the mass market (notice all the MMORPGs charging flat rates) the average gamer can not and will not pay for multiple subscriptions just because he has several games that he hasn't finished playing yet. So it may well be that such a subscription model wont fly anyway..
MMORPGs are an interesting counter to my argument - they are indeed charging per-month subscriptions and making a lot of money (collectively) by doing so. However, they are all also continually evolving and adding new content, and also providing a compelling social experience - that social experience is fundamental to their product, and not present in a single-player game.
~Cederic
We're saying approximately the same thing, just with different emphasis. So I'll just say: Yes, I agree.
Thing is, almost nobody ever designs up-front to the level of detail where they know precisely and exactly what their code is doing.
So you may well know at a macro level "This code is calculating tax" but while writing your code you need considerably more detail than that. Most people will go horribly wrong if they stop at that macro level; constant compile/test cycles help you break down the coding itself into small tasks, each of which you can then apply adequate thought to and perform the detailed design of that tiny piece of the puzzle - and then validate that you've implemented it correctly and it does what you expect.
I didn't say, "Don't design up front."
I kinda skipped a couple of lines of code
balance -= getNewComputer().getCost();
balance -= girlfriend.expenses();
balance -= carLoan;
balance -= etc;
In java,
boolean gotcha = false;
if (gotcha = true)
{
}
This compiles fine; the assignation returns the type of the assignee, which as it's a boolean is acceptable for use in an if statement.
~Cederic
Although ironically you also left in a compile error.
I do prefer to avoid checking multiple constructs in a single statement, but the important thing is, use brackets to start with!
if (this||a==b||c==d)
works fine, but isn't as easy to mentally parse as it would be with brackets - however many spaces are involved.
~cederic
Money tax = calculateSalesTax(order);
The sales tax calculation may be a 20 line block of code. I don't need a novel describing it to me - the method name is pretty comprehensive all by itself.
I agree it may be useful to have some method documentation though - what is the parameter, what will be returned, are there any error conditions (in which case when will they occur and how will they be reported), etc.
What I don't want is all that documentation preventing readability of the code. The line of code above is simple, concise and can be interpreted by a non-programmer. If all code is written in such a manner then it makes grokking an entire system far simpler, and thus reduces the need for extensive documentation.
I'd far rather have easy to read code than excessive reams of developer ramblings describing it.
~Cederic
If you don't compile every few minutes, you're running your tests every few minutes.
If you're not running your tests, how do you know your code works?
If you're not compiling and testing, how are you figuring out what the code you're writing is meant to be doing?
I used to code for a day without compiling, then sit in amazement as my code compiled first time. Luckily computers are faster now and it doesn't take the better part of an hour to recompile - it takes a few seconds - long enough to pick up my coffee, take a sip and think about the next test I'm going to write.
Now that I compile more often, and run tests several times an hour, my code is immensely higher quality, I write it faster, I spend far less time sorting out compile errors and random bugs and I can safely walk away from the computer with just a couple of minutes notice without worrying about leaving a nasty mess that it'll take me a couple of hours to understand, finish and compile the next day.
In other words, thanks for the advice, I'll follow it if I want to return to where I was a decade ago.
Or just write simple code that doesn't need a novel to explain it.
Money balance = startBalance + salary - mortgage;
Tell me precisely wtf I need to comment on that line of code?
~Cederic
>> The Teach Teach Yourself eXtreme Test-driven Agile Development Patterns in 21 Days By Example Bible.. JAVA EDITION!
I think my boss bought that book.
In the UK it's illegal to rip your own mp3 collection. There is no 'fair use' provision in law.
What I'm far less sure about is the legality of sharing such material over the 'net. I suspect that's also covered. Heck, you get charged with "producing child pornography" if you just view such an image, because you've had to create a new copy of that image in the memory of your computer. The dastards will stop at nothing to get you.
~Cederic (who has a need for Britney Spears, but it's nothing to do with music)
>> Strange how everyone else manages it.
Everyone else also manages to run, ride a bike, play tennis, dance and do many other things that I can't do.
Thanks for rubbing it in. I hope you have a good life,
~Cederic
I have to stop at 17 junctions and/or traffic lights, in addition to general changes in speed: that's a lot of going into neutral and/or changing gears; that's also just my first three miles on the 55 miles home in an evening.
So whether I drive like an idiot or not, there's a tremendous amount of clutch work required. Being able to avoid braking is utterly irrelevant; when the car is stationary it must be in neutral (or clutch depressed) or the engine will stall. To move again that situation must change.
Operating a clutch hurts my knee. I'd rather skip the pain and drive an automatic - idiotically or otherwise.
~Cederic
Some people probably picked up on the "Even driving an automatic I get constant pain from my knee" part of my message.
Simple fact: Working the clutch on a 12 minute commute did noticeable damage to my knee.
I'm now doing a 55 mile commute. For most of that my left leg would be idle even driving a manual. For the rest (which accounts for 20-50 minutes, depending on time of day, roadworks, accidents, etc) my car is constantly either in stop-go traffic, or changing speed.
Manuals are not FAR superior to automatics when using a manual means walking on crutches your whole life. I'd rather use an automatic and retain the ability to actually walk. Trust me, I would drive a manual out of reference, were it not for my knee. However, that preference isn't strong enough for me to cripple myself.
~Cederic
ps: I also broke my left ankle in July. Two days after the break I was driving again - something I suspect I wouldn't have been doing in a manual. Not to put too fine a point on it "every way possible" is clearly bullshit.
>> anybody who'd buy an auto trans where a manual was availible would steal sheep
If I drove a manual for my daily commute I'd be registered disabled, permanently limping and in constant pain - due to the wear and tear on my left knee.
By driving an automatic I get to avoid all that (well, except the constant pain).
Of course, your sheep are still not safe..
>> Java generics don't provide any performance benefit
On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.
That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.
>> Autoboxing: this feature removes clarity from the language.
I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with
List listOfNumbers = new List();
listOfNumbers.add(5);
System.out.printl
Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.
>> Enums
That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on
>> Annotations: I really don't see the point of this.
It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.
See the Apache Beehive project for an indication of what can be achieved with these things. (e.g. a one line annotation to turn a class into a web service - that's a lot of code you didn't have to write).
Personally I think they add a lot of complexity to the language, and that does (as your post's main thrust seems to suggest) make the language weaker - not because it's less capable, but because it's harder to understand and to write. Note that I'm not lazy, I'm not looking for a language that does everything for me and doesn't make me think; I'm looking for a language that lets me think about the logic I'm writing, rather than the language mechanics being used to express that logic.
>> New for: This simply makes the code harder to read.
I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the current 'for'. If anything, potentially simpler..
>> Static imports and variable length parameter lists: I think these are well done.
At risk of sounding argumentative, I'm even going to disagree with your only positive comment on the changes.
Static imports add no value that I can perceive. They are there purely to entice users of other languages. I like having use of statically declared values qualified by a classname, it makes the code more readable and adds a little context.
So some of the changes I welcome, others I am more uncertain about, and a couple I'll dissuade people from using (to prevent misuse and aid code readability - where I am, maintainable code counts for a lot). I wouldn't however agree that "They fucked up Java".
~Cederic
You have my sympathy. I've not yet dared try running our J2EE application deployed in Weblogic 6.1 on Java 1.3 in Java 5 - heck, I don't even dare try and compile it
Later today perhaps, once I have a little more time..
~Stuart
Help me out here. Are you after a specifically IBM implementation of the Java VM for Windows, or is there another reason why you can't go to http://java.sun.com/j2se/1.5.0/download.jsp and download the Windows version from there?
No intent here to flame, just curious about your reasoning..
~Cederic
>> it's one of the major drawbacks of java on the desktop.
>> java is in for a tough fight.
Java is already established, both for server-side code (where it has a major presence) and on the desktop (albeit mostly in the form of tools for people writing server-side Java code).
I don't really care about Java on the desktop, but Eclipse using SWT is an example of very performant Java desktop software. Maybe you wont write the next SETI @Home client in Java, but it has reached usable levels.
Of course, Mono supports other languages, a different set of libraries, and perhaps lacks the maturity of Java - there are too many trade-offs involved for me to recommend one over another, so use whatever makes you happiest.
~Cederic
>> what is the point in coding in Java if it won't work on the #2 desktop OS?
Perhaps because it will work on the #1..n server OSes?
You stay pragmatic, yet cunningly manage to deride the language for certain low level developments and pigeonhole its use for lightweight temporary code.
Fortunately the rest of the industry recognise that most code fits somewhere in between and thus values the language rather more than you.
Java is less capable than other languages at certain types of development. It is more capable than other languages for other types of development. It is comparable to some languages for some types of development.
Language choice is dependent on language availability, performance characteristics, ease of development, skillset availability, overall costs, portability, personal preference and a few other criteria. It would be unfortunate to label a language as good or bad in all circumstances.
~Cederic
I would hope that 1.2, 1.3 and 1.4 bytecode would run in the 1.5 JRE. I think it's ambitious to expect 1.5 bytecode to run in a pre-1.5 JRE - the language has new features that such JREs don't know about or support.
While you could obviously write code that interprets 1.5 bytecode so that it will run on a 1.4 JRE, and make it possible to automagically create that code at compile-time, including it by default in the compiled 1.5 code would be wasteful as it's not required to run in a 1.5 environment.
So yes, it will inhibit the use of Java 5 by projects that wish to run on JRE1.4. And trust me, I'm extremely distressed that my company is still stuck on Weblogic 6.1 as that only works with JRE1.3, so I haven't even been able to make use of J2SE 1.4 capabilities in code, but life goes on.
~Cederic
Rather than mod you troll, here's a simple answer.
>> Does anyone think it will ever take?
What makes you think it hasn't? A single example: What percentage of Apache Foundation products are written in and/or for Java. Note that Apache Foundation products are used extensively in Enterprise software development, deployment and systems.
~cederic