Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.
Most people treat JavaScript like its C's retarded little brother, but that's just one of many programming styles that it adapts to. Methods like Array.each and Array.grep allow JavaScript to be used in a very Ruby-like fashion, which, in addition to making the language more comfortable for its target audience, usually results in tighter, more readable code. Extending Array and Object might lead to some exciting bugs in code that doesn't expect it, but I don't see how this makes the practice wholesale wrong. Ruby on Rails does stuff like this all over the place. Being able to say 3.months.ago or some_random_object.to_json is part of what makes Rails such a pleasure to work with, and I don't see why its JavaScript library shouldn't be extended the same freedoms.
To quickly address your other two issues, I got all the documentation I ever needed from this site, and, while unit tests are definitely nice, prototype's proven track record is enough for me. I haven't had the slightest bit of trouble with prototype -- it's done nothing but save me time thus far.
Well, perhaps this is a case where it's best to agree to disagree. Your comments are all valid and well presented, but my experiences have pointed me in a different direction.
Moving between databases hasn't been a big problem for me. Somewhat ironically, the only major issue of this type that I've had to deal with recently involved going from MySQL to Oracle in a Hibernate project, but this was more Oracle's fault than Hibernate's. We did have to resort to a few native queries to work around it however.
That issue aside though, I've found that changing business requirements and aggressive project schedules are a far bigger problem for me than database interoperability. For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code. I have years more experience with Java than I do with Ruby, but I'm still 2 - 4x more productive using Rails than I am using Tapestry + Hibernate, and easily 10 - 20x more productive than I am when I'm forced to work on a Struts + JSP + JDBC project.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
For some developers, I can see how Java could be the best choice. Rails has definitely won me over though.
Of course the heavy lifting is done in a compiled language. In fact, that was pretty much my point. It's all about using the right tools for the job. If I was writing a database, I'd probably use C, but to use it for a standard web app would be the very definition of premature optimization in my eyes. Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Along similar lines, I have not tried complicated image or XML processing using pure Ruby, nor can I understand why anyone would want to. Ruby ships with a fast, native XML processor, and typing "gem install rmagick" is all it takes to get nice Ruby API for ImageMagick. The fact that these are native libraries is completely shielded from the developer, leaving the best of both worlds: Native performance, with Ruby productivity.
Most of these performance bottlenecks became solved problems a long time ago. When I interact with a Ruby On Rails application, I'm dealing with a native web server, a native database, native database drivers, native image processing code, probably a native XML parser, as well as the Ruby standard libraries, many of which are also written in C. At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre.NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages. Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
I've seen you bring this up before, but I still don't really follow. Rail can infer model details if you don't provide them yourself because, most of the time, it's the reasonable thing to do. Why should I have to tell it that the PRODUCTS table backs the Product model, or that a VARCHAR field holds data from a String property? The relationship is obvious, and Rails saves me the hassle of mapping it myself. These are simply default values however, and there's absolutely nothing preventing me from overriding them. If you choose to map everything (using something called a migration), Rails can even generate the schema for you against a variety of different types of databases.
There are ORM layers that go further with their abstractions than Rails, but I think Rails goes far enough. Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often, and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up. And, partly because rails really tries to enforce proper MVC design, and partly because Ruby is just such a damn productive language, making major changes to the way models work wouldn't be very difficult in most cases anyway.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
If you were a 20 year old kid with 2 cents to his name and an idea in his head, how exactly would you go about raising 20,000? Sure, it's possible. You could max out your (possibly non existent) credit cards and hope for the best. You could hit up rich uncle Joe and try to get a sliver of his fish packing fortune. If you have generous parents, maybe you could keep living in mom's basement, and spend the next 6 month of your life working on business plans, slogging through meetings, and dealing with folks who are far more interested in your age than your idea.
If you do manage to get the money, then what? Mine uncle Joe's fish packing knowledge to find out how to flip a software company? Tell Visa that you'll be able to make your minimum payment as soon as you can secure your second round of funding?
Some people would rather write software than deal with business crap, get in debt, or lose their family's money. For those folks, getting 20,000 for nothing more than an idea probably sounds pretty sweet. If things go south, they're no further behind than when they started, and if they get rich, who cares about a lousy 6% to avoid all that hassle? They're still rich.
Lastly, Google doesn't even know about Jimmy Nobody and his Fabulous Web-o-Matic. You can bet your ass they're looking at Y Combinator's kids though.
Have you actually tried Ruby? I mean, gave it an honest to goodness chance.. say a dozen or so hours of coding and perhaps the first few chapters of a good reference book? I just find it really hard to believe than anyone who actually knew Ruby's syntax would call it disqusting. It is, by a fairly wide margin, the nicest language I've ever used. Everything is incredibly easy and intuitive. If I don't know how to do something, I can usually guess it on my first or second try, and it makes it so easy to write reusable, modular code that it's stupid not to, even for what appears to be a throwaway program.
Ruby is hugely productive. Pretty much everything I've ever wanted to do requires less code, less configuration, and simply less hassle than in every other language I've used.
Now, this is mostly evident when compairing to more traditional statically typed languages like Java and C#, but Ruby's has plenty to offer folks who already use agile languages like Python or Lisp. Ruby has an easy to use and powerful package managment system, Gems. An excellent build tool, Rake. RDoc, a powerful JavaDoc like documentation system. Rails, which is probably the most productive web devleopment platform on the planet. Watir, a web scripting system that makes functional and system testing a breeze. MouseHole, a really slick scriptable proxy. Two extremely well written, freely available books: the first edition of Programming Ruby, and Why's Poignant Guide. An extremely helpful user community. The list goes on and on.
Maybe you should be asking yourself why you dislike Ruby so much, rather than why everyone else likes it. That's not to say that everyone should like it as much as I do, but I suspect you're missing something important.
Re:Proof of inflated reviews
on
Review: Dragonshard
·
· Score: 5, Insightful
Inflated reviews? Metacritic.com lists the average rating by the gaming media for this title as 82/100, which is pretty damn close to Zonk's 8/10. If this score is inflated, so are pretty much everyone else's.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
Rails lets you alias column names to provide some level of abstraction away from the database. Many people don't do this, as it's easier just to go with what's in the db, but renaming a column would only require one line of code to be added to object. It's also possible to perform some types of queries without any sql.
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
"It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own..."
The major bottleneck for most websites is the database. Pick up, well, pretty much ANY book about writing dynamic web sites, be it in PHP, Ruby, Java or whatever, and you'll likely find major sections dedicated to optimizing your db access code. Any help the language or framework can provide in this area directly leads to a faster, more scalable website.
Java has tonnes to offer here, nearly to the point of being ridiculous. With Hibernate (a popular Java data access framework), I don't have to write ANY data access code at all. All I have to do is provide a little extra meta information in my classes so it understands my relationships, give it a config file so it knows how to connect, and it takes care of almost all of the rest. It will even generate the database for you, if you want it to. For most tasks, it will do exactly the right thing without any extra work, yet still provides many ways to tweak the trouble areas.
PHP also makes it incredibly tempting to do the wrong thing. If I want to put a SQL query right in with my HTML template, it won't do anything at all to encourage me to do otherwise. In fact, in PHP this is the easiest place to put it... I suspect that many PHP programmers don't even realize that this is generally a very bad practice. Part of PHP's charm is that you don't have to learn complicated frameworks or patterns, which is just great for someone who wants to get off and running right away. However, without some sort of structure things can become an unmaintainable nightmare in no time at all.
"If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever. I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the at all."
Logic and presentation should be separated. It makes updating both easier, and it helps remove unnecessary dependencies between the two. The easiest thing to do in PHP however is to just stick them all in the same file. Contrast this to a Java framework like Tapestry, who's html component is simply a plain jane html file, with a single extra attribute added to the tags that Tapestry is interested in. This can be previewed in a standard web browser.. the entire look and feel of the site can be changed by someone who doesn't even know what Tapestry is. And, when I decide I want to switch from HTML to WML, or to a desktop application, all of my logic is cleanly separated, ready to be reused however I like.
It is of course possible to do this in PHP using Smarty templates or something similar, but the easiest approach is to just not think about it. For simple applications, this may never turn into a problem, but for anything moderately complicated the lack of separation can turn into a real issue.
Don't get me wrong.. I think PHP is great. It was the first web programming framework I really fell in love with, and I've seen some amazing things done with it. It's incredibly easy to pick up, and it will scale just about as far as you want to go with it.
However, writing sophisticated PHP applications requires just as much discipline as writing sophisticated Java applications, and I just find Java gives you so much more. Take a good java programmer, give them best of breed open source tools like Hibernate, Tapestry and Spring or Hivemind, and they're going to code circles around just about anyone else. Using these tools you can prototype an application incredibly quickly (faster in my experience than PHP, Perl, or anything else except for Rails), then evolve that application one piece at a time into a full, production ready enterprise app.
I have both Knights of the Old Republic and Doom 3 on a newer PC with an older (Geforce2) video card. Doom runs, KOTOR doesn't, so you might not be totally out of luck. Admittadly, I'm not really getting the full Doom 3 experience as I have many of cool effects turned off, but it's still very playable, unlike nearly every other new game I've tried.
Some would argue that, as a mostly visual game, crippling in this way defeats the point of playing it, but it's still very pretty even with shadowing and bump mapping turned off, and, despite being repetative, I've found it quite fun.
I'd suggest trying it before you shell out for a new system. You almost certainly need something newer to play Doom 3 in all it's glory, but it would likely look pretty good on what you have.
Err.. so what would you suggest? How is a company expected to fix problems in it's software without releasing a new version?
Real's made some serious mistakes in the past, but they seem to be making an honest effort to do the right thing now, or at least as much as they can without giving away all of their IP. Thanks to real, there's now a 100% open source video and audio streaming server and client, using Helix and OGG codecs. Real is also the only major streaming solution with Windows, Mac and Linux clients, and the only company that seems to be addressing the issue of interoperability in a DRM world. I can't say I'm a big fan of their solution, but at least they've raised the issue, which is more than you can say for MS or Apple. No DRM at all would be much better of course, but that just isn't an option for anyone who wants to sell music controlled by the RIAA.
Yes, much of this may be for Real's own selfish reasons, but the world, and especially the open source world, is still a better place with Real than it would be without them. They've given quite a lot.
Have you even used Real's offerings? If not, let's keep our opinions of quality to ourselves.
Apple's community is generally fiercely loyal. While apple's standards are usually high, they tend to be supported by their community even when they're not the best available option. Any attempt to create a competitor to iTunes Music Store on the mac will almost certainly be a failure unless they have something VERY special to offer, and given how similar the various music store offerings have been to date, this seems unlikely.
Back in college, my best friend had a fairly current Mac, while I used NT 4 on an older x86. He fancied himself a graphic artist, but 99% of the time he was doing more mundane stuff -- gaming, e-mail, IM and word processing. This was in the pre OSX days, back when Macs had no preemptive multitasking, and my system performed so much better for him that I frequently had to kick him off my PC so I could get some work done. He constantly bitched about the interface, but he still used it far more than his own computer.
NT clearly better suited his needs, so when he decided to get ANOTHER new computer (even though his was just over a year old), I assumed he'd be coming home with a PC. To my astonishment, he bought another Mac, because, as he said, he was an "Apple supporter". So, for the whole next year I had to fight to use my, by then downright ancient, PC.
I don't doubt that even then the Mac was far superior for some tasks, and the situation has greatly improved with OSX, but many Mac users still seem like they'd be perfectly content to follow Steve Jobs off a cliff. Until that changes it's going to be very difficult for any company to compete with Apple on the Mac, and nearly impossible an area like music sales, where it's challenging to differentiate yourself and Apple already dominates the market.
Want some beautiful Open Source games? Attract game artists with flexible and powerful open source tools that do something NEW -- not merely clones of packages they already have (*cough* The Gimp).
Err.. what sort of something new? When was the last time Adobe or Macromedia created something new?
The whole digital image manipulation market is very well established, and revolutionary advances occur very rarely. Gimp is full of neat little features that photoshop doesn't have, many of which undoubtedly are completely original ideas. However, it's impossible to compete in this market without producing a tool that is similar to photoshop in many respects, simply because, as the market evolved, that's where it went. Could you explain to me how an image manipulation program that wasn't like photoshop would even work?
I've found the Doom 3 engine scales down remarkably well. I'm currently playing it using a Geforce 2 MX. Will source actually run acceptably well on a lesser card than this?
I have shadows, specular lighting and bump mapping turned off, so the game doesn't look quite as good as it ought to, but it's still stunning to behold, and the framerates arn't too bad.
So what kind of hardware does source need?
So, I guess expecting the US to not act like an angry elementary school kid is asking too much?
Sure, Saddam was asking for it. But when a course of action is going to lead to thousands of deaths, that's not a good enough excuse.
A few years ago a Canadian politician called George Bush a moron. On the school yard, this would have been justification for a thorough ass kicking. By your logic I guess it would have been acceptable to attack Canada too?
The fact that you can change tapes on an older answering machine isn't really a feature, but more a side effect of the technology it was based on. When answering machines made the switch to digital they lost this ability, and nobody really complained. It simply isn't useful to the majority of folks.
So what IS useful to most folks? Why the ability to play games and take pictures. If I'm heading out to take some photographs, of course I'll be bringing the digital camera, and if I know I'll need to pass some serious time the gameboy will come out long before the cell phone. But what about when I'm unable to anticipate these things? Regularly I stumble unexpectedly across something that I'd love to be able to photograph to show my friends. Even more regularly I find myself with 20 or 30 minutes to kill -- a perfect opportunity to do a little gaming. So am I suppose do carry my digital camera and gameboy everywhere I go? What about my PDA and mp3 player? Not only is this awkward, but these are expensive devices that could be lost, stolen or broken. I'll take them if I know I'll be needing them, but carrying them all the time is both cumbersome and risky. I would MUCH rather have one small device that fits comfortably into my pocket and does all of these things, even if it doesn't do an amazingly good job of it.
It's unfortunate that your needs are different from most people's, and that current phones don't meet them very well, but this isn't the fault of convergence. Your needs are unique -- you can't expect a common mass marked device to fulfill an uncommon requirement.
Slashdot Mirror
Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.
Most people treat JavaScript like its C's retarded little brother, but that's just one of many programming styles that it adapts to. Methods like Array.each and Array.grep allow JavaScript to be used in a very Ruby-like fashion, which, in addition to making the language more comfortable for its target audience, usually results in tighter, more readable code. Extending Array and Object might lead to some exciting bugs in code that doesn't expect it, but I don't see how this makes the practice wholesale wrong. Ruby on Rails does stuff like this all over the place. Being able to say 3.months.ago or some_random_object.to_json is part of what makes Rails such a pleasure to work with, and I don't see why its JavaScript library shouldn't be extended the same freedoms.
To quickly address your other two issues, I got all the documentation I ever needed from this site, and, while unit tests are definitely nice, prototype's proven track record is enough for me. I haven't had the slightest bit of trouble with prototype -- it's done nothing but save me time thus far.
Well, perhaps this is a case where it's best to agree to disagree. Your comments are all valid and well presented, but my experiences have pointed me in a different direction.
Moving between databases hasn't been a big problem for me. Somewhat ironically, the only major issue of this type that I've had to deal with recently involved going from MySQL to Oracle in a Hibernate project, but this was more Oracle's fault than Hibernate's. We did have to resort to a few native queries to work around it however.
That issue aside though, I've found that changing business requirements and aggressive project schedules are a far bigger problem for me than database interoperability. For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code. I have years more experience with Java than I do with Ruby, but I'm still 2 - 4x more productive using Rails than I am using Tapestry + Hibernate, and easily 10 - 20x more productive than I am when I'm forced to work on a Struts + JSP + JDBC project.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
For some developers, I can see how Java could be the best choice. Rails has definitely won me over though.
Of course the heavy lifting is done in a compiled language. In fact, that was pretty much my point. It's all about using the right tools for the job. If I was writing a database, I'd probably use C, but to use it for a standard web app would be the very definition of premature optimization in my eyes. Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Along similar lines, I have not tried complicated image or XML processing using pure Ruby, nor can I understand why anyone would want to. Ruby ships with a fast, native XML processor, and typing "gem install rmagick" is all it takes to get nice Ruby API for ImageMagick. The fact that these are native libraries is completely shielded from the developer, leaving the best of both worlds: Native performance, with Ruby productivity.
Most of these performance bottlenecks became solved problems a long time ago. When I interact with a Ruby On Rails application, I'm dealing with a native web server, a native database, native database drivers, native image processing code, probably a native XML parser, as well as the Ruby standard libraries, many of which are also written in C. At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre .NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages. Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
I've seen you bring this up before, but I still don't really follow. Rail can infer model details if you don't provide them yourself because, most of the time, it's the reasonable thing to do. Why should I have to tell it that the PRODUCTS table backs the Product model, or that a VARCHAR field holds data from a String property? The relationship is obvious, and Rails saves me the hassle of mapping it myself. These are simply default values however, and there's absolutely nothing preventing me from overriding them. If you choose to map everything (using something called a migration), Rails can even generate the schema for you against a variety of different types of databases.
There are ORM layers that go further with their abstractions than Rails, but I think Rails goes far enough. Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often, and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up. And, partly because rails really tries to enforce proper MVC design, and partly because Ruby is just such a damn productive language, making major changes to the way models work wouldn't be very difficult in most cases anyway.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
If you were a 20 year old kid with 2 cents to his name and an idea in his head, how exactly would you go about raising 20,000? Sure, it's possible. You could max out your (possibly non existent) credit cards and hope for the best. You could hit up rich uncle Joe and try to get a sliver of his fish packing fortune. If you have generous parents, maybe you could keep living in mom's basement, and spend the next 6 month of your life working on business plans, slogging through meetings, and dealing with folks who are far more interested in your age than your idea.
If you do manage to get the money, then what? Mine uncle Joe's fish packing knowledge to find out how to flip a software company? Tell Visa that you'll be able to make your minimum payment as soon as you can secure your second round of funding?
Some people would rather write software than deal with business crap, get in debt, or lose their family's money. For those folks, getting 20,000 for nothing more than an idea probably sounds pretty sweet. If things go south, they're no further behind than when they started, and if they get rich, who cares about a lousy 6% to avoid all that hassle? They're still rich.
Lastly, Google doesn't even know about Jimmy Nobody and his Fabulous Web-o-Matic. You can bet your ass they're looking at Y Combinator's kids though.
Have you actually tried Ruby? I mean, gave it an honest to goodness chance.. say a dozen or so hours of coding and perhaps the first few chapters of a good reference book? I just find it really hard to believe than anyone who actually knew Ruby's syntax would call it disqusting. It is, by a fairly wide margin, the nicest language I've ever used. Everything is incredibly easy and intuitive. If I don't know how to do something, I can usually guess it on my first or second try, and it makes it so easy to write reusable, modular code that it's stupid not to, even for what appears to be a throwaway program.
Ruby is hugely productive. Pretty much everything I've ever wanted to do requires less code, less configuration, and simply less hassle than in every other language I've used.
Now, this is mostly evident when compairing to more traditional statically typed languages like Java and C#, but Ruby's has plenty to offer folks who already use agile languages like Python or Lisp. Ruby has an easy to use and powerful package managment system, Gems. An excellent build tool, Rake. RDoc, a powerful JavaDoc like documentation system. Rails, which is probably the most productive web devleopment platform on the planet. Watir, a web scripting system that makes functional and system testing a breeze. MouseHole, a really slick scriptable proxy. Two extremely well written, freely available books: the first edition of Programming Ruby, and Why's Poignant Guide. An extremely helpful user community. The list goes on and on.
Maybe you should be asking yourself why you dislike Ruby so much, rather than why everyone else likes it. That's not to say that everyone should like it as much as I do, but I suspect you're missing something important.
Inflated reviews? Metacritic.com lists the average rating by the gaming media for this title as 82/100, which is pretty damn close to Zonk's 8/10. If this score is inflated, so are pretty much everyone else's.
Most Eclipse contributors have been paid for doing so since day 1. This is hardly a new thing.
A testing framework for webapps that runs in the browser. It's both slick and simple.
http://selenium.thoughtworks.com/index.html
Rails lets you alias column names to provide some level of abstraction away from the database. Many people don't do this, as it's easier just to go with what's in the db, but renaming a column would only require one line of code to be added to object. It's also possible to perform some types of queries without any sql. Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
"It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own ..."
The major bottleneck for most websites is the database. Pick up, well, pretty much ANY book about writing dynamic web sites, be it in PHP, Ruby, Java or whatever, and you'll likely find major sections dedicated to optimizing your db access code. Any help the language or framework can provide in this area directly leads to a faster, more scalable website.
Java has tonnes to offer here, nearly to the point of being ridiculous. With Hibernate (a popular Java data access framework), I don't have to write ANY data access code at all. All I have to do is provide a little extra meta information in my classes so it understands my relationships, give it a config file so it knows how to connect, and it takes care of almost all of the rest. It will even generate the database for you, if you want it to. For most tasks, it will do exactly the right thing without any extra work, yet still provides many ways to tweak the trouble areas.
PHP also makes it incredibly tempting to do the wrong thing. If I want to put a SQL query right in with my HTML template, it won't do anything at all to encourage me to do otherwise. In fact, in PHP this is the easiest place to put it... I suspect that many PHP programmers don't even realize that this is generally a very bad practice. Part of PHP's charm is that you don't have to learn complicated frameworks or patterns, which is just great for someone who wants to get off and running right away. However, without some sort of structure things can become an unmaintainable nightmare in no time at all.
"If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever. I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the at all."
Logic and presentation should be separated. It makes updating both easier, and it helps remove unnecessary dependencies between the two. The easiest thing to do in PHP however is to just stick them all in the same file. Contrast this to a Java framework like Tapestry, who's html component is simply a plain jane html file, with a single extra attribute added to the tags that Tapestry is interested in. This can be previewed in a standard web browser.. the entire look and feel of the site can be changed by someone who doesn't even know what Tapestry is. And, when I decide I want to switch from HTML to WML, or to a desktop application, all of my logic is cleanly separated, ready to be reused however I like.
It is of course possible to do this in PHP using Smarty templates or something similar, but the easiest approach is to just not think about it. For simple applications, this may never turn into a problem, but for anything moderately complicated the lack of separation can turn into a real issue.
Don't get me wrong.. I think PHP is great. It was the first web programming framework I really fell in love with, and I've seen some amazing things done with it. It's incredibly easy to pick up, and it will scale just about as far as you want to go with it.
However, writing sophisticated PHP applications requires just as much discipline as writing sophisticated Java applications, and I just find Java gives you so much more. Take a good java programmer, give them best of breed open source tools like Hibernate, Tapestry and Spring or Hivemind, and they're going to code circles around just about anyone else. Using these tools you can prototype an application incredibly quickly (faster in my experience than PHP, Perl, or anything else except for Rails), then evolve that application one piece at a time into a full, production ready enterprise app.
Of course, n
IBM's JVM is based on Sun's. They may be able to contribute bits and pieces, but certainly not the whole thing.
I have both Knights of the Old Republic and Doom 3 on a newer PC with an older (Geforce2) video card. Doom runs, KOTOR doesn't, so you might not be totally out of luck. Admittadly, I'm not really getting the full Doom 3 experience as I have many of cool effects turned off, but it's still very playable, unlike nearly every other new game I've tried. Some would argue that, as a mostly visual game, crippling in this way defeats the point of playing it, but it's still very pretty even with shadowing and bump mapping turned off, and, despite being repetative, I've found it quite fun. I'd suggest trying it before you shell out for a new system. You almost certainly need something newer to play Doom 3 in all it's glory, but it would likely look pretty good on what you have.
Err.. so what would you suggest? How is a company expected to fix problems in it's software without releasing a new version? Real's made some serious mistakes in the past, but they seem to be making an honest effort to do the right thing now, or at least as much as they can without giving away all of their IP. Thanks to real, there's now a 100% open source video and audio streaming server and client, using Helix and OGG codecs. Real is also the only major streaming solution with Windows, Mac and Linux clients, and the only company that seems to be addressing the issue of interoperability in a DRM world. I can't say I'm a big fan of their solution, but at least they've raised the issue, which is more than you can say for MS or Apple. No DRM at all would be much better of course, but that just isn't an option for anyone who wants to sell music controlled by the RIAA. Yes, much of this may be for Real's own selfish reasons, but the world, and especially the open source world, is still a better place with Real than it would be without them. They've given quite a lot.
Have you even used Real's offerings? If not, let's keep our opinions of quality to ourselves.
Apple's community is generally fiercely loyal. While apple's standards are usually high, they tend to be supported by their community even when they're not the best available option. Any attempt to create a competitor to iTunes Music Store on the mac will almost certainly be a failure unless they have something VERY special to offer, and given how similar the various music store offerings have been to date, this seems unlikely.
Back in college, my best friend had a fairly current Mac, while I used NT 4 on an older x86. He fancied himself a graphic artist, but 99% of the time he was doing more mundane stuff -- gaming, e-mail, IM and word processing. This was in the pre OSX days, back when Macs had no preemptive multitasking, and my system performed so much better for him that I frequently had to kick him off my PC so I could get some work done. He constantly bitched about the interface, but he still used it far more than his own computer.
NT clearly better suited his needs, so when he decided to get ANOTHER new computer (even though his was just over a year old), I assumed he'd be coming home with a PC. To my astonishment, he bought another Mac, because, as he said, he was an "Apple supporter". So, for the whole next year I had to fight to use my, by then downright ancient, PC.
I don't doubt that even then the Mac was far superior for some tasks, and the situation has greatly improved with OSX, but many Mac users still seem like they'd be perfectly content to follow Steve Jobs off a cliff. Until that changes it's going to be very difficult for any company to compete with Apple on the Mac, and nearly impossible an area like music sales, where it's challenging to differentiate yourself and Apple already dominates the market.
Want some beautiful Open Source games? Attract game artists with flexible and powerful open source tools that do something NEW -- not merely clones of packages they already have (*cough* The Gimp).
Err.. what sort of something new? When was the last time Adobe or Macromedia created something new?
The whole digital image manipulation market is very well established, and revolutionary advances occur very rarely. Gimp is full of neat little features that photoshop doesn't have, many of which undoubtedly are completely original ideas. However, it's impossible to compete in this market without producing a tool that is similar to photoshop in many respects, simply because, as the market evolved, that's where it went. Could you explain to me how an image manipulation program that wasn't like photoshop would even work?
I've found the Doom 3 engine scales down remarkably well. I'm currently playing it using a Geforce 2 MX. Will source actually run acceptably well on a lesser card than this? I have shadows, specular lighting and bump mapping turned off, so the game doesn't look quite as good as it ought to, but it's still stunning to behold, and the framerates arn't too bad. So what kind of hardware does source need?
So, I guess expecting the US to not act like an angry elementary school kid is asking too much?
Sure, Saddam was asking for it. But when a course of action is going to lead to thousands of deaths, that's not a good enough excuse.
A few years ago a Canadian politician called George Bush a moron. On the school yard, this would have been justification for a thorough ass kicking. By your logic I guess it would have been acceptable to attack Canada too?
The fact that you can change tapes on an older answering machine isn't really a feature, but more a side effect of the technology it was based on. When answering machines made the switch to digital they lost this ability, and nobody really complained. It simply isn't useful to the majority of folks.
So what IS useful to most folks? Why the ability to play games and take pictures. If I'm heading out to take some photographs, of course I'll be bringing the digital camera, and if I know I'll need to pass some serious time the gameboy will come out long before the cell phone. But what about when I'm unable to anticipate these things? Regularly I stumble unexpectedly across something that I'd love to be able to photograph to show my friends. Even more regularly I find myself with 20 or 30 minutes to kill -- a perfect opportunity to do a little gaming. So am I suppose do carry my digital camera and gameboy everywhere I go? What about my PDA and mp3 player? Not only is this awkward, but these are expensive devices that could be lost, stolen or broken. I'll take them if I know I'll be needing them, but carrying them all the time is both cumbersome and risky. I would MUCH rather have one small device that fits comfortably into my pocket and does all of these things, even if it doesn't do an amazingly good job of it.
It's unfortunate that your needs are different from most people's, and that current phones don't meet them very well, but this isn't the fault of convergence. Your needs are unique -- you can't expect a common mass marked device to fulfill an uncommon requirement.