This is why we use libraries, frameworks, and higher-level languages, and why Ruby on Rails is better suited for many web apps than PHP, which was my original point.
My point wasn't that you should use C instead of PHP. It was that PHP isn't the be-all-end-all of web development. Ruby on Rails has a lot of selling points other than "look what I can build that can be built with anything else".
However...
You can "hook into the webserver" pretty easily with CGI programs written in C. That's how they did it (along with Perl) before PHP and every other web framework.
http://en.wikipedia.org/wiki/Common_Gateway_Interface
String manipulation isn't much more cumbersome in C than any other language. Just use a library if you can't figure it out for yourself.
http://bstring.sourceforge.net/
If you need high-availability disaster-recovery, or simply distributed databases, you can use GUIDs for surrogate keys instead of auto-incrementing integers. You lose a bit on the integer-is-faster-than-varchar argument, but a single varchar column is still better than a natural key (which might be subject to change, requiring cascading updates for foreign keys) and especially better than a composite natural key (which effectively requires de-normalization for foreign keys.. which you might do anyway to avoid JOINs for performance reasons).
It depends. There have been cases (such as Twitter) where Rails apps have run into problems at high load. However, there are always solutions. Twitter's problem wasn't caused by Rails, it was caused by how they were using Rails. Their bottleneck was actually in the database, and Rails doesn't support multiple databases. Within 2 or 3 days of the issue becoming public a plugin was released.
The nice thing about Rails and Ruby is that they are flexible. The dynamic nature of Ruby makes it easy to extend, and Rails benefits greatly from that.
But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in C. Just because most people don't, doesn't mean it's a bad tool. If you need a tool to hold your hand and force you to adhere to best practices, then you aren't a very good developer.
I think database developers could learn a thing or two about Rails.
"all facts for a single entity in one table" Just break the entity up into composite parts that map to separate tables/model classes, each of which "belongs to" to the master object. There are other ways to do it too, if you want to write some code.
"using one-to-one links ("universal IDs")" I don't know what you're talking about. I don't think these are industry terms. If you're referring to "surrogate keys", there are perfectly valid reasons to do so, and perfectly valid reasons to use them instead of natural keys.
"queries that fetch all attributes at once, and save all at once" You can easily fetch only the attributes that you need. Model.find(:all,:select => 'a,b,c') will only select columns a, b, and c. Yes, all of the attributes are saved at once, but how often do you only want to save some of the attributes? It doesn't cost much to update unchanged columns -- it's probably cheaper (total guess, but makes sense) to just update them all rather than figure out which ones have changed.
"minimal use of joins" Sure, if you don't know how to use them. Rails makes eager fetching easy with the:include option in finders, which is implemented as a left outer join. You can write your own joins if necessary.
"implementing complex queries in procedural code" This is not an issue if someone understands encapsulation. It's up to the developer to do it right -- Rails doesn't do it wrong.
I think he means that if only the actual stick were broken, it would be nice to have the option to press a button to pause the game and plug in a new joystick. A lot of Atari joysticks have bad sticks, but the buttons still work.
Not that your trolling deserves a response, but gaming is a pretty common use of PCs, and considering that this thread is in the Gaming section, it seems a relevant question.
Writing C++ and having the OS talk directly to the processor is partly to blame for instable systems. Low-level access requires high-level knowledge -- one byte out of place and someone's mechanical lung stops working.
Operating systems 20 years ago used much less memory than they do today. That doesn't mean that modern OS's aren't as good, just as having a virtual machine isn't necessarily bad. The concept of abstraction layers is a good one, even though they usually have a cost. Like anything else, the cost has to be weighed against other factors (efficiency being one, but also portability, security, time-to-market, and robustness).
Embedded systems may be an exception in a lot of cases. However, there is embedded Java (J2ME), and resources are relatively cheap (and getting cheaper). It's probably often cheaper to use Java and a bit more hardware than designing against a proprietary system to skimp on the hardware costs. Economies of scale, and all that.
Isn't an OS just a kind of runtime environment? After all, it's just one level of abstraction among many levels of abstraction. A Java Virtual Machine is just one more level of abstraction.
2GB may be more space than YOU need at this point in time, but I doubt that you can speak for everyone for the forseeable future.
Google, Yahoo, Microsoft, etc, don't simply allocate 2GB on some hard drive on some computer for each user. That would be the most inefficient and least cost-effective solution that is possible (other than, say, delegating one server per user). It is much more likely that their implementation does not tie your email account to any one particular hard drive, or even one particular server. The contents of each message might be on any computer that happens to have the hard drive space, and I can guarantee that each hard drive is backed up, mirrored, and otherwise made redundant. They keep track of how much hard drive space you are using, and simply prevent you from using more than 2GB.
One could also argue that exposure to OSS, even on a closed OS, is a good thing. Especially when said closed OS has a virtually ubiquitous market share.
Hibernate has an option to turn output/log the SQL statements that it generates. You can also run a profiler on your database (SQL Server's SQL Profiler is nice) to capture everything that happens.
Mappings of every common data type are built into Hibernate, and you can write custom user types for anything weird. I'm not aware of any problems. In fact, Hibernate will figure out what data type a column is by using reflection on the POJO. If column "LASTNAME" is mapped to "lastName", and "getLastName()" returns a String, it's smart enough to know that the column is a varchar, or the equivalent in the SQL dialect you are using.
The creators of Hibernate are the first to admit that it doesn't solve every problem, and it wasn't intended to. What it does is produces good enough SQL (at least as good as a person) for most problems. Hand-crafted SQL or HQL can still be written (and externalized), and sometimes you just need to go as low-level as possible (JDBC, for ex).
Slashdot Mirror
"it will take a lot more source code, and a lot more time" That was my point, although in respect to Ruby vs PHP instead of C.
This is why we use libraries, frameworks, and higher-level languages, and why Ruby on Rails is better suited for many web apps than PHP, which was my original point.
My point wasn't that you should use C instead of PHP. It was that PHP isn't the be-all-end-all of web development. Ruby on Rails has a lot of selling points other than "look what I can build that can be built with anything else". However... You can "hook into the webserver" pretty easily with CGI programs written in C. That's how they did it (along with Perl) before PHP and every other web framework. http://en.wikipedia.org/wiki/Common_Gateway_Interface String manipulation isn't much more cumbersome in C than any other language. Just use a library if you can't figure it out for yourself. http://bstring.sourceforge.net/
If you need high-availability disaster-recovery, or simply distributed databases, you can use GUIDs for surrogate keys instead of auto-incrementing integers. You lose a bit on the integer-is-faster-than-varchar argument, but a single varchar column is still better than a natural key (which might be subject to change, requiring cascading updates for foreign keys) and especially better than a composite natural key (which effectively requires de-normalization for foreign keys.. which you might do anyway to avoid JOINs for performance reasons).
Great post, parent. Wish I could mod you up!
It depends. There have been cases (such as Twitter) where Rails apps have run into problems at high load. However, there are always solutions. Twitter's problem wasn't caused by Rails, it was caused by how they were using Rails. Their bottleneck was actually in the database, and Rails doesn't support multiple databases. Within 2 or 3 days of the issue becoming public a plugin was released. The nice thing about Rails and Ruby is that they are flexible. The dynamic nature of Ruby makes it easy to extend, and Rails benefits greatly from that.
http://www.fastcgi.com/
Ironically, I believe the rubyonrails.org site was built with PHP.
But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in C. Just because most people don't, doesn't mean it's a bad tool. If you need a tool to hold your hand and force you to adhere to best practices, then you aren't a very good developer.
I agree. That's why I build all of my computers by hand with raw transistors and whatnot.
I think database developers could learn a thing or two about Rails.
:select => 'a,b,c') will only select columns a, b, and c. Yes, all of the attributes are saved at once, but how often do you only want to save some of the attributes? It doesn't cost much to update unchanged columns -- it's probably cheaper (total guess, but makes sense) to just update them all rather than figure out which ones have changed.
:include option in finders, which is implemented as a left outer join. You can write your own joins if necessary.
"all facts for a single entity in one table"
Just break the entity up into composite parts that map to separate tables/model classes, each of which "belongs to" to the master object. There are other ways to do it too, if you want to write some code.
"using one-to-one links ("universal IDs")"
I don't know what you're talking about. I don't think these are industry terms. If you're referring to "surrogate keys", there are perfectly valid reasons to do so, and perfectly valid reasons to use them instead of natural keys.
"queries that fetch all attributes at once, and save all at once"
You can easily fetch only the attributes that you need. Model.find(:all,
"minimal use of joins"
Sure, if you don't know how to use them. Rails makes eager fetching easy with the
"implementing complex queries in procedural code"
This is not an issue if someone understands encapsulation. It's up to the developer to do it right -- Rails doesn't do it wrong.
You can get a paying job doing Ruby.
This isn't unique to open source. How many times has Microsoft told us to upgrade because of the enhanced security in the latest version of Windows?
I think he means that if only the actual stick were broken, it would be nice to have the option to press a button to pause the game and plug in a new joystick. A lot of Atari joysticks have bad sticks, but the buttons still work.
Not that your trolling deserves a response, but gaming is a pretty common use of PCs, and considering that this thread is in the Gaming section, it seems a relevant question.
Have you ever used a trackball for gaming? I haven't, but I don't imagine it would be very effective.
Writing C++ and having the OS talk directly to the processor is partly to blame for instable systems. Low-level access requires high-level knowledge -- one byte out of place and someone's mechanical lung stops working.
Operating systems 20 years ago used much less memory than they do today. That doesn't mean that modern OS's aren't as good, just as having a virtual machine isn't necessarily bad. The concept of abstraction layers is a good one, even though they usually have a cost. Like anything else, the cost has to be weighed against other factors (efficiency being one, but also portability, security, time-to-market, and robustness).
Embedded systems may be an exception in a lot of cases. However, there is embedded Java (J2ME), and resources are relatively cheap (and getting cheaper). It's probably often cheaper to use Java and a bit more hardware than designing against a proprietary system to skimp on the hardware costs. Economies of scale, and all that.
Isn't an OS just a kind of runtime environment? After all, it's just one level of abstraction among many levels of abstraction. A Java Virtual Machine is just one more level of abstraction.
Not exactly. Not all Germans were Nazis. Most, but not all, Nazis were German.
Even Hitler technically wasn't German.
You have a problem with people hacking into your cell phone account and paying your bill for you?
2GB may be more space than YOU need at this point in time, but I doubt that you can speak for everyone for the forseeable future.
Google, Yahoo, Microsoft, etc, don't simply allocate 2GB on some hard drive on some computer for each user. That would be the most inefficient and least cost-effective solution that is possible (other than, say, delegating one server per user). It is much more likely that their implementation does not tie your email account to any one particular hard drive, or even one particular server. The contents of each message might be on any computer that happens to have the hard drive space, and I can guarantee that each hard drive is backed up, mirrored, and otherwise made redundant. They keep track of how much hard drive space you are using, and simply prevent you from using more than 2GB.
One could also argue that exposure to OSS, even on a closed OS, is a good thing. Especially when said closed OS has a virtually ubiquitous market share.
Velocity is a term used in the Agile software development method.
Hibernate has an option to turn output/log the SQL statements that it generates. You can also run a profiler on your database (SQL Server's SQL Profiler is nice) to capture everything that happens.
Mappings of every common data type are built into Hibernate, and you can write custom user types for anything weird. I'm not aware of any problems. In fact, Hibernate will figure out what data type a column is by using reflection on the POJO. If column "LASTNAME" is mapped to "lastName", and "getLastName()" returns a String, it's smart enough to know that the column is a varchar, or the equivalent in the SQL dialect you are using.
The creators of Hibernate are the first to admit that it doesn't solve every problem, and it wasn't intended to. What it does is produces good enough SQL (at least as good as a person) for most problems. Hand-crafted SQL or HQL can still be written (and externalized), and sometimes you just need to go as low-level as possible (JDBC, for ex).