csn wrote:

Let's bash PHP now--not following MVC is particularly egregious. Sure there are frameworks, but I'd bet most PHP code out there is spaghetti. Following Rails database conventions is much easier in comparison. And you can do far more with procs in Ruby than limited languages like pl/sql and variants, and much more easily than with C.

PHP (and Perl, and C, and even Ruby) are programming languages. Software architecture (like MVC) is the responsibility of the programmer writing the application. If you're lucky, there's a library-cum-framework already written for the language that will encapsulate such things provided they're well-written and you use it right.

Comparing PHP and Rails is like comparing bauxite and aluminium.

    Sxooter wrote:

    The last time I tried to use PDO it wasn't reliable for pgsql, but that was a couple of years ago...

    PDO as a whole was still experimental back then (and PostgreSQL itself was still only 8.0 - hence no "RETURNING" clause - I haven't got the relevant source files to see whether PDO uses it. Of course, that's not to say you can't just write the clause in the query); I think PostgreSQL-related work has concentrated primarily on PDO since, and the procedural interface has been left ticking over.

      Weedpacket wrote:

      PHP (and Perl, and C, and even Ruby) are programming languages. Software architecture (like MVC) is the responsibility of the programmer writing the application. If you're lucky, there's a library-cum-framework already written for the language that will encapsulate such things provided they're well-written and you use it right.

      Comparing PHP and Rails is like comparing bauxite and aluminium.

      Yup, I agree--apples and oranges.

      But saying MVC is the responsibility of the programmer writing the app is a stretch. Why reinvent the wheel AGAIN and spend lots of time doing so? And most programmers probably aren't up to the task of writing their own MVC framework, and one that's better than existing ones no less. I'd bet most devs choose to use MS's MVC framework for Windows rather than write their own from scratch.

        Sxooter wrote:

        Just to flesh out the thing about RI in app versus in DB.

        The reason RI in the app is a bad idea is that it leaves you open to failures of a transaction.

        If your app crashes halfway through a transaction, your database is now in an inconsitent state. Suppose the typical transaction is something like this:

        begin transaction
        look up user account info
        check user account for x dollars
        create user billing notice
        debit user account x dollars
        credit master account x dollars
        commit transaction.

        If your app or database crashes halfway through this and you are using your db to do RI and handle the transaction, the transaction will roll back 100%. no money missing anywhere. If you're using an application to handle transactions and RI and either the db or the app layer crash in the middle, you've got an inconsistent state. If you're handling 100,000 transactions an hour, you might have dozens of accounts that are now out of whack, and no way to be sure which to roll back and which to commit.

        Things get even more interesting when you've got multiple servers doing this. Suppose you have a corporate customer where several users debit from the same account. The account has $500 in it, and two users try to debit it for $400 each. Each transaction hits a different app server. Again, if the db is handling the transaction and RI, then one transaction will automatically wait for the other to finish (assuming you used select for update like you should) and the second transaction will fail, like it should.

        If it's in the app layer, two app servers are likely to both debit the account $400, and worse yet, if they do it by grabbing the balance and decrementing it in memory, then they'll both set the balance to $100 when they're done.

        Last job I had we had an app on a DGUX machine that used vsam tables that made these mistakes all day, everyday. It was a full time job to fix the data destruction it left in its wake. We probably had 10 to 20 bad transactions a day on that machine.

        And if you DO get the locking and RI right in the app layer, it's more costly than in the DB layer, because you've got to move more data around to doublecheck every step to make sure you're getting it right each time.

        For community sites, etc... app layer RI and transactions may result in the occasional race condition that means a post gets lost or something. In a transactional system, it might mean that you give away a free ticket for every 100th you sell. Or you double book the same seats, or who knows what.

        The strength of the database is referential integrity and transactional integrity. A well designed db will be fast and reliable for such things. An app will always have more work to do to accomplish this, and will have to use much more severe db and app layer locking to accomplish the same thing.

        Good point, and I don't know. I guess Rails stores transactions in its tmp and hopefully recovers when it restarts. I'll have to put it on my investigate TODO. I would be surprised if Rails transactions could be so flawed and that nobody had thought of this scenario.

          csn wrote:

          Good point, and I don't know. I guess Rails stores transactions in its tmp and hopefully recovers when it restarts. I'll have to put it on my investigate TODO. I would be surprised if Rails transactions could be so flawed and that nobody had thought of this scenario.

          Being the skeptic, I would not be so surprised. πŸ˜ƒ

            csn wrote:

            Yup, I agree--apples and oranges.

            But saying MVC is the responsibility of the programmer writing the app is a stretch. Why reinvent the wheel AGAIN and spend lots of time doing so? And most programmers probably aren't up to the task of writing their own MVC framework, and one that's better than existing ones no less. I'd bet most devs choose to use MS's MVC framework for Windows rather than write their own from scratch.

            Well, I guess I'm an old-school programmer who reckons programmers should be capable of programming.

            "Yup, I agree--apples and oranges. "
            No, not quite. I did think the analogy through instead of just trotting out the clichΓ©. Apples and oranges would be a category error. Which is what I was pointing out that comparing PHP to Rails was. An appropriate comparison would be between PHP and Ruby, or between Rails and Zend Framework. Or Rails and Symfony. Or Django and Symfony. Or CGI.pm and Django. Or Perl and Python.

            "Why reinvent the wheel AGAIN and spend lots of time doing so?"
            So why do new frameworks keep being developed?

            "programmers probably aren't up to the task of writing their own MVC framework"
            I get the feeling that there are quite a few "programmers" who wouldn't know programming if it sat on their collective face and wriggled. Obviously, if you have a clear, well-defined, well-understood, and well-established requirement for which a solution already exists, you use that solution. That's where frameworks come in. Me, I'm using one right now (because it was in use when I arrived), but I have to keep reminding myself to stop mentally re-engineering the thing and just use it like I have no idea what's going on under the bonnet. (Oh, there are some egregious design flaws in this thing. Detailing them would identify it, so I won't.)

            So I guess you can make a comparison between "Ruby on Rails" and "traditional PHP"; the latter asks more of you as a programmer.

            Besides, it's not like you need to build an entire framework when you're writing an application. You write the application. If you already know how to write it then that's most of the work already done.

            "One that's better than existing ones no less"?
            That kind of depends on whether a given specific application needs an all-singing-all-dancing-one-size-fits-all (except when it doesn't have something you need) framework. ASP.NET, for example, strikes me as massive overkill for 99.5% of web sites and I'd only be inclined use it in a situation where everything else in the organisation in question is already done the Microsoft Way. (That's something else I've noticed: pick a framework and all development processes morph into practices geared towards the care and feeding of the framework and its way of doing things.)

            Why no "one that's as fancy as necessary but no more"?

            Still, all that will happen is that the frameworks will get more elaborate and complex and configurable and easy-to-stuff-up and so development kits will be written to make developing in <insert framework of your choice here> easier and simpler, and then those development kits will become more configurable and more programmable and spawn their own hooks and become frameworks and the whole process will begin again with yet another layer of abstraction designed to isolate the programmer from the computer.

              Weedpacket wrote:

              So I guess you can make a comparison between "Ruby on Rails" and "traditional PHP"; the latter asks more of you as a programmer.

              No, the latter asks you to experience more pain. πŸ˜›

                Banks have lots of systems that aren't transactional.

                I'm willing to bet good money that anything that is touched by ruby either isn't transactional, or if it is, the transactions are ensured by the database, not by ruby.

                I think you keep misunderstanding me.

                Ruby is a good scripting language. RoR is a nice framework. RoR encourages handling transactions in code. That's bad.

                Banks, airlines, suppliers, etc... might use RoR (we use it for our configuration management in production) but they don't let it handle the transactions, and for damned good reasons. transaction semantics in code are error prone, don't scale, and aren't tough enough to survive small problems like a server crashing halfware through.

                When you go to Bank of America and log into to transfer funds, do you really think they're doing the transaction in the web front end you're looking at? Seriously, no way they'd do that.

                  I'm not misunderstanding you! ;P

                  I've got a question for you. Let's say two devs choose two different scenarios:

                  • Dev 1 develops Enterprisey App 1.0 and puts RI and transactions in the database. He requires 12 database servers.

                  • Dev 2 develops Enterprisey App 1.0 as well, but puts RI and transactions in the app. He requires 12 app servers (and one database server I guess).

                  Don't the database servers need to talk to each other as much as the app servers would? How is it that the database servers can supposedly scale so much better? I gotta plead ignorance here--I have no idea how 12 database servers would be set up. 1 master and 11 slaves? Or do they all somehow make one big virtual database (maybe even using something like Xen?)?

                    the network effect will swamp the app tier before it swamps the db tier.

                    OR the app tier will cheat and not implement ACID transactions.

                    Fast, cheap, reliable. You can have two. With app tier you get fast and cheap, with the database you get fast and reliable. OR even cheap and reliable.

                    There are lots of well written papers on this on the web and I'm not going to try and re-write them. My experience tells me that app layer transactions are a disaster waiting to happen.

                    P.s. the fact that you've thrown example after example of non-transactional systems tells me you HAVE misunderstood what I meant all along. Not that there's anything wrong with that.

                      Sxooter wrote:

                      the network effect will swamp the app tier before it swamps the db tier.

                      The network effect?

                      Sxooter wrote:

                      P.s. the fact that you've thrown example after example of non-transactional systems tells me you HAVE misunderstood what I meant all along.

                      Not at all! I just asked you how you could tell if a system used transactions without looking at their code or the devs tell you. I suspect more than bank and airline systems use transactional systems. πŸ˜›

                        csn wrote:

                        The network effect?

                        In the database the amount of data to exchange to between backends, and the paths they follow are faster compared to an app tier handling transactions. Especially if that app tier is trying to guarantee real ACID compliance, not just hand waving their way around it.

                        Not at all! I just asked you how you could tell if a system used transactions without looking at their code or the devs tell you. I suspect more than bank and airline systems use transactional systems. πŸ˜›

                        Well, it's all just hand waving until someone steps up and says that they're handling transactions handling MONEY with app layer RoR transactions. I'm quite sure that if someone is doing RoR / transactions in the app tier with no RI in the db, we'll hear all about it.

                          Sxooter wrote:

                          Ruby is a good scripting language. RoR is a nice framework. RoR encourages handling transactions in code. That's bad.

                          I think there are a few misconceptions with your understanding of Rails.

                          1. Rails does not handle transactions in code, it uses database transaction support. Rails offers an abstraction to the actual SQL being executed, but the transaction is still taken care of in the database.

                            Example: The following code...

                            
                            
                            Account.transaction(david, mary) do
                                david.withdrawal(100)
                                mary.deposit(100)
                            end
                            

                            executes the following SQL...

                            
                            
                            BEGIN
                            SQL to remove 100 from david
                            SQL to add 100 to mary
                            COMMIT
                            
                          2. Rails does not force developers to keep referential integrity out of the database. Rails offers the ability the put validations and such in code, but there is no reason that one MUST put them there and not in the database.

                          Saying that these types of database features are not possible is Rails is ridiculous. Rails abstracts SQL in most cases, but if there is any SQL that you want to execute you can do so easily, just like you would in PHP.

                          If these concerns with the database are your only problems with Rails, then I think you need to seriously take a closer look and gain a better understand of how Rails actually works.

                            rulian wrote:

                            From what I can tell so far, Rails is basically a very general Pre-Assembled package for web applications, or in a sense, a small short cut to programming, or even a way to develop for people who dont konw how to develop.

                            Not read through the whole thread but I just noticed this... funnily enough its "php developers" that I've noticed don't know how to develop. Hence the quotes because I've met allot of people that claim to be but they really don't know what they are doing.

                            I'm talking about the person that Google's for something similar, hacks at it until it eventually (kinda) works.

                            I'm actually trying to decide on a new language to learn this summer and I have been thinking about RoR, however I'm not sure yet.

                              dougal85 wrote:

                              I'm actually trying to decide on a new language to learn this summer and I have been thinking about RoR, however I'm not sure yet.

                              Just remember that the language is called Ruby, and that Rails (RoR) is just a web development framework implemented in it (anyone would think that's all Ruby is used for).

                              If you're looking for a new language to learn, why not one that's a bit different? Like Haskell? Or Mercury? Or XSLT? Or Lisp? Get a look at programming from a different perspective.

                                dougal85 wrote:

                                I'm actually trying to decide on a new language to learn this summer and I have been thinking about RoR, however I'm not sure yet.

                                If you're going to learn a new language, you might as well go for something that will help you get a job (as a fellow UK resident and web developer, I would heavily advise this). Why not look at ASP or ASP.NET? There are quite a few jobs going with these technologies, people over here (as I guess anywhere) are still not quite trusting PHP just yet

                                  Weedpacket wrote:

                                  Just remember that the language is called Ruby

                                  Very true, I say RoR because I would only be learning it from the web perspective. If regular Ruby can be used for web development that I guess I've missed something!

                                  Has anybody tried Grails? aka Groovy on Rails - changed the name because the RoR people where not happy. One of my lecturers loves it and pushes it about as hard as he can.

                                  piersk wrote:

                                  Why not look at ASP or ASP.NET?

                                  I think that's what I think I'm going to do to be honest. I am tempted to sign up to http://www.learnvisualstudio.net/ - $70 a year... what's that Β£35-Β£40... that's nothing. I'm not sure how good they really are mind you but the example video's look quite good. I have some (limited) experience with C# too, so I just need to get more familiar with the framework.

                                    dougal85 wrote:

                                    Very true, I say RoR because I would only be learning it from the web perspective. If regular Ruby can be used for web development that I guess I've missed something!

                                    Well, unless RoR relies on something other than Ruby to do what it does, then a bit of logical thought leads to the conclusion that "regular" Ruby can be used for web development. Proof is by construction: first, implement Ruby on Rails in Ruby....