It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
No, it's about having less issues by using modern tools, rather than trying to find who's to blame.
If HTML/JS/CSS/HTTP could be redesigned today, do you think that the way a browser manage cookies, XHR requests and sandboxing in general would be the same as it is today? Do you think that the SMTP protocol that was good enough 30 years ago is not a big pile of crap nowadays, even, just like ORMs, their content is now shown in webmails? SQL is just like SMTP. Or the FAT filesystem. An old thing. There are worthy proposals and even working products that could superscede them, but because of legacy applications and people who want to stick with the same technologies till the end of the universe, these old things remain. They just get bloated with new extensions instead, in order to keep up with mandatory requirements.
they exist because of the crappy programmer who doesn't know how to use the database
"Our GUI _is_ user-friendly! Customers just don't understand how to use it because _they_ are clueless!"
"hey, and there's a workaround to make them use it properly. Just tell them to top an GUIORM (pick one out of hundreds), an extra layer that hides our wonderful GUI and shows another GUI that's closer to reality, and transparently translates events both way, while introducing some new limitations (thinking about that other ORM that has no way to issue OR-like statements) and some grain of extra sluginess!"
> WTF! I think that ranks as one of the stupidest statements I have ever read on slashdot!
Tons of people aren't exactly writing PHP websites, but are still able to install vbulletin, phpbb, phpnuke, joomla, wordpress on mutualised hosting. And then they fire phpmyadmin in order to remove bogus users, to count the number of posts or visits, etc. SQL perfectly makes sense for this.
"id" is MP3 data. How do I find the title of the song? Will your 3 liners do the trick? In a document-oriented database id wouldn't be an issue. No need for any wrapper.
Marschaling is still required, but you don't need to think about being restricted to a schema, columns, types, to define identifiers for everything, to do explicit joins, etc. Just store your objects as they are in memory. Look at MongoDB: http://www.mongodb.org/
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query. And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement. If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Talked about "records" and "id" because people familiar with SQL might not be familiar with other kind of databases, but you took it the wrong way.
Now, ask Google. How many critical vulnerabilities were due to SQL injections? How many similar vulnerabilities were found in SQL-free databases?
I agree with you that workarounds do exist, and that developpers are to blame instead of SQL, but in the real world, SQL is how a lot of services are compromised by kiddies.
Why do we need to invent wrappers? Why do tools like GreenSQL exist? Why do we need ORMs? Why does a stock PHP have 5 different APIs just to issue basic MySQL queries? Why are there hundreds of third-party PHP abstraction layers and ORMs? How come every PHP project reinvents yet another SQL abstraction layer? How come, even though both are using the same SQL database server, it's a real hell to merge code of a PHP application with another PHP application, because they invented their own abstraction layers? Why do people want to hide SQL at the first place (even Apple in newer iPhone SDKs)?
Maybe just because there's something wrong with the SQL language itself.
Scalability is one thing, but what we appreciate in SQL-free databases is also that they don't require SQL.
When what we want is just to retrieve a record, calling get(id) is way easier and more secure than building an SQL statement, and way cheaper than using an ORM.
The Tokyo Cabinet API is absolutely excellent in this regard. And there's no need to learn yet another domain-specific language like SQL, just use the language you use for the rest of the app.
Now, SQL-zealots would troll "but how would you do with ?". And yes, for complex requests as in data mining, SQL and XPath make sense. For people who aren't developpers, SQL makes sense as well. For interoperability with 3rd-party apps, SQL is also useful, just as FAT is still useful today in order to share filesystems between operating systems.
But for the rest of us, SQL is cumbersome. Databases like MongoDB make you achieve similar results in a more natural way instead of forcing you to learn SQL and to rethink everything in a tabular way.
I wouldn't be surprized if Apple dropped ZFS for BTRFS or DragonflyBSD's HAMMER, just because their license is better, because their performance don't degrade much over time and because Oracle has nothing to do with them.
If the masses were blocking ads, what would happen?
1) The web would become a marvelous place without any ad anywhere. 2) Tons of web site would just close 3) Tons of web site would require you to pay per view 4) New, more intrusive, difficult to block, kind of ads would go mainstream. (similar to spam filters vs spammers).
To tell the truth, 1) would only happen in a fairy tale.
Slashdot Mirror
Ahaha you're so funny.
Now, GOTO \your_namespace because $this->is_off_topic(TRUE == "FALSE");
There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/
John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/
Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ - http://ajaxian.com/archives/jsclass-21-released
I'm sure Lynx would win hands down.
And if you don't want to directly code in Javascript, some great alternative languages can actually compile Javascript code :
- haXe : http://www.haxe.org/
- Fan : http://www.fandev.org/
Does it run Linux?
Why the heck did they release it under an Apache 2 license, and not under a regular BSD license?
Cool, but where can we download it?
Oh we can't?
It's an internal project and it will remain an internal project just like the previous version. So what's the point for the rest of us?
I'm really more excited about projects like Elliptics Network, because at least, they can be useful to everyone, not only to Google's employees.
Ning buying Skyrock? :)
Nice to see that Piston finally gets the recognition it desserves!
I second this.
Arch Linux and Funtoo can fit the bill.
It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
No, it's about having less issues by using modern tools, rather than trying to find who's to blame.
If HTML/JS/CSS/HTTP could be redesigned today, do you think that the way a browser manage cookies, XHR requests and sandboxing in general would be the same as it is today? Do you think that the SMTP protocol that was good enough 30 years ago is not a big pile of crap nowadays, even, just like ORMs, their content is now shown in webmails? SQL is just like SMTP. Or the FAT filesystem. An old thing. There are worthy proposals and even working products that could superscede them, but because of legacy applications and people who want to stick with the same technologies till the end of the universe, these old things remain. They just get bloated with new extensions instead, in order to keep up with mandatory requirements.
they exist because of the crappy programmer who doesn't know how to use the database
"Our GUI _is_ user-friendly! Customers just don't understand how to use it because _they_ are clueless!"
"hey, and there's a workaround to make them use it properly. Just tell them to top an GUIORM (pick one out of hundreds), an extra layer that hides our wonderful GUI and shows another GUI that's closer to reality, and transparently translates events both way, while introducing some new limitations (thinking about that other ORM that has no way to issue OR-like statements) and some grain of extra sluginess!"
> WTF! I think that ranks as one of the stupidest statements I have ever read on slashdot!
Tons of people aren't exactly writing PHP websites, but are still able to install vbulletin, phpbb, phpnuke, joomla, wordpress on mutualised hosting. And then they fire phpmyadmin in order to remove bogus users, to count the number of posts or visits, etc. SQL perfectly makes sense for this.
"id" is MP3 data. How do I find the title of the song? Will your 3 liners do the trick?
In a document-oriented database id wouldn't be an issue. No need for any wrapper.
Marschaling is still required, but you don't need to think about being restricted to a schema, columns, types, to define identifiers for everything, to do explicit joins, etc. Just store your objects as they are in memory.
Look at MongoDB: http://www.mongodb.org/
Not exactly since Excel macros can perform loops at least.
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query.
And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement. If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Talked about "records" and "id" because people familiar with SQL might not be familiar with other kind of databases, but you took it the wrong way.
Now, ask Google. How many critical vulnerabilities were due to SQL injections? How many similar vulnerabilities were found in SQL-free databases?
I agree with you that workarounds do exist, and that developpers are to blame instead of SQL, but in the real world, SQL is how a lot of services are compromised by kiddies.
Why do we need to invent wrappers?
Why do tools like GreenSQL exist?
Why do we need ORMs?
Why does a stock PHP have 5 different APIs just to issue basic MySQL queries?
Why are there hundreds of third-party PHP abstraction layers and ORMs?
How come every PHP project reinvents yet another SQL abstraction layer?
How come, even though both are using the same SQL database server, it's a real hell to merge code of a PHP application with another PHP application, because they invented their own abstraction layers?
Why do people want to hide SQL at the first place (even Apple in newer iPhone SDKs)?
Maybe just because there's something wrong with the SQL language itself.
Scalability is one thing, but what we appreciate in SQL-free databases is also that they don't require SQL.
When what we want is just to retrieve a record, calling get(id) is way easier and more secure than building an SQL statement, and way cheaper than using an ORM.
The Tokyo Cabinet API is absolutely excellent in this regard. And there's no need to learn yet another domain-specific language like SQL, just use the language you use for the rest of the app.
Now, SQL-zealots would troll "but how would you do with ?".
And yes, for complex requests as in data mining, SQL and XPath make sense. For people who aren't developpers, SQL makes sense as well. For interoperability with 3rd-party apps, SQL is also useful, just as FAT is still useful today in order to share filesystems between operating systems.
But for the rest of us, SQL is cumbersome. Databases like MongoDB make you achieve similar results in a more natural way instead of forcing you to learn SQL and to rethink everything in a tabular way.
Next step: educate PHP users so that they have a clue about security?
I wouldn't be surprized if Apple dropped ZFS for BTRFS or DragonflyBSD's HAMMER, just because their license is better, because their performance don't degrade much over time and because Oracle has nothing to do with them.
"In the fourth place overall, after Chrome 2, Safari 4 and Firefox"
Or said in a different way: no other browser performs worse, except IE.
And just like IE, it's still closed-source, proprietary software.
"Have to learn *another* language/system" -> Not if you're using haXe.
"Does not index well in search engines." -> Problem solved a long time ago with frameworks like Gaia / hxGaia ( http://www.gaiaflashframework.com/ )
Well, it will soon be possible to code native iPhone apps using the Flash API, through NME and haXe: http://www.ncannasse.fr/blog/haxe_for_iphone
And it rocks.
Why was parent mod'd down?
This is so true. Java isn't as slow and memory hungry as it used to be in 1995.
If the masses were blocking ads, what would happen?
1) The web would become a marvelous place without any ad anywhere.
2) Tons of web site would just close
3) Tons of web site would require you to pay per view
4) New, more intrusive, difficult to block, kind of ads would go mainstream. (similar to spam filters vs spammers).
To tell the truth, 1) would only happen in a fairy tale.