...putting an insanely unreasonable clause in your EULA is a form of marketing now. Before today I had never heard of Radlight. No such thing as bad publicity, I suppose.
Whenever I read articles about this I think about the free amusement park in the movie "Pinnochio" that turns you into a donkey. Moral of the story: There's no such thing as a free lunch.
A lot of online services use.ASP's and.JSP's to create dynamic content on their web pages. It would be easy (although time consuming) to reverse engineer their URL structure and use a HTML parsing library to parse the resulting web page, thereby creating your own API. Might make for a good open-source project.
If the only types of games that Java can truly implement and make platform-independent are (relatively) slow, light on graphics, or "written for smaller segments of the market", is it really worthwhile to pursue this as some sort of holy grail?
Sure, it's easy enough to write Tetris in Java and make it platform independent, but how does that help the people hanging on to their Windows platform in order to use Unreal 7, Wolfenstein 6D, and Tribes 4?
As of last week, these are the top selling PC video games (according to ArsTechnica.com):
1) Command & Conquer Renegade
2) Medal of Honor: Allied Assault
3) The Sims: Hot Date
4) The Sims
5) RollerCoaster Tycoon
6) Harry Potter and the Sorcerer's Stone
7) Civilization III - Infogrames
8) Zoo Tycoon
9) Entertainment Multi Pack
10) The Sims: Livin' Large
I would bet at least half of these games could be written in Java and still have the same level of game performance. In addition, I would bet they would cost 20% less, take 20% less time, and not require any additional costs to port to other platforms (or additional distribution or maintainence costs for different versions).
As a professional Java developer, an avid gamer, and a hobbyist game developer, I can tell you that there is no way this is going to work for certian types of games. Quake [X] will never be written in Java.
However, many types of games (RTS, for example) almost beg to be written in Java for two reasons:
1) They need good game logic (and design) and not high framerates in order to be sucessful. Java fosters good design and is less prone to errors (buffer overflow anyone?) while still allowing for acceptable graphics performance.
2) Because of a Java app's inherient portability, games can be written for smaller segments of the market that couldn't be written before because the limited market, limited even further by a specific platform, did not warrant the cost of development (and porting to other platforms).
This is what government is for. If we spent half the money on this that we spend on those two horrible asteroid movies, we wouldn't have a thing to worry about.
I've written two applications with the Microsoft Speech Recognition and Text-To-Speech engines, and that has taught me enough to know that turning it on by default is a REALLY bad idea. Of course, M$'s speciality is turning things on by default that shouldn't be on, so this does not really suprise me.
And following the methodology has no overhead?
What I'm saying is that if you follow the methodology, you get all the benfits (like modularity) without having to always concentrate on how to achieve them...they almost happen naturally. Yes, there's an overhead involved, but you get way more than you put in. Rarely to never have I seen software with a decent OO design have less unnecessary code rather than more..
You're right about the call stack length, however good OO design fosters (almost forces) the designer to think long and hard about the problem space. The result is an OO design that more closely models the problem than a procedural design. And the smaller the 'distance' between your model and the actual problem, the more efficent your design. (Again, the fastest code is the code not executed). Basically, you trade some raw performance for logic optimizations, and as any computer scientist knows, a better algorithm beats raw computing power any day of the week.
You're wrong is so many places I'm just going to make a list.
Software engineering methodologies in general (and OOP in particular):
- Are always worthwhile for non-trivial systems because their overhead is linear (as a function of system size) while software errors and complexity are exponential.
- Require no additional work to add modularity (the ability to replace or change components). It is a natural function of following the methodology.
- Require no managerial oversight unless the programmer does not understand the methodology (which is standardized, so he can learn it from a book)
- Reduce QA time by allowing for unit testing and pre-QA'd components.
- Reduce program complexity by replacing complex procedural code with simple polymorphic objects. The net result is less lines of code, less code paths, but the same functionality.
- Can increase system performance through efficent design. (The fastest code is the code not executed)
- Do not guarantee program correctness, but do reduct the cost (a.k.a Time) to achieve it if used properly.
And I have 5 years of Object-Oriented development experience to back up these claims. Given your posts I doubt you even really undertand OOP.
It's not the FUNCTIONALITY we want to conform to a standard it's the DESIGN METHODOLOGY. There's a big difference.
You can write any application you want using OOP. It doesn't limit your functionality at all. You can use the POSIX standard, or an M$ standard, or the standard from BillyBob's house of code...
Engineering is using a standard methodology to solve general problems. If the problem set the methodology can solve isn't totally general, then the methodology is useless.
Your right, software does change, that's why any software engineering methodology worth it's salt helps you design FOR change.
OOP is a perfect example. By mainaining low coupling through the entire system, you make it very easy to change and replace objects without introducing bugs. So software engineering not only reduces your inital cost, but also your maintainence cost over time.
The best way is just to get a bunch of developers who know that the wild-west approach is a bad idea. If they know going in that they have to have a cohesive and well thought-out design, you won't need the heavy hand of management to get a reliable, well-engineered system.
Yes, you don't need a civil engineering degree to design a dollhouse. But on any non-trivial software project, if you don't apply some good software engineering practices (OOP and UML come to mind), it's going to take you twice as long, cost twice as much, and have twice as many bugs.
The inherient problem in "methodless" software development is that there's no standard way of thinking about design. Engineering is all about formalizing the design process so that any other engineer can understand it. Give a blueprint for a bridge from one engineer to another and it will take him about a day to understand it all. Try doing that with any reasonably sized software system. Unless you've stuck to a strict design principle that both the devlopers understand, it'll take you months to sort out how the system works.
We need more disciplines like this
on
Security Engineering
·
· Score: 3, Interesting
Software development, on the whole, is not practiced as an engineering discipline. It needs to be. Software engineers should be certified just like civil engineers or electrical engineers, and when something breaks, the company shouldn't be able to hide behind the EULA...they should be fully accountable.
This would make software much more reliable and siginificantly reduce the maintence cost for users.
Many 'Senior Design' (aka Capstone) courses are ideal for open-source projects. You gain valuable experience, contribute to the open-source community, and get course credit! Plus, sometimes these projects translate into actual jobs when you get out of school.
Many professors will let you work on O.S. projects if you find one than can be completed in the alloted time, and if it's relevant to some of your other coursework. Of course, this depends greatly on the professor, but you'll never know if you don't ask.
This whole fight over musicians and artists between the record companies and Napsteresque services is like two convicts arguing over who owns a prison bitch. Either way musicians wind up tossing someone's salad.
When big name bands finally figure out that the best way to sell thier music is direct to the people, both we, and the artists, will be a lot better off.
Rational Rose has some of what you're looking for, but the best way might just be a big, fat whiteboard, a digital camera (for taking pics of the whiteboard), and some elbow grease.
In order to collect the information necessary to do that, you would have to invade people's privacy on a grand scale.
Imagine getting tons of porn spam becuase all the marketing companies know you like pr0n...and that information is available to anyone who wants to buy it.
The less that marketing companies know about me, the better. Even if it means I have to wade through lots of pointless popups.
Posit:
This process works, exact replicas of human organs can be grown and implanted into patients with phenominal success.
Effect:
Millions of americans decide that quitting smoking, losing weight, and all manner of healthy activity are not worth the trouble because science can simply cure them.
Result:
Health care costs skyrocket. General levels of health decrease.
So I ask...how would we prevent this? Make smokers pay for thier own lung transplants? Alcholoics pay for their own liver?
I'm working on a software project with a few friends, and whenever we talk about highly sensitive stuff, or send source code, we always PGP encrypt our messages.
Also, if i'm at work and I want to send sensitive material home to work on, I'll usually encrypt it to my own key before I send it.
The fact of the matter is, though, most people don't think what they have to say is worth protecting with encrpytion...and most of the time, they're right.
What we need is completely transparent use of PGP in an e-mail client. The user should never know it's there at all.
The point is not that Microsoft shouldn't give it's software to poor schools (considering it costs them nearly nothing to copy they should have been doing it anyway)
The point is that Microsoft has committed a crime and needs to be punished, not rewarded...
So your assertion is that God simply know ALL the possible outcomes but not which particular outcome will occur?
So if you were sitting at a baseball game with God and you asked him who was going to win, he couldn't tell you. He could tell you all the possible different ways one of the two teams could win, and he could tell you the probabilities of any of those outcomes, but he couldn't tell you who is going to win?
That's not omniscience. Given enough time and money, I could get a computer to do that. When you think about it logically, there are only two possible answers:
a) God is not omniscient (or he does not exist)
b) Man does not have free will
The trouble is that both of those options are so disturbing to humans that they will refuse to believe what is obviously true.
Slashdot Mirror
...putting an insanely unreasonable clause in your EULA is a form of marketing now. Before today I had never heard of Radlight. No such thing as bad publicity, I suppose.
Whenever I read articles about this I think about the free amusement park in the movie "Pinnochio" that turns you into a donkey. Moral of the story: There's no such thing as a free lunch.
A lot of online services use .ASP's and .JSP's to create dynamic content on their web pages. It would be easy (although time consuming) to reverse engineer their URL structure and use a HTML parsing library to parse the resulting web page, thereby creating your own API. Might make for a good open-source project.
If the only types of games that Java can truly implement and make platform-independent are (relatively) slow, light on graphics, or "written for smaller segments of the market", is it really worthwhile to pursue this as some sort of holy grail?
Sure, it's easy enough to write Tetris in Java and make it platform independent, but how does that help the people hanging on to their Windows platform in order to use Unreal 7, Wolfenstein 6D, and Tribes 4?
As of last week, these are the top selling PC video games (according to ArsTechnica.com):
1) Command & Conquer Renegade
2) Medal of Honor: Allied Assault
3) The Sims: Hot Date
4) The Sims
5) RollerCoaster Tycoon
6) Harry Potter and the Sorcerer's Stone
7) Civilization III - Infogrames
8) Zoo Tycoon
9) Entertainment Multi Pack
10) The Sims: Livin' Large
I would bet at least half of these games could be written in Java and still have the same level of game performance. In addition, I would bet they would cost 20% less, take 20% less time, and not require any additional costs to port to other platforms (or additional distribution or maintainence costs for different versions).
As a professional Java developer, an avid gamer, and a hobbyist game developer, I can tell you that there is no way this is going to work for certian types of games. Quake [X] will never be written in Java.
However, many types of games (RTS, for example) almost beg to be written in Java for two reasons:
1) They need good game logic (and design) and not high framerates in order to be sucessful. Java fosters good design and is less prone to errors (buffer overflow anyone?) while still allowing for acceptable graphics performance.
2) Because of a Java app's inherient portability, games can be written for smaller segments of the market that couldn't be written before because the limited market, limited even further by a specific platform, did not warrant the cost of development (and porting to other platforms).
This is what government is for. If we spent half the money on this that we spend on those two horrible asteroid movies, we wouldn't have a thing to worry about.
I've written two applications with the Microsoft Speech Recognition and Text-To-Speech engines, and that has taught me enough to know that turning it on by default is a REALLY bad idea. Of course, M$'s speciality is turning things on by default that shouldn't be on, so this does not really suprise me.
I'd rather tax companies (and have those costs passed on to consumers) than pay more in income taxes.
And following the methodology has no overhead?
What I'm saying is that if you follow the methodology, you get all the benfits (like modularity) without having to always concentrate on how to achieve them...they almost happen naturally. Yes, there's an overhead involved, but you get way more than you put in.
Rarely to never have I seen software with a decent OO design have less unnecessary code rather than more..
You're right about the call stack length, however good OO design fosters (almost forces) the designer to think long and hard about the problem space. The result is an OO design that more closely models the problem than a procedural design. And the smaller the 'distance' between your model and the actual problem, the more efficent your design. (Again, the fastest code is the code not executed). Basically, you trade some raw performance for logic optimizations, and as any computer scientist knows, a better algorithm beats raw computing power any day of the week.
You're wrong is so many places I'm just going to make a list.
Software engineering methodologies in general (and OOP in particular):
- Are always worthwhile for non-trivial systems because their overhead is linear (as a function of system size) while software errors and complexity are exponential.
- Require no additional work to add modularity (the ability to replace or change components). It is a natural function of following the methodology.
- Require no managerial oversight unless the programmer does not understand the methodology (which is standardized, so he can learn it from a book)
- Reduce QA time by allowing for unit testing and pre-QA'd components.
- Reduce program complexity by replacing complex procedural code with simple polymorphic objects. The net result is less lines of code, less code paths, but the same functionality.
- Can increase system performance through efficent design. (The fastest code is the code not executed)
- Do not guarantee program correctness, but do reduct the cost (a.k.a Time) to achieve it if used properly.
And I have 5 years of Object-Oriented development experience to back up these claims. Given your posts I doubt you even really undertand OOP.
You're missing the point.
It's not the FUNCTIONALITY we want to conform to a standard it's the DESIGN METHODOLOGY. There's a big difference.
You can write any application you want using OOP. It doesn't limit your functionality at all. You can use the POSIX standard, or an M$ standard, or the standard from BillyBob's house of code...
Engineering is using a standard methodology to solve general problems. If the problem set the methodology can solve isn't totally general, then the methodology is useless.
Your right, software does change, that's why any software engineering methodology worth it's salt helps you design FOR change.
OOP is a perfect example. By mainaining low coupling through the entire system, you make it very easy to change and replace objects without introducing bugs. So software engineering not only reduces your inital cost, but also your maintainence cost over time.
The best way is just to get a bunch of developers who know that the wild-west approach is a bad idea. If they know going in that they have to have a cohesive and well thought-out design, you won't need the heavy hand of management to get a reliable, well-engineered system.
Yes, you don't need a civil engineering degree to design a dollhouse. But on any non-trivial software project, if you don't apply some good software engineering practices (OOP and UML come to mind), it's going to take you twice as long, cost twice as much, and have twice as many bugs.
The inherient problem in "methodless" software development is that there's no standard way of thinking about design. Engineering is all about formalizing the design process so that any other engineer can understand it. Give a blueprint for a bridge from one engineer to another and it will take him about a day to understand it all. Try doing that with any reasonably sized software system. Unless you've stuck to a strict design principle that both the devlopers understand, it'll take you months to sort out how the system works.
Software development, on the whole, is not practiced as an engineering discipline. It needs to be. Software engineers should be certified just like civil engineers or electrical engineers, and when something breaks, the company shouldn't be able to hide behind the EULA...they should be fully accountable.
This would make software much more reliable and siginificantly reduce the maintence cost for users.
Many 'Senior Design' (aka Capstone) courses are ideal for open-source projects. You gain valuable experience, contribute to the open-source community, and get course credit! Plus, sometimes these projects translate into actual jobs when you get out of school.
Many professors will let you work on O.S. projects if you find one than can be completed in the alloted time, and if it's relevant to some of your other coursework. Of course, this depends greatly on the professor, but you'll never know if you don't ask.
This whole fight over musicians and artists between the record companies and Napsteresque services is like two convicts arguing over who owns a prison bitch. Either way musicians wind up tossing someone's salad.
When big name bands finally figure out that the best way to sell thier music is direct to the people, both we, and the artists, will be a lot better off.
Rational Rose has some of what you're looking for, but the best way might just be a big, fat whiteboard, a digital camera (for taking pics of the whiteboard), and some elbow grease.
In order to collect the information necessary to do that, you would have to invade people's privacy on a grand scale.
Imagine getting tons of porn spam becuase all the marketing companies know you like pr0n...and that information is available to anyone who wants to buy it.
The less that marketing companies know about me, the better. Even if it means I have to wade through lots of pointless popups.
Posit:
This process works, exact replicas of human organs can be grown and implanted into patients with phenominal success.
Effect:
Millions of americans decide that quitting smoking, losing weight, and all manner of healthy activity are not worth the trouble because science can simply cure them.
Result:
Health care costs skyrocket. General levels of health decrease.
So I ask...how would we prevent this? Make smokers pay for thier own lung transplants? Alcholoics pay for their own liver?
It makes for an interesting question.
I'm working on a software project with a few friends, and whenever we talk about highly sensitive stuff, or send source code, we always PGP encrypt our messages.
Also, if i'm at work and I want to send sensitive material home to work on, I'll usually encrypt it to my own key before I send it.
The fact of the matter is, though, most people don't think what they have to say is worth protecting with encrpytion...and most of the time, they're right.
What we need is completely transparent use of PGP in an e-mail client. The user should never know it's there at all.
A wise man once said:
"Computer Scientists are just Electrical Engineers who can't do calculus and MIS majors are just Computer Scientists who can't code"
My thought has been, anything you can do with a MIS degree, you can do better with a CS degree.
Return to Castle Wolfenstein. Hands down the best game for the holiday season.
Killing Nazis is fun for for the whole family.
The point is not that Microsoft shouldn't give it's software to poor schools (considering it costs them nearly nothing to copy they should have been doing it anyway)
The point is that Microsoft has committed a crime and needs to be punished, not rewarded...
"a) skirt around the meaning of 'omniscient' "
Good old option a)...everyone seems to love it
So your assertion is that God simply know ALL the possible outcomes but not which particular outcome will occur?
So if you were sitting at a baseball game with God and you asked him who was going to win, he couldn't tell you. He could tell you all the possible different ways one of the two teams could win, and he could tell you the probabilities of any of those outcomes, but he couldn't tell you who is going to win?
That's not omniscience. Given enough time and money, I could get a computer to do that. When you think about it logically, there are only two possible answers:
a) God is not omniscient (or he does not exist)
b) Man does not have free will
The trouble is that both of those options are so disturbing to humans that they will refuse to believe what is obviously true.