Apple is dominating the market, and it's not because they have vendor-lock-in with the iTunes music store. I mean, in order to get locked in, they first need to sell you an iPod or an iTMS song.
Since you're pretty unlikely to buy one without the other, I don't think Apple cares all that much. On Slashdot, people love to say music sharing doesn't cut into music sales. I'd love to see if that is true.
I think it'd be interesting if Apple stopped DRMing their 128bit AAC files and only DRM'd their high quality Apple Lossless files, taking a page from radio. A lossy transmission is great for listening, but people who want the media for arhchival and distribution get licenses.
I'm not saying DRM is okay, but it'd be interesting to see what happens to iTMS sales.
I really don't see this at all, as those languages are virtually identical to the C-based counterparts. Groovy is about as different from Ruby as Ruby is to Python - there is nothing fundamentally alien about it because it is hosted on JVM.
That's the problem. It's too different from Java. You're right about the execution environment not mattering.
Personally, I don't care! Providing I can mix and match classes from different languages cleanly, I welcome the chance to use new languages in this way. I guess I have always believed that IT knowledge always goes out of date, and the only thing that counts is general experience and a willingness to learn.
Many of us have this dream, but it's a very progressive dream and there are a lot of people out there who wouldn't like to see it. It makes me want to help out with Parrot, but I don't have the time.
As for Real/Napster, how about anyone else who wants to run a music store that sells DRM'd music to play on as many audio devices as possible?
Too bad for them. Offer a better product, and it'll sell.
Strawman arguments are not that convincing. Boo! Real suck! Therefore no-one should be allowed to use Fairplay to sell DRM music for iPods!
I wasn't trying to imply that Real or Napster were the only ones hurt. I was implying that Napster and Real are companies that are trying to get Congress involved or otherwise have a slice of the pie that they themselves couldn't bake.
And where did we go from "We don't know exactly what's going on between Apple and the RIAA. It's very hard to say." to "the RIAA won't let people sell music that plays on an iPod", which seemed to happen in the course of your post?
The RIAA will not let people sell unencoded MP3s or AACs, both of which are industry standard formats that play on the iPod. If you want to sell un-DRM'd music for the iPod, and you can pull it off, you'll make huge piles of money. But you can't do it if you want to sell music the RIAA controls.
That's how we got there. Is everyone forgetting the iPod plays a lot more than just FairPlay AAC?
Next, you'll be complaining that iTunes should interface with everyone's music store, because otherwise iTMS gets an unfair advantage with iPod users. That also doesn't work.
Apple came up with a good piece of hardware, a good sales model, and a good piece of software to tie the two together. Nothing about it is or should be illegal. Nothing coerces you to buy an iPod, except your natural desire to buy the best product. Nothing forces you to use the iTunes Music Store even if you do own an iPod.
Do they have a choice? We don't know exactly what's going on between Apple and the RIAA. It's very hard to say.
But let's assume they can. Why should they? As long as the RIAA is requiring them to use DRM, why should they open it up? Who's clamoring for this to change? Real, for example? Ahh, let me play my Violin for Real. They've been holding out on their video format for years. Suddenly someone comes along and begins to make some real money selling media and media peripherals. And suddenly, it's unfair. Ahh, the tables have turned.
Or maybe we should talk about Napster? Oh yeah, Napster 2.0, friendlier, fluffier, totally under the RIAA's thumb. Their music subscription system is even more restrictive than Apple's!
Look, as long as the RIAA is on this DRM kick, the consumer is screwed. No amount of licensing, patenting, or copyrighting is going to change this simple fact. Apple's at least given us DRM terms that aren't completely awful, and if other companies don't like that, too bad. If you buy iTMS music then switch players, too bad. Welcome to Capitalism, population: everyone trying to make money.
Companies do this kind of stuff all the time, and it only seems to be "bad" when someone succeeds. But Apple's succeeding so wildly that you have to ask why we're upset! People obviously like the way things are, or they wouldn't be buying all these iPods and music. If it's legal, and people like it, then screw the competition. You can censure Apple because the RIAA won't let people sell music that plays on an iPod.
I think this is exaggerating - it is a minor matter, perhaps?
No. Not having it sucks. Just because I can abuse a feature doesn't mean I will. If it's so bad, why is Sun using it on its string class? The answer to "why" is obvious, because it made the class easier to use. But, I am prevented from making that decision.
It would make no difference to the compiler's complexity to add operator overloading because, obviously, it's allready there in some capacity.
This simplicity means that compilers are simple and implementations can be simple.
The java compiler and runtime are not simple. They incorporate some of the best JIT stuff in the commerical landscape. There are better things out there, but they aren't as well known or used.
Java was not designed to be concise or elegant, it was designed to be small and very clear for readers and compilers to understand.
Funny, where I come from concise, elegant code is easy to read. But that's just us Python and Ruby folks being quirky, I guess. I mean, sure, Python is called Executable Pseudocode and Ruby has been referred to as a "joy" to read.
But hey, I'll admit maybe some people like typing 20 characters just so that they can write a string to the screen, and maybe there are people who like having to fake anoymous functions with an interface and class to get nice internal iteration or pleasantly abstract code. Obviously, I am not one of them. I've seen the light, or the dark, or the other side, or whatever.
Interestingly, there is a new Java technology that will allow operator overloading, closures etc. It is called Groovy, and is now a JCP JSR. This is a dynamic scripting language that can seamlessly use existing Java classes and can in turn be compiled to classes for use by pure Java. Groovy classes can freely mixed with Java classes in any application. This will allow the flexibility that many of us would like, but in a clearly defined and delimited area.
I've played with Groovy, it's an interesting project. Someone over there is starting to get what we love about dynamic and functional languages, and they're trying to introduce it to Java users. However, it shares the same weakness as JRuby or Jython. It's too alien, and there are many people out there who, having spent years mastering Java, feel extremely threatened when someone suggests their hard-earned knowledge may not always be applicable.
No one can burn UMDs but Sony. They have locked the professional game market in a way similar to the old days of Nintendo, where you just couldn't copy the media without undue (and potentially illegal) effort.
But Sony explicitly has the ability to play games from memory sticks. Why would they do that? It is an obvious hole for Sony to allow people to make games and utilities for the PSP, but forever relegate these utilities to a small subset of the market.
From a marketing and image standpoint, this is a stroke of genius. In order to be a real contender, you have to go through Sony like all the big kids. But the device can benefit from "underground" development work without a threat to Sony's normal sales model, for people willing to spend more money and time on the device.
Also, they'll sell more Memory Stick Duo media. How else are you going to hold these fancy games? And if you want to hold a fancy memory stick game and one of these movies they plan to use to push the PSP as a video iPod? Well, pony up for the media.
Sony has everything to gain by encouraging indie developers, and their control of the UMD media means they have little to lose.
By the way, this is heresay, but I've heard the hardware calls to read a memory stick and the calls to read a UMD are different. This means that Sony realized that game piracy might be a threat, and so they further protected their interests. If you could buy a game, use a utility to image it, then distribute it and play it on memory stick, Sony would have a real problem.
I'm not sure. There are plenty of classes which have behaviour which syntactically would look better with operators, but most developers seem to manager without : java.math.* etc.
I think operator overloading got a bum rap. Many developers, myself included, saw people abusing it and said that the horror outweighed the benefit. Now, without it, the landscape is pretty bleak.
Also, Sun saw fit to use it, but we cannot. This says something about Sun's attitude, I think.
As for the library, there is nothing to stop developers writing their own!
The only reason anyone would do this is to open source it. There is no reasion for a company to do it, unless they have VERY long term plans for Java.
Further, they'd need to be willing to hack the runtime some. What if they want to add a new class with String-like functionality? In order to get operator overloading, which Sun seems to think they needed to make the Java Standard Library, you'd have to do that.
I'll agree that Java's syntax was both it's reason for success and its greatest flaw, though.
I won't argue this point much further, since it's certainly subjective and also varies wildly depending on when you tried to use Java for this purpose.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I don't want to poke a hornets nest, so please keep in mind I work with Java nearly every day, and the other language I get paid to work with is C++ (which I also dislike, somewhat). Here are some examples:
Java is very verbose. Some argue that this is for improved readability, and some feel that this is a hollow argument.
Java is statically typed in a lexical fashion, a-la C++ and C. While there are reflection featues, they are not as strong as the features in a language like Python.
There are a great many design flaws in Java's standard library. For example, InputStream and OutputStream do not have a common root or delegate, so any code written that is applicable to both input AND output must be either abstracted into another class or duplicated.
Some people feel Java's new template system is unacceptable because it does not provide Liskov-like substitution.
These are just a few examples of what I was really getting at.
Many people, myself included, have made GUI apps with Java. And everyone goes in-full of optimism-and says, "This will be easy! Java makes it so that we can deploy on multiple platforms!"
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability. A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I've also developed apps for multiple platforms using Qt, and I have to say that the Qt experience in C++ and the Java experience were, all in all, about equal. Which is to say better than it would have been 10 years ago, but not painless by any stretch of the imagination.
Yeah, Java got a bum rap early on for speed. But people quickly showed that in many of Java's preferred domains, I/O latency was by far the primary reason for speed issues.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue, but a lot of people got angry because their sluggish machines couldn't handle it. This continues even today. A common comment about Eclipse, for example, is that it's a terrific IDE so long as you have a very fast machine.
These days, when you hear educated people complain about Java, it's not usually because of the speed issues anymore. It's usually language issues (Java needs that, Java shouldn't have this, etc.). The validity of these complains depends entirely on your viewpoint.
Basically, the UNIX-based stuff has been secure against cache poisoning for quite some time, but there may always be a bug or design flaw that is discovered. We are not quite sure why Microsoft left a default configuration to be unsecure in NT4 and 2000. (Exercise to reader: insert Microsoft security comment/opinion/joke here, but keep it to yourself).
The worst part about DNS cache poisoning is that it affects DNS nodes underneath it in the hierarchy. So if you're below a Windows DNS that gets attacked, you yourself may be subject even if your local DNS is in fact secure.
Oh, and fear caching http proxy servers that touch DNS servers that get poisoned. They can keep the bad data around for a long time.
Paradox, I don't remember getting much arguments, I do remember getting much flames and trolls.
This may be part of your problem.
I only react to posts that attack me directly, like the one that started the thread, don't pull things out of context again.
Do you actually think this matters at all? If I got angry every time someone on Slashdot insulted me, Anonymous Coward or no, I'd have a stroke within 24 hours.
Grow a thicker skin and let your work rest on its technical merit. To do anything else is a disservice to your hard work.
You just can't stop complaining about this, can you? Didn't you get enough arguments with Rails users last time?
Let me try and set the record straight, without being an overzealous fan.
Oh, and btw, Ta-da Lists's template line count was not taken into account into the 600 lines, so stop whining.
I'm not sure anyone has told you that a lot of stuff that was included in Ta-da's linecount was done so only because of an ideal of fairness. Caching, for instance, is used for the first time in Ta-da List (and is prepared for extraction). So it goes into the linecount.
I'd rather call Ta-da optimized for Rails since you have your List Act which does all the list handling automatically in the framework.
Same with the table-as-list stuff. Ta-da extraction. Extra DB handling. Not too bad, but still. I know I wouldn't have line-counted it, since it was being put in the framework that very version.
Personally, I wouldn't have included these things. They were extracted into the framework.
You guys continue to amaze me, so you write an even more simple to-do list with Rails that does some Ajax eye-candy and only does account management and list editing.
Ooof. Why on earth the AC mentioned that app, I have no idea. taskTHIS! is an Ajax tech demo. It's not meant to be something competiting with Ta-da or Bla-bla. Please discard this comparison.
I'm still not that sure I should have since the features it gives you are completely impossible to do with Rails.
Not to belabor any points, but no one argues that Rails does more than RIFE. Most certainly, RIFE can probably out-feature Rails on many different levels. Even when Rails hits 1.0, this will still probably be the case.
What many Rails fans (and I think the AC above, in typicall trollish AC fashion) are trying to point out is that the end-all-be-all of a framework is not the result of terminal featuritis. Rails is great for small-to-medium kinds of project. Most of us are aware of this. When Rails is applicable, it's incredibly applicable.
When it's not, we still have RIFE. Rest assured that if Rails ever hits its limits for me, RIFE will be the first place I look (despite your obnoxious behavior, recently). Now, many of the Rails community (including myself) dislike Java strongly. But that doesn't mean we don't know it and aren't prepared to use it if we must.
So I for one thank you, Geert. You showed me an alternative. No stop being such a dick about it. If you're trying to say that DHH behaved innapropriately when he compared Bla-Bla to Ta-da, your point is not well-served by throwing a tantrum every time Rails gets some positive press. Take the moral high ground.
Rails comes with this. Indeed, it's preferred for many situations. The template method is best when you're not working with web designers who don't know any programming language and want to make mockups.
It's called XML::Builder, and it's pretty neat. Check it out at this link.
Okay, there is CRUD and then there are CRUD-screens.
Rails automates CRUD class generation. This is a popular and useful pattern. Rails has an outstanding implementation of this. It does have a few performance weaknesses, but they don't seem to inhibt many applications.
Rails also has a CRUD-screen generator set called "scaffolding". Scaffolding isn't really meant for production use. It's a nice way to force the app to get started. You then add things as you go, overiding the generated pages with real pages. It's unfortunate that many demos use scaffolding, because its really a very tiny part of Rails development.
The Rails framework does indeed auto-generate some other things. But they're extrmely generic.
Subway will have to discover what is the natural "Python" way for doing what Rails does (which is a great example of the "Ruby Way"). This may or may not be as beautiful and pleasnt as the Ruby way.
Grandparent of this post. Look what I said. Python needs to find the Python way to do it. This way may or may not be more elegant than the Ruby way. Yes, elegance exists as a meta-language property, it's not tied to any one language.
No, disagreeing with that doesn't help Python's case very much.
A user proposed a patch to disable the unsafe way, since he, and many others didn't even realize that way was unsafe. David refused that patch because it might inconvenience people who were using the insecure way, but protecting themselves manually.
Umm, closing off arbitrary SQL statements would be an incredibly bad idea. ActiveRecord is great, but it is not the Alpha and Omega of all things you could want to do. It's not developer convienience we're talking about here. If you removed that feature there would be some things you just couldn't do.
This isn't about discarding security, it's standard practice. Unchecked SQL queries are unsafe. They're unsafe because they're the final level of the database layer. If you don't know this, you're at a novice level of web programming and shouldn't be using that feature anyways.
Maybe one day ActiveRecord will be so good that you'd never want to use that feature, but that's not now. Sorry.
But you're holding an unreasonable standard with, here. Keep that in mind.
You're right, you can do things different ways to emulate what Ruby is doing naturally. But, then you begin to lose the beautiful meta-language-syntax that makes ActiveRecord and ActionPack so attractive.
Python is a great language, and is very powerful. But it lacks true lambdas and closures (yes, you get baby-lambdas, and no, they aren't enough). It also lacks the powerful meta-programming features that Ruby has. Of course, Python has other strengths, but they're not topical here.
Subway will have to discover what is the natural "Python" way for doing what Rails does (which is a great example of the "Ruby Way"). This may or may not be as beautiful and pleasnt as the Ruby way.
This doesn't condemn Subway or Python. It remains to be seen what they can do. So far, I don't think many people have been impressed so far, but we're all waiting to see what happens.
However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).
This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.
If you want to try ruby with code completion, check out FreeRIDE. It is not done yet, but it'll show you the direction things are going.
Rails sucks because its written in ruby, which is slow (excruciatingly slow for recursion and text processing), and doesn't support OS level threads. The fake threads ruby does have can under uncertain circumstances cause the entire interpreter to block.
Get off it. Ruby is not "excruciatingly slow" for anything. It is surely not as fast as some languages, but its speed is obviously good enough, because even without caching the Rails app is faster than the Java app.
I mean, if caching was the only thing holding Rails afloat, you could draw this conclusion, but even a cursory examination of TFA wills show that's just not true.
Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem if you haven't read the rails code thoroughly to understand what its doing underneath. Convenience trumps security in rails development.
Making secure actions in Rails is trivially easy. There is even a generator for it. Rails developers are concerned with security, but they've yet to see a scenario where the standard login generators and practices of the rails community require a technical fix.
Yes, you could bring up Geert's posts point out flaws in Ta-da Lists, but that'd be silly. Every application can have bugs, and Ta-da Lists was ripped wholesale out of Basecamp, reseated, and used mainly as an Ajax demo and advertisement for basecamp.
Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then". Then the new version has different bugs instead. Continue this cycle until you decide to use mysql or stop using rails.
This is no longer true. It was true at one point. Yes, many features go into Edge Rails that are MySQL only, but that's just because the developers tend to know it best. Features don't end up in the mainline unless they're as compatible as people can make them. I cannot deny that some databases are not as well supported as others, though.
That's all I've got, any other problems I've seen are personal preference issues, or things that can easily be fixed as rails matures.
I think you formed your opinions before the 0.10.0 release. We're closing in on Rails 1.0 now, and things are starting to get really stable.
You can use parts of Ruby On Rails, usually the ActiveRecord component, to do app dev with Ruby. Ruby does have FX, GTK and even Qt bindings if you so desire to use them.
However, much of Rails's work revolves around web work, and so besides ActiveRecord, there isn't much else you can use.
Ruby is a viable choice for building applications, though. Rails is just one expression of this.
Slashdot Mirror
Apple is dominating the market, and it's not because they have vendor-lock-in with the iTunes music store. I mean, in order to get locked in, they first need to sell you an iPod or an iTMS song.
Since you're pretty unlikely to buy one without the other, I don't think Apple cares all that much. On Slashdot, people love to say music sharing doesn't cut into music sales. I'd love to see if that is true.
I think it'd be interesting if Apple stopped DRMing their 128bit AAC files and only DRM'd their high quality Apple Lossless files, taking a page from radio. A lossy transmission is great for listening, but people who want the media for arhchival and distribution get licenses.
I'm not saying DRM is okay, but it'd be interesting to see what happens to iTMS sales.
That's the problem. It's too different from Java. You're right about the execution environment not mattering.
Many of us have this dream, but it's a very progressive dream and there are a lot of people out there who wouldn't like to see it. It makes me want to help out with Parrot, but I don't have the time.
Next, you'll be complaining that iTunes should interface with everyone's music store, because otherwise iTMS gets an unfair advantage with iPod users. That also doesn't work.
Apple came up with a good piece of hardware, a good sales model, and a good piece of software to tie the two together. Nothing about it is or should be illegal. Nothing coerces you to buy an iPod, except your natural desire to buy the best product. Nothing forces you to use the iTunes Music Store even if you do own an iPod.
Here's a question for you.
Do they have a choice? We don't know exactly what's going on between Apple and the RIAA. It's very hard to say.
But let's assume they can. Why should they? As long as the RIAA is requiring them to use DRM, why should they open it up? Who's clamoring for this to change? Real, for example? Ahh, let me play my Violin for Real. They've been holding out on their video format for years. Suddenly someone comes along and begins to make some real money selling media and media peripherals. And suddenly, it's unfair. Ahh, the tables have turned.
Or maybe we should talk about Napster? Oh yeah, Napster 2.0, friendlier, fluffier, totally under the RIAA's thumb. Their music subscription system is even more restrictive than Apple's!
Look, as long as the RIAA is on this DRM kick, the consumer is screwed. No amount of licensing, patenting, or copyrighting is going to change this simple fact. Apple's at least given us DRM terms that aren't completely awful, and if other companies don't like that, too bad. If you buy iTMS music then switch players, too bad. Welcome to Capitalism, population: everyone trying to make money.
Companies do this kind of stuff all the time, and it only seems to be "bad" when someone succeeds. But Apple's succeeding so wildly that you have to ask why we're upset! People obviously like the way things are, or they wouldn't be buying all these iPods and music. If it's legal, and people like it, then screw the competition. You can censure Apple because the RIAA won't let people sell music that plays on an iPod.
It would make no difference to the compiler's complexity to add operator overloading because, obviously, it's allready there in some capacity.
The java compiler and runtime are not simple. They incorporate some of the best JIT stuff in the commerical landscape. There are better things out there, but they aren't as well known or used. Funny, where I come from concise, elegant code is easy to read. But that's just us Python and Ruby folks being quirky, I guess. I mean, sure, Python is called Executable Pseudocode and Ruby has been referred to as a "joy" to read.But hey, I'll admit maybe some people like typing 20 characters just so that they can write a string to the screen, and maybe there are people who like having to fake anoymous functions with an interface and class to get nice internal iteration or pleasantly abstract code. Obviously, I am not one of them. I've seen the light, or the dark, or the other side, or whatever.
I've played with Groovy, it's an interesting project. Someone over there is starting to get what we love about dynamic and functional languages, and they're trying to introduce it to Java users. However, it shares the same weakness as JRuby or Jython. It's too alien, and there are many people out there who, having spent years mastering Java, feel extremely threatened when someone suggests their hard-earned knowledge may not always be applicable.You think Apple wants to deal with all this DRM shit? They know it's bogus. We know it's bogus.
Have Congress the the RIAA that we actually get our fair use rights, and that they have to adapt or die to a changing enconomy.
If Congress did this, Apple would pull their DRM scheme in heartbeats, I garuntee it. They gain nothing except the Record Industry's approval with it.
No one can burn UMDs but Sony. They have locked the professional game market in a way similar to the old days of Nintendo, where you just couldn't copy the media without undue (and potentially illegal) effort.
But Sony explicitly has the ability to play games from memory sticks. Why would they do that? It is an obvious hole for Sony to allow people to make games and utilities for the PSP, but forever relegate these utilities to a small subset of the market.
From a marketing and image standpoint, this is a stroke of genius. In order to be a real contender, you have to go through Sony like all the big kids. But the device can benefit from "underground" development work without a threat to Sony's normal sales model, for people willing to spend more money and time on the device.
Also, they'll sell more Memory Stick Duo media. How else are you going to hold these fancy games? And if you want to hold a fancy memory stick game and one of these movies they plan to use to push the PSP as a video iPod? Well, pony up for the media.
Sony has everything to gain by encouraging indie developers, and their control of the UMD media means they have little to lose.
By the way, this is heresay, but I've heard the hardware calls to read a memory stick and the calls to read a UMD are different. This means that Sony realized that game piracy might be a threat, and so they further protected their interests. If you could buy a game, use a utility to image it, then distribute it and play it on memory stick, Sony would have a real problem.
I think operator overloading got a bum rap. Many developers, myself included, saw people abusing it and said that the horror outweighed the benefit. Now, without it, the landscape is pretty bleak.
Also, Sun saw fit to use it, but we cannot. This says something about Sun's attitude, I think.
The only reason anyone would do this is to open source it. There is no reasion for a company to do it, unless they have VERY long term plans for Java.
Further, they'd need to be willing to hack the runtime some. What if they want to add a new class with String-like functionality? In order to get operator overloading, which Sun seems to think they needed to make the Java Standard Library, you'd have to do that.
I'll agree that Java's syntax was both it's reason for success and its greatest flaw, though.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I don't want to poke a hornets nest, so please keep in mind I work with Java nearly every day, and the other language I get paid to work with is C++ (which I also dislike, somewhat). Here are some examples:
These are just a few examples of what I was really getting at.
Many people, myself included, have made GUI apps with Java. And everyone goes in-full of optimism-and says, "This will be easy! Java makes it so that we can deploy on multiple platforms!"
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability. A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I've also developed apps for multiple platforms using Qt, and I have to say that the Qt experience in C++ and the Java experience were, all in all, about equal. Which is to say better than it would have been 10 years ago, but not painless by any stretch of the imagination.
Yeah, Java got a bum rap early on for speed. But people quickly showed that in many of Java's preferred domains, I/O latency was by far the primary reason for speed issues.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue, but a lot of people got angry because their sluggish machines couldn't handle it. This continues even today. A common comment about Eclipse, for example, is that it's a terrific IDE so long as you have a very fast machine.
These days, when you hear educated people complain about Java, it's not usually because of the speed issues anymore. It's usually language issues (Java needs that, Java shouldn't have this, etc.). The validity of these complains depends entirely on your viewpoint.
From TFA:
The worst part about DNS cache poisoning is that it affects DNS nodes underneath it in the hierarchy. So if you're below a Windows DNS that gets attacked, you yourself may be subject even if your local DNS is in fact secure.
Oh, and fear caching http proxy servers that touch DNS servers that get poisoned. They can keep the bad data around for a long time.
Grow a thicker skin and let your work rest on its technical merit. To do anything else is a disservice to your hard work.
Personally, I wouldn't have included these things. They were extracted into the framework.
Ooof. Why on earth the AC mentioned that app, I have no idea. taskTHIS! is an Ajax tech demo. It's not meant to be something competiting with Ta-da or Bla-bla. Please discard this comparison. Not to belabor any points, but no one argues that Rails does more than RIFE. Most certainly, RIFE can probably out-feature Rails on many different levels. Even when Rails hits 1.0, this will still probably be the case.What many Rails fans (and I think the AC above, in typicall trollish AC fashion) are trying to point out is that the end-all-be-all of a framework is not the result of terminal featuritis. Rails is great for small-to-medium kinds of project. Most of us are aware of this. When Rails is applicable, it's incredibly applicable.
When it's not, we still have RIFE. Rest assured that if Rails ever hits its limits for me, RIFE will be the first place I look (despite your obnoxious behavior, recently). Now, many of the Rails community (including myself) dislike Java strongly. But that doesn't mean we don't know it and aren't prepared to use it if we must.
So I for one thank you, Geert. You showed me an alternative. No stop being such a dick about it. If you're trying to say that DHH behaved innapropriately when he compared Bla-Bla to Ta-da, your point is not well-served by throwing a tantrum every time Rails gets some positive press. Take the moral high ground.
Rails comes with this. Indeed, it's preferred for many situations. The template method is best when you're not working with web designers who don't know any programming language and want to make mockups.
It's called XML::Builder, and it's pretty neat. Check it out at this link.
It's nice for generating "Semantic Web" markup.
Okay, there is CRUD and then there are CRUD-screens.
Rails automates CRUD class generation. This is a popular and useful pattern. Rails has an outstanding implementation of this. It does have a few performance weaknesses, but they don't seem to inhibt many applications.
Rails also has a CRUD-screen generator set called "scaffolding". Scaffolding isn't really meant for production use. It's a nice way to force the app to get started. You then add things as you go, overiding the generated pages with real pages. It's unfortunate that many demos use scaffolding, because its really a very tiny part of Rails development.
The Rails framework does indeed auto-generate some other things. But they're extrmely generic.
Grandparent of this post. Look what I said. Python needs to find the Python way to do it. This way may or may not be more elegant than the Ruby way. Yes, elegance exists as a meta-language property, it's not tied to any one language.
No, disagreeing with that doesn't help Python's case very much.
Now stop trolling and go about your day.
Uhh, hi. Reread what I said.
I said to do exactly what you're saying they should do. Step away from your defensive attitude for a second.
It may just be that, some languges are better at expressing certain patterns. This is not a bad thing.
Umm, closing off arbitrary SQL statements would be an incredibly bad idea. ActiveRecord is great, but it is not the Alpha and Omega of all things you could want to do. It's not developer convienience we're talking about here. If you removed that feature there would be some things you just couldn't do.
This isn't about discarding security, it's standard practice. Unchecked SQL queries are unsafe. They're unsafe because they're the final level of the database layer. If you don't know this, you're at a novice level of web programming and shouldn't be using that feature anyways.
Maybe one day ActiveRecord will be so good that you'd never want to use that feature, but that's not now. Sorry.
But you're holding an unreasonable standard with, here. Keep that in mind.
Code completion via IRB is in the works. It's just a very hard problem.
As for why not GTK? Compatibility with Windows, Linux and OS X.
You're right, you can do things different ways to emulate what Ruby is doing naturally. But, then you begin to lose the beautiful meta-language-syntax that makes ActiveRecord and ActionPack so attractive.
Python is a great language, and is very powerful. But it lacks true lambdas and closures (yes, you get baby-lambdas, and no, they aren't enough). It also lacks the powerful meta-programming features that Ruby has. Of course, Python has other strengths, but they're not topical here.
Subway will have to discover what is the natural "Python" way for doing what Rails does (which is a great example of the "Ruby Way"). This may or may not be as beautiful and pleasnt as the Ruby way.
This doesn't condemn Subway or Python. It remains to be seen what they can do. So far, I don't think many people have been impressed so far, but we're all waiting to see what happens.
Ruby does not have a canonical IDE, unlike Java.
However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).
This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.
If you want to try ruby with code completion, check out FreeRIDE. It is not done yet, but it'll show you the direction things are going.
I mean, if caching was the only thing holding Rails afloat, you could draw this conclusion, but even a cursory examination of TFA wills show that's just not true.
Making secure actions in Rails is trivially easy. There is even a generator for it. Rails developers are concerned with security, but they've yet to see a scenario where the standard login generators and practices of the rails community require a technical fix.Yes, you could bring up Geert's posts point out flaws in Ta-da Lists, but that'd be silly. Every application can have bugs, and Ta-da Lists was ripped wholesale out of Basecamp, reseated, and used mainly as an Ajax demo and advertisement for basecamp.
This is no longer true. It was true at one point. Yes, many features go into Edge Rails that are MySQL only, but that's just because the developers tend to know it best. Features don't end up in the mainline unless they're as compatible as people can make them. I cannot deny that some databases are not as well supported as others, though. I think you formed your opinions before the 0.10.0 release. We're closing in on Rails 1.0 now, and things are starting to get really stable.You can use parts of Ruby On Rails, usually the ActiveRecord component, to do app dev with Ruby. Ruby does have FX, GTK and even Qt bindings if you so desire to use them.
However, much of Rails's work revolves around web work, and so besides ActiveRecord, there isn't much else you can use.
Ruby is a viable choice for building applications, though. Rails is just one expression of this.