Now measure execution time and compare not on a bare table but in a real business application.
Why should I try? Your post is vague to the point of hand-waving about what the actual scenario and problem is, so whether I can reproduce an environment that is close enough to yours to get relevant figures out of it is anyone’s guess. I’m not into games of throw dice and make shit up. I stuck to a question with a clear answer (“how do I get monthly in addition to weekly aggregates with SQL?”).
As far as can be gleaned from your post you may well be right, but just as likely you may be clueless about how to make SQL and/or Perl work to your advantage. The knee-jerk reactions against your claim are silly too – your post is missing way too much detail for any bystander to decide whether the people at Booking were the idiots or you are. Or neither. Or both.
Shrug.
]]>the stage was set in the very first paragraph. “Perl is a toy, is everyone too stupid to see that?”
Nobody said that here except you.
Your post is vague to the point
Again, you give the answer with an example of the exact piece of code as a response to the vague question.
I have read this post and the comments with some interest. And I have gotten some clues about what to do when I should have to process really big amounts of data. This has never happened to me. Although some million datasets I once analyzed for fun and as a proof of concept. The script was surprisingly fast and it made a huge difference if I used Text::CSV or a "real" database, of course. Sadly I can't give the exact numbers.
I once even experimented with pack() to save memory, but this became obsolete after I had bought a new computer with much more RAM..
Nobody said that here except you.
You didn’t say it, but everybody responded to you as if you had. The tone of the responses would have been hardly different without your attack on Booking, as SawyerX thought.
Again, you give the answer with an example of the exact piece of code as a response to the vague question.
“Tell me please where do I see the number of items and their sum in June?”, with most of the SQL already included plus a sample result output table, is not a vague question.
So what is it that you thought I wish to read? I didn’t think I had any particular agenda but I may be lacking self-awareness, so I’m curious.
]]>You are telling me how you would write a blog post. But I wrote as I wrote it.
Of course you wrote it as you wrote it. It’s your choice. That was just my opinion and suggestion, and you’re free to ignore it if that’s what you want.
I have no idea of the performance of other high level languages in these circumstances, why should I mention them?
Because if anything (and especially if you’re right about your claims here), it’s definitely not a Perl-specific thing but it’s relating to a certain type of languages. It would be like me attacking Ruby because it’s not as fast as Assembly. It wouldn’t be just Ruby, it would be any language like Ruby. If I were to go on a Ruby forum and tell them their language sucks because it’s not as fast as Assembly, they would probably get the impression I’m attacking their language instead of any type of language that provides the same features at the cost of speed.
Do you expect Python, Ruby or even PHP to be a much better competition to C++? I don’t think so, but you gave the impression that the problem is Perl, instead of languages that have lower performance benefits in favor of features and ease of use.
Basically you gave the wrong impression, and this is also why you got such comments.
Again, this is just my opinion, feel free to ignore it as well. I won’t be offended, it’s okay. :)
]]>The first case hasn't yet been established as wrong, but I'll ignore that for now. Others have addressed it.
The second case is what I care about. If it's not the proper tool, then it obviously has nothing to do with scissors of a specific brand. If the person failed using scissors (while all scissors are of quality X), and he blames a specific scissors company (though he'll get the same result from any other scissors produced by any other company) then he's completely misguided and misguiding others.
And I would understand the company saying "look, you either used the scissors wrong or scissors are simply not the right tool. so quit advertising that OUR scissors are fucked up, and simply say that scissors were a wrong choice, by ANY company".
What you're doing is a simple (albeit very impolite) cop-out.
Say "dynamic languages are not suitable" (and that's still of an "if" if you were using them correctly - Andrew *did* say he changed his algorithm and didn't originally use MySQL for some of the operations as he possibly could have), don't say "YOUR dynamic language is not suitable" when speaking of something that ALL dynamic languages share alike (such as performance, in this case). You're simply misleading, and you should know better.
]]>Thanks Buddy.
~Dinesh
]]>run some command | while read line do process each "$line" done]]>
$libgd_package = $::operatingsystem ? { 'Ubunutu' => 'libgd2-xpm-dev', 'Debian' => 'libgd2-xpm-dev', 'FreeBSD' => 'graphics/gd', 'Mandriva' => 'libgd-devel', 'openSUSE' => 'gd-devel', 'CentsOS' => 'gd-devel', default => 'libgd', }package { [ "$libgd_package" ]:
ensure => latest,
}
Underscoring the caveats above, dpkg -S was useless for this purpose, advising me only that no installed package provided the needed package. And apt-file requires the installation of an additional package. Guess I ought to add that to my utilities manifest, at least for my development machine.
]]>Otherwise, this puppet syntax seems to work fine.
]]>