I am not digging through the mailing list archives that have no search to find it for you. I am not confused, however if you would like to believe I am than that is fine. I am not asking you not to use rails, I am saying some of us refuse to use it because the attitude of the main developer is that convenience trumps security, and we feel that attitude is harmful.
I am not talking about whatever tutorial thing that guy was. I didn't hear about that. I am also not talking about bypassing the framework for the 3rd time, please take the time to read before you jump to defend someone else's baby that you want to live vicariously through.
I am talking about a few months ago when I looked into using rails, there was a mailing list discussion I came across where passing args to a rails function could be done in two ways. One way protected you from SQL injection, the other did not. 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. This is the exact same attitude that prevents me from using microsoft products. I don't care who is writing the software, if they consider convenience more important than security, I will not use it.
Seaside. That is the list. Nothing else makes the list because they all (rails included) look sad and pathetic in comparison. I do not care for python, so I can't really comment on the quality of various python frameworks except to say that I hated zope (not really a framework, I know).
You don't need to alter objects at run-time to make a rails like framework. That's a rediculous way to try to make ruby seem special. The question is "can problem X be solved by language Y?" and your answer is "no, you would have to do it differently". There's nothing wrong with doing it differently, it still solves the problem. Just because you don't like the perl or python way of doing something, does mean they are wrong and ruby is right. Different strokes for different folks.
But showing how uninformed you are with the lisp flamebait, and the lies about not being able to use python for templating really adds to your credibility, nice touch.
You kinda have to try them all and see if you like them, which can be quite annoying when sparse documentation makes trying things take longer than it should. I don't actually care for python though, so I'm not the best person to ask.
Um. Tell me, how can you not read, but can reply? I specifically said the SQL that rails makes. Rails does not make any guarentees about safety, and you can pass arguments unsafely. A patch was proposed to fix this, and David refused it because people who somehow guessed to use the function safely would be inconvienced by changing the semantics of the function to protect people who didn't have the psychic abilities to use the function safely.
If I have a "stock" PHP and I want the gd libraries, I don't do either of your nonsensical choices. I compile the PHP gd module, uncomment the php.ini line that loads the PHP gd module, and reload apache. You don't need to compile everything into PHP you know, and in fact its pretty dumb to do so.
Not trying to defend PHP for a large project or anything, I'm not crazy. But you shouldn't challenge people to tests you don't understand.
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.
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.
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.
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.
There's a big difference between "you can put identical copies of your rails app on many servers and it works if everything is normal" and a real distributed app. What happens to the users in the middle of doing something on one server when it goes down? And rails caching is per server, which is a complete waste and starts to look really stupid when you have a big app running on a few dozen machines.
The rails guy is constantly pushing rails at every opportunity, and is smart enough to start lots of java flamewars to get even more attention. Once you start like that, you end up with other people getting excited and pushing it at every opportunity too. Before you know it, every other story on slashdot is about rails.
Nobody has really made any serious attempts to push seaside, or any of the python frameworks, so obviously they are less well known. That's ok though, you don't have to use rails just because its the latest fad.
Rails is not special or impressive. The only people who seem to like it are people who were using huge bloated java stacks. Try comparing rails to something good like seaside and then see how much it "rocks".
Tomcat is certainly not known for performance, well, not known for it in a positive way anyhow. How about doing the same benchmarks using resin or a commercial java server instead of tomcat?
This is why I gave up on rails. The developers take the attitude of "its your problem, you make sure its secure". No, that's wrong. You are making a web development framework, then YOU make it secure. If you don't read the rails code and find out how things are implimented underneath, then you don't know if your own code is vulnerable to SQL injection or not. That's rediculous, all the rails automatic SQL generation should be safe, you shouldn't expect every user to guess which is the safe way to use rails and which is the unsafe way. And when David dismissed a patch to fix an issue like this "because that would inconvenience people who are using the potentially insecure method securely", I knew he had no business writing software for the web.
I have tried python. Whitespace didn't prevent me from trying it, it seemed fine at first. Then when I did something larger, I realized what a problem it actually is, and stopped using python.
What I am saying is that removing curly braces does not add any benefit, the language is not any more clear or concise. But there are problems with removing the curly braces. So if you add up the fact that there is no benefit, but there are downsides, that means its a problem. If you don't mind dealing with the problem that's up to you, but trying to pretend its not a problem by claiming "its just like what you should be doing anyways, only kinda a pain in the ass in certain situations" isn't going to solve the problem.
if a > b:
if a > c: # indented with 4 spaces
print "python forces me to use stupid editor settings" # indented with 8 spaces
print "I am less productive in python as a result" # indented by a tab
If your editor's indentation level is 4, then this is how the code looks. But the second print is always executed when the first one is, despite not looking that way. And you can always do bizarre ass indentation where every level is a different width. I realize you shouldn't code this way, and obviously I don't *intentionally* code this way. But there is more to programming than simply writing a piece of code the first time, many other people read it and edit it afterwards, and cause weird errors like this if they don't worship at the alter of python editor settings, or when they try to move a block of code to a different place, where the indentation is different, and have to try to fix it, and can very easily make a mistake. This is completely avoided by simply using curly braces, and any inconsistancies in indentation can quickly be fixed by running indent on the code.
So, clearly removing the curly braces does NOT force the code to be indented clearly, instead it just forces me to use editor settings I dislike, have a hard time working with other people, and makes it a huge pain to move blocks of code since I now have to manually re-indent a whole crapload of code. Even if you don't think these downsides are a big deal, the fact is they are downsides, and there is no upside.
Just because there's the possibilty of improved performance someday, that doesn't mean you can't compare what exists now. This is what exists, this is what people are trying to claim is so much better than python, this is what gets compared. If ruby increases in performance in the future then that's great, but right now it is a potential issue. Also, pike isn't as old as python either, and has fewer developers and a much smaller community, but its faster than python.
Yes, having to enforce someone elses coding standard that we don't like on ourselves is the entire problem. Languages with syntax allow us all to program as we please, then re-indent to the standard *we* choose for our project. That's the entire point.
Try writing some unit tests? No, try not having to test things that should be dealt with by the language. That's the entire point being made. Statically typed languages find these bugs immediately, and you don't have to waste time testing if your variables are what you think they are, its already guarenteed for you. Just because you don't mind wasting your time, doesn't mean everyone feels the same way. Some people like having computers deal with boring crap for them.
When people say "I don't like language X because it has these 2 problems", you stating those same problems again doesn't counter it and make things all good. If you like python go ahead and use it, but stop expecting everyone to put up with pythons problems just because you don't mind having to deal with them. Python loses points for having these problems, but it doesn't having anything on the other side giving it points that I've seen. I don't find python offers any benefits over perl, ruby or pike, but it definately has a couple downsides. So, we're going to switch to one of those other languages that doesn't go out of its way to try to make things difficult for us.
You are saying that indentation is good. Ok, so go ahead and indent. That doesn't explain why curly braces have to be removed. What else people want is the ability to have the clear, consise and useful curly braces that they have come to love. Instead of trying to dismiss the valid concerns about whitespace, how about trying to explain what benefit it provides? Saying "its just like what you are already used to" is a cop-out, that's not a benefit. And "it forces you to indent correctly" isn't even correct, as you can clearly have lines that look identically indented, but aren't actually being interpreted that way by python due to a mix of spaces and tabs. At some point you will have to accept the fact that you cannot convince people to give up something they like and find useful, in exchange for nothing. Provide some valid reasons why significant whitespace is good. If they best you can do is "its not that bad really, you'll get used to it", then its clearly a bad thing, not a feature.
While I am not sure I would go so far as to say ruby is "incredibly" slow, it is definately quite a bit slower than python. Check out http://shootout.alioth.debian.org/. There's a very big difference in speed for things like object creation, method calls, etc. Core language functionality that can't be made into a C module. And of course, python still lets you make C modules too, its still nice to have your normal code execute faster though.
Slashdot Mirror
I am not digging through the mailing list archives that have no search to find it for you. I am not confused, however if you would like to believe I am than that is fine. I am not asking you not to use rails, I am saying some of us refuse to use it because the attitude of the main developer is that convenience trumps security, and we feel that attitude is harmful.
I am not talking about whatever tutorial thing that guy was. I didn't hear about that. I am also not talking about bypassing the framework for the 3rd time, please take the time to read before you jump to defend someone else's baby that you want to live vicariously through.
I am talking about a few months ago when I looked into using rails, there was a mailing list discussion I came across where passing args to a rails function could be done in two ways. One way protected you from SQL injection, the other did not. 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. This is the exact same attitude that prevents me from using microsoft products. I don't care who is writing the software, if they consider convenience more important than security, I will not use it.
Seaside. That is the list. Nothing else makes the list because they all (rails included) look sad and pathetic in comparison. I do not care for python, so I can't really comment on the quality of various python frameworks except to say that I hated zope (not really a framework, I know).
You don't need to alter objects at run-time to make a rails like framework. That's a rediculous way to try to make ruby seem special. The question is "can problem X be solved by language Y?" and your answer is "no, you would have to do it differently". There's nothing wrong with doing it differently, it still solves the problem. Just because you don't like the perl or python way of doing something, does mean they are wrong and ruby is right. Different strokes for different folks.
But showing how uninformed you are with the lisp flamebait, and the lies about not being able to use python for templating really adds to your credibility, nice touch.
You kinda have to try them all and see if you like them, which can be quite annoying when sparse documentation makes trying things take longer than it should. I don't actually care for python though, so I'm not the best person to ask.
Um. Tell me, how can you not read, but can reply? I specifically said the SQL that rails makes. Rails does not make any guarentees about safety, and you can pass arguments unsafely. A patch was proposed to fix this, and David refused it because people who somehow guessed to use the function safely would be inconvienced by changing the semantics of the function to protect people who didn't have the psychic abilities to use the function safely.
If I have a "stock" PHP and I want the gd libraries, I don't do either of your nonsensical choices. I compile the PHP gd module, uncomment the php.ini line that loads the PHP gd module, and reload apache. You don't need to compile everything into PHP you know, and in fact its pretty dumb to do so. Not trying to defend PHP for a large project or anything, I'm not crazy. But you shouldn't challenge people to tests you don't understand.
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.
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.
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.
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.
There are already similar or even better (seaside) frameworks in other languages, including both python and perl. Rails is well marketed, that's all.
There's a big difference between "you can put identical copies of your rails app on many servers and it works if everything is normal" and a real distributed app. What happens to the users in the middle of doing something on one server when it goes down? And rails caching is per server, which is a complete waste and starts to look really stupid when you have a big app running on a few dozen machines.
The rails guy is constantly pushing rails at every opportunity, and is smart enough to start lots of java flamewars to get even more attention. Once you start like that, you end up with other people getting excited and pushing it at every opportunity too. Before you know it, every other story on slashdot is about rails.
Nobody has really made any serious attempts to push seaside, or any of the python frameworks, so obviously they are less well known. That's ok though, you don't have to use rails just because its the latest fad.
Rails is not special or impressive. The only people who seem to like it are people who were using huge bloated java stacks. Try comparing rails to something good like seaside and then see how much it "rocks".
Tomcat is certainly not known for performance, well, not known for it in a positive way anyhow. How about doing the same benchmarks using resin or a commercial java server instead of tomcat?
Its an internal server error.
This is why I gave up on rails. The developers take the attitude of "its your problem, you make sure its secure". No, that's wrong. You are making a web development framework, then YOU make it secure. If you don't read the rails code and find out how things are implimented underneath, then you don't know if your own code is vulnerable to SQL injection or not. That's rediculous, all the rails automatic SQL generation should be safe, you shouldn't expect every user to guess which is the safe way to use rails and which is the unsafe way. And when David dismissed a patch to fix an issue like this "because that would inconvenience people who are using the potentially insecure method securely", I knew he had no business writing software for the web.
I have tried python. Whitespace didn't prevent me from trying it, it seemed fine at first. Then when I did something larger, I realized what a problem it actually is, and stopped using python.
What I am saying is that removing curly braces does not add any benefit, the language is not any more clear or concise. But there are problems with removing the curly braces. So if you add up the fact that there is no benefit, but there are downsides, that means its a problem. If you don't mind dealing with the problem that's up to you, but trying to pretend its not a problem by claiming "its just like what you should be doing anyways, only kinda a pain in the ass in certain situations" isn't going to solve the problem.
if a > b:
if a > c: # indented with 4 spaces
print "python forces me to use stupid editor settings" # indented with 8 spaces
print "I am less productive in python as a result" # indented by a tab
If your editor's indentation level is 4, then this is how the code looks. But the second print is always executed when the first one is, despite not looking that way. And you can always do bizarre ass indentation where every level is a different width. I realize you shouldn't code this way, and obviously I don't *intentionally* code this way. But there is more to programming than simply writing a piece of code the first time, many other people read it and edit it afterwards, and cause weird errors like this if they don't worship at the alter of python editor settings, or when they try to move a block of code to a different place, where the indentation is different, and have to try to fix it, and can very easily make a mistake. This is completely avoided by simply using curly braces, and any inconsistancies in indentation can quickly be fixed by running indent on the code.
So, clearly removing the curly braces does NOT force the code to be indented clearly, instead it just forces me to use editor settings I dislike, have a hard time working with other people, and makes it a huge pain to move blocks of code since I now have to manually re-indent a whole crapload of code. Even if you don't think these downsides are a big deal, the fact is they are downsides, and there is no upside.
Just because there's the possibilty of improved performance someday, that doesn't mean you can't compare what exists now. This is what exists, this is what people are trying to claim is so much better than python, this is what gets compared. If ruby increases in performance in the future then that's great, but right now it is a potential issue. Also, pike isn't as old as python either, and has fewer developers and a much smaller community, but its faster than python.
Yes, having to enforce someone elses coding standard that we don't like on ourselves is the entire problem. Languages with syntax allow us all to program as we please, then re-indent to the standard *we* choose for our project. That's the entire point.
Try writing some unit tests? No, try not having to test things that should be dealt with by the language. That's the entire point being made. Statically typed languages find these bugs immediately, and you don't have to waste time testing if your variables are what you think they are, its already guarenteed for you. Just because you don't mind wasting your time, doesn't mean everyone feels the same way. Some people like having computers deal with boring crap for them.
When people say "I don't like language X because it has these 2 problems", you stating those same problems again doesn't counter it and make things all good. If you like python go ahead and use it, but stop expecting everyone to put up with pythons problems just because you don't mind having to deal with them. Python loses points for having these problems, but it doesn't having anything on the other side giving it points that I've seen. I don't find python offers any benefits over perl, ruby or pike, but it definately has a couple downsides. So, we're going to switch to one of those other languages that doesn't go out of its way to try to make things difficult for us.
You are saying that indentation is good. Ok, so go ahead and indent. That doesn't explain why curly braces have to be removed. What else people want is the ability to have the clear, consise and useful curly braces that they have come to love. Instead of trying to dismiss the valid concerns about whitespace, how about trying to explain what benefit it provides? Saying "its just like what you are already used to" is a cop-out, that's not a benefit. And "it forces you to indent correctly" isn't even correct, as you can clearly have lines that look identically indented, but aren't actually being interpreted that way by python due to a mix of spaces and tabs. At some point you will have to accept the fact that you cannot convince people to give up something they like and find useful, in exchange for nothing. Provide some valid reasons why significant whitespace is good. If they best you can do is "its not that bad really, you'll get used to it", then its clearly a bad thing, not a feature.
While I am not sure I would go so far as to say ruby is "incredibly" slow, it is definately quite a bit slower than python. Check out http://shootout.alioth.debian.org/. There's a very big difference in speed for things like object creation, method calls, etc. Core language functionality that can't be made into a C module. And of course, python still lets you make C modules too, its still nice to have your normal code execute faster though.