Yes, sometimes capitalism makes me sick (though I cannot offer a better alternative for the world). An industry arises for a particular problem and they perpetuate (become part of the) problem. This happens all the time in medicine/health industry, law, and of course computer.
I don't see how the content of your post is an argument to "MySQL causing harm to *web hosting*".
In fact, shared web hosting simply cannot use mod_perl due to the inability of mod_perl to prevent normal users from messing up Apache within their.htaccess files.
If you are typing it from scratch, you'll want a quick way to check the syntax. AKA validation.
YAML parser will validate your YAML documents, much like an XML parser validate XML documents. And additionally you can quickly check the syntax with your _eyes_, since YAML uses indentation.
YAML also has builtin datatypes, so when you load it, you will automatically get a data structure of strings, numbers, symbols, etc. instead of just strings for all values. And thus you save time by not having to cast datatypes.
Basically, I've ditched XML and used YAML for all my config files and I've never been happier.
Actually I'm glad that Sun restricts JDK/JRE distributions. It allows other (and better!) languages to flourish in Linux/BSD environments. Perl, Python, Ruby... I'd hate to hack Java OSS (but I fear in the future we will be seeing more and more C# OSS).
Is that there's currently no way to restrict Perl* directives from being specified in.htaccess files. This makes it insecure for hosting servers to use mod_perl. Server admin certainly doesn't want normal clients to access mod_perl. Otherwise, mod_perl could be useful for server admins to customize their webserver.
mod_ruby on the other hand now has RubyRestrictDirectives to do exactly that.
True, but since this misconception is so common, perhaps the "Unstable" label is not appropriate (i.e. who the hell gave the "unstable" name in the first place? we know it means fragile!)
So perhaps choose another name for this branch: incoming? bleedingedge? cuttingedge?
You might not consider speed as a problem, but many other sites do. "Providing a worthy alternative to IIS on Windows (including speed-wise)" is very much a valid problem.
Oh and not all requests are database heavy dynamic pages. Images, static HTML files, redirections, 304 responses, etc.
Actually there are real problems in Apache 1.3.x that are addressed (or supposed to be addressed) by Apache 2.x. Threads, for one. Servers on Windows really should use threads and not processes due to the immense overhead of process creation.
And then there's supposed to be a per-child MPM that can separate multiple users better. I've never heard more of it these days. Anyone knows whatever happened to it? If there's one compelling reason to upgrade to Apache 2, that's _it_ for me.
Re:Why reimplement Ruby?
on
RAD with Ruby
·
· Score: 1
> > C and UNIX and nothing else > What else is there?:-)
Suddenly your post loses all credibility.:-)
The "lacking implementation" (e.g. no native threads in CRuby, subpar speed, Unicode support) problem is very real and needs to be addressed as soon as possible. Ruby is already 10 years old, people expect it to be stable and solid, language-wise or implementation-wise.
wxRuby is nice, but sadly, as long as Ruby doesn't have OS threads ("real" threads), coding complex GUI apps in Ruby will still be a pain...
Re:Someone please tell me what I gain over Python?
on
RAD with Ruby
·
· Score: 1
One of the acid tests for a language (certainly not the only one, but a really big one for journeyman developers) is the number of ready to roll third party libraries available to enable the language to create sophisticated and ready to deploy applications using only the language itself.
I wouldn't call it an acid test for a language as much as for the _popularity_ of that language.
Here, IMO, Python is unequalled by almost anything else.
Umm, have you heard about CPAN?
Re:Someone please tell me what I gain over Python?
on
RAD with Ruby
·
· Score: 1
In touting Python, a respondent will invariably trot out generator in Python and then suggest that generators are more transparent/clear/aesthetically pleasing thatn Ruby blocks, never mentioned that:
1. Ruby does not *need* generators. Generators are Python solution to a Python problem.
2. Ruby can *easily* implement generators, and the resulting syntax is as "beautiful"/aesthetically pleasing as in Python.
Search the Web or Slashdot for past discussions on this.
However, since you're very comfortable in Python, it's very likely that you will find Ruby too Perl-like or too cryptic, as 95% of all Python users.
Re:Ruby thread scheduler uses gettime.. DANGER!!!
on
RAD with Ruby
·
· Score: 1
Agrees. But this is the limitation of the implementation. In the future Ruby will most probably have OS threads. Currently it implements its own threads. Don't overlook a nice language because of the implementation.
Ok, I couldn't care less if I'm using "real OO" or not. But I want better syntax, damn it! Perl's OO syntax is just horrible! But luckily there are Perl modules to hide that.
God, Microsoft Frontpage client is my favorite. Error messages like "Could not find a web server at 'your.host.name' on port 80. Please check to make sure that the web server name is valid and your proxy settings are set correctly. If you are sure that everything is correct, the web server may be temporarily out of service." Long, verbose, completely useless. "Could not find"? Why? "Out of service?" WTF?
For me, views are mostly valuable to significantly simplify queries. With views you can accomplish your complex query in steps: create a view with some criteria, then do a select on that view, and so on.
Then there's materialized views. This one is really useful for performance while still keeping your model clean (no more need to do manual triggers to update summary tables, etc).
Your loss then, I guess. True, O'Reilly churns out many good books, but of all my favorite books, only about 10-20% of those are O'Reilly's. SQL For Smarties, The Data Warehouse Lifecyle Toolkit, Unix Haters' Handbook,...
You're missing _a lot_ if you limit yourself to O'Reilly.
Why do people keep saying MySQL doesn't have transactions or subqueries? For heaven's sake, please update your 4-year-old facts!
Oh, and PostgreSQL is actually better for ANSI SQL compliance. It's one of the most SQL-standard compliant database I've ever seen (certainly more standard than Firebird). Call me when Firebird has TIMESTAMP WITH TIME ZONE datatype.
There are free alternatives, mind you. Gaim, Miranda, even CenterICQ. All support Yahoo!, ICQ, (and some even support AIM and MSN). And then there's Trillian...
Slashdot Mirror
Yes, sometimes capitalism makes me sick (though I cannot offer a better alternative for the world). An industry arises for a particular problem and they perpetuate (become part of the) problem. This happens all the time in medicine/health industry, law, and of course computer.
I don't see how the content of your post is an argument to "MySQL causing harm to *web hosting*". In fact, shared web hosting simply cannot use mod_perl due to the inability of mod_perl to prevent normal users from messing up Apache within their .htaccess files.
Really? Where can I read about it? And you mean GUIDs, right?
It's easier to parse than virtually anything else whatsoever. Why? Because 99% of programmers don't parse it. They use a pre-existing XML parser.
Well, if we don't care so much having to write our own parser, why not choose a nicer, easier-to-type format instead?
When I think about it, XML scores pretty badly ("C or D student") as a data storage (or one would argue, also as markup) format.
* EASY TO PARSE: not really
* COMPACT: no
* EASY TO TYPE: no (too much to type and all those angle brackets...)
* EASY TO READ: not the easiest for the eye
* FEATURE-RICH: no (no builtin datatypes, no syntax for intradocument references, no macro, no directives/flags, etc.)
No wonder people hate XML so much...
If you are typing it from scratch, you'll want a quick way to check the syntax. AKA validation.
YAML parser will validate your YAML documents, much like an XML parser validate XML documents. And additionally you can quickly check the syntax with your _eyes_, since YAML uses indentation.
YAML also has builtin datatypes, so when you load it, you will automatically get a data structure of strings, numbers, symbols, etc. instead of just strings for all values. And thus you save time by not having to cast datatypes.
Basically, I've ditched XML and used YAML for all my config files and I've never been happier.
What's wrong with Money? I always thought it's pretty decent for non-computer folks to use. And it's now the market leader?
Actually I'm glad that Sun restricts JDK/JRE distributions. It allows other (and better!) languages to flourish in Linux/BSD environments. Perl, Python, Ruby... I'd hate to hack Java OSS (but I fear in the future we will be seeing more and more C# OSS).
Is that there's currently no way to restrict Perl* directives from being specified in .htaccess files. This makes it insecure for hosting servers to use mod_perl. Server admin certainly doesn't want normal clients to access mod_perl. Otherwise, mod_perl could be useful for server admins to customize their webserver.
mod_ruby on the other hand now has RubyRestrictDirectives to do exactly that.
True, but since this misconception is so common, perhaps the "Unstable" label is not appropriate (i.e. who the hell gave the "unstable" name in the first place? we know it means fragile!)
So perhaps choose another name for this branch: incoming? bleedingedge? cuttingedge?
You might not consider speed as a problem, but many other sites do. "Providing a worthy alternative to IIS on Windows (including speed-wise)" is very much a valid problem. Oh and not all requests are database heavy dynamic pages. Images, static HTML files, redirections, 304 responses, etc.
Actually there are real problems in Apache 1.3.x that are addressed (or supposed to be addressed) by Apache 2.x. Threads, for one. Servers on Windows really should use threads and not processes due to the immense overhead of process creation.
And then there's supposed to be a per-child MPM that can separate multiple users better. I've never heard more of it these days. Anyone knows whatever happened to it? If there's one compelling reason to upgrade to Apache 2, that's _it_ for me.
> > C and UNIX and nothing else :-)
:-)
> What else is there?
Suddenly your post loses all credibility.
The "lacking implementation" (e.g. no native threads in CRuby, subpar speed, Unicode support) problem is very real and needs to be addressed as soon as possible. Ruby is already 10 years old, people expect it to be stable and solid, language-wise or implementation-wise.
wxRuby is nice, but sadly, as long as Ruby doesn't have OS threads ("real" threads), coding complex GUI apps in Ruby will still be a pain...
One of the acid tests for a language (certainly not the only one, but a really big one for journeyman developers) is the number of ready to roll third party libraries available to enable the language to create sophisticated and ready to deploy applications using only the language itself .
I wouldn't call it an acid test for a language as much as for the _popularity_ of that language.
Here, IMO, Python is unequalled by almost anything else.
Umm, have you heard about CPAN?
In touting Python, a respondent will invariably trot out generator in Python and then suggest that generators are more transparent/clear/aesthetically pleasing thatn Ruby blocks, never mentioned that:
1. Ruby does not *need* generators. Generators are Python solution to a Python problem.
2. Ruby can *easily* implement generators, and the resulting syntax is as "beautiful"/aesthetically pleasing as in Python.
Search the Web or Slashdot for past discussions on this.
However, since you're very comfortable in Python, it's very likely that you will find Ruby too Perl-like or too cryptic, as 95% of all Python users.
Agrees. But this is the limitation of the implementation. In the future Ruby will most probably have OS threads. Currently it implements its own threads. Don't overlook a nice language because of the implementation.
Ok, I couldn't care less if I'm using "real OO" or not. But I want better syntax, damn it! Perl's OO syntax is just horrible! But luckily there are Perl modules to hide that.
And your post is just an inferior troll. Python is trying to be too Perl-like, and Ruby is not? WTF?
What about virii then? Or some entirely new kind of life form? I'm all for progress, but you can never be too cautious.
God, Microsoft Frontpage client is my favorite. Error messages like "Could not find a web server at 'your.host.name' on port 80. Please check to make sure that the web server name is valid and your proxy settings are set correctly. If you are sure that everything is correct, the web server may be temporarily out of service." Long, verbose, completely useless. "Could not find"? Why? "Out of service?" WTF?
For me, views are mostly valuable to significantly simplify queries. With views you can accomplish your complex query in steps: create a view with some criteria, then do a select on that view, and so on.
Then there's materialized views. This one is really useful for performance while still keeping your model clean (no more need to do manual triggers to update summary tables, etc).
Your loss then, I guess. True, O'Reilly churns out many good books, but of all my favorite books, only about 10-20% of those are O'Reilly's. SQL For Smarties, The Data Warehouse Lifecyle Toolkit, Unix Haters' Handbook, ...
You're missing _a lot_ if you limit yourself to O'Reilly.
Why do people keep saying MySQL doesn't have transactions or subqueries? For heaven's sake, please update your 4-year-old facts!
Oh, and PostgreSQL is actually better for ANSI SQL compliance. It's one of the most SQL-standard compliant database I've ever seen (certainly more standard than Firebird). Call me when Firebird has TIMESTAMP WITH TIME ZONE datatype.
There are free alternatives, mind you. Gaim, Miranda, even CenterICQ. All support Yahoo!, ICQ, (and some even support AIM and MSN). And then there's Trillian...
First of all, Ruby doesn't need generators since it has proper closures.
Second of all, it's trivial to implement generators/coroutines using continuations in Ruby. Using the Fibonacci example:
require 'generator'
g = Generator.new { |g|
a, b = 0, 1
while true
a, b = b, a+b
g.yield a
end
}
p (1..10).collect { g.next }
will print:
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
Don't bash Ruby if you know next to nothing about it.