Her predecessor had disappeared on a similar trip, probably killed by a shark. 'She was a hero,'
...
In a decade we think it will be commonplace to have roving fleets of these gliders making transoceanic trips.'
...
I have had a great experience, so far, and I shouldn't....
Starting around midnight, this morning, I upgraded from 64 bit Jaunty Studio, which was setup like this:
Jaunty Studio was "upgraded" to Kubuntu
Used Intel graphics -- the kind of card Jaunty particularly hates
64-bit Flash, 64-bit Java, 64-bit Firefox
MythTV with all the add-ons I could throw in...
I *should* be a poster child for problems.
I only had 3 minor issues:
~/.ICEAuthority permissions issues (easily corrected)
An issue when switching to text mode using Ctrl+Alt+F{1,2,3,4,5} (should be easily correctable in grub)
Mythtv-status no longer knows how to calculate drive totals (I think that's easily fixed, but haven't looked)
Everything is so much snappier, but that could be due to Jaunty vs. Intel Graphics wars or it could be due to a mem leak on Jaunty (I can't prove that one but I swapped heavily until the upgrade).
As a long-term Perl programmer, myself, who switched to Ruby, virtually everything you're talking about is either an ugly hack or is an add-on via CPAN or is only available in 5.10+.
As for features available in 5.10+, that's totally fair, but I abandoned Perl around that time. As for Moose, it's not part of the core language today.
Maybe if a production-ready version of Perl 6 ships by late 2011, I may give it a try, then. Is it truly ready for prod, now? If so, I'm interested.
Don't get me wrong; Perl 5 is a popular, very powerful dynamic language that I programmed in for 12-13 years, myself.
To say, however, that Perl 5 is better than Ruby 1.8/1.9 in every respect or to equivocate between the already available Perl 5 and the maybe-it'll-be-released-real-soon-now-perhaps Perl 6 isn't fair and smacks of fanboyism.
It's not like I am comparing 2 languages, one of which I never programmed in.
As to the study - I think this is one of those correlation vs. causation issues. The study is worried that seasonal flu vaccine -> swine flu infection. When, in reality, it is more likely that:
High risk of any flu infection -> obtaining seasonal vaccines
High risk of any flu infection -> contracting swine flu
I do agree and that's why I think most studies border on pure junk science.
This study seems, at least to me, to be more likely to be accurate than most studies, due to factors in the original article.
But, you're right, correlation and causation or correlation vs. causation?
Lifted straight from Python? How's that? The syntax doesn't even superficially resemble Python's. Where do you get proof for that (I looked and see nothing to back up your claims)?
Perl got objects in 1994, with Perl 5. Python was released in 1991. It *could* have happened the way you describe, but I don't see evidence of that. I bet some Pythonistas would challenge that assumption.
In Python, as far as I can remember, nearly everything is an object (except, basically keywords and immutable types), with the ability to call methods on most things, even many immutable types, such as numbers:
>>> (1).__add__(2)
3
In Ruby, where essentially everything (other than keywords) is an object:
>> "hello world".length
=> 11
How does Perl compare to either of these, even Python?
Ruby 1.8 and Ruby 1.9 are production-ready, as is Perl 5.
Perl 6 is "any decade now." I don't see a sequitur leap to a comparison between Ruby 2 and Perl 6, since you started by comparing Ruby 1.9 to Perl 6.
Very few people worry about Ruby 2, while Perl 6 is considered a "big deal" to Perlers. Perl 6 is still on the drawing board and is in a severe state of flux, many, many years later. I think the Perl 6 project has failed due to scope creep. Ruby 2 is rarely discussed, since it's not a "big deal," so it hasn't suffered from that kind of "bit rot," yet. Ruby 2 is just a relative glimmer in a few people's eyes, even if it, like Perl 6, is a long-term project.
Comparing Ruby 1.9.x to Perl 5.11.x may be more of a valid comparison, in terms of what they mean to the next big leap.
Both Ruby 1.8 and 1.9 have severely more powerful OOP constructs than Perl 5. All three of these are prod-ready.
Still, Perl 6 is supposed to greatly break compatibility. Ruby 1.9 doesn't greatly break compatibility, and 2.0 is also expected to be easy to port, but we'll see. Perl 6 is mostly a different language, according to what I've read.
Perl 5 has bolt-on class-based objects. These superficially resemble C++/Java/C#'s classes. Ruby has objects resembling the king of OOP: Smalltalk. There's a big difference, there.
Ruby has open classes, true exception handling, method_missing(), duck typing, and reflection. Lambdas are truly useful (check out iterators).
Even though Ruby is extremely dynamic, it is strongly typed, without getting in your way -
This is an error:
"hello world" + 5
This is not and returns an integer 5:
"hello world".to_i + 5
In Perl 5, this is not an error:
"hello world" + 5;
So, in Perl 5, if you accidentally set a variable wrongly, you still get an answer, instead of an exception you can handle. This can be catastrophic to data integrity. `use strict;` and `my $variable;` don't help this situation.
I just have one question, in closing.... Have you spent at least 6 months trying to become proficient in Ruby? If not, I challenge you, as a former Perler. Try it for 6 months, part-time....
See if you get as hooked as many of us have.
Sorry, Mojo is "like" Rack. Mojolicious is more "like" Rails. I use the quotes around "like," because both are weakly inspired by Rack and Rails, not close to being "clonish" like Groovy on Grails.
Speed, by the way, is *not* one of Ruby's strengths, although its performance and scalability are greatly improving and have more "tweakability."
I am having trouble backing up the performance differences claim (one that used to be easy to do) -- perhaps Perl has finally closed this gap over the past couple of years.
However, the opinions that PHP is cleaner and easier to learn are shared by many:
http://www.killerphp.com/articles/php-vs-perl-vs-java-a-students-question/
http://www.webmaster-forums.net/web-programming-and-application-development/php-vs-asp-vs-perl
http://www.thesitewizard.com/archive/phpvscgi.shtml
I used to be a believer in Perl (and PHP, for web development) but have changed my mind, due to Ruby.
As a programmer, are you open to change and trying new stuff? Why not learn from other languages, like Ruby, Lisp, or Smalltalk, to become a better Perl programmer?
There was something odd about the Spanish Flu, which was a more deadly version of H1N1. It attacked and killed the healthy and young far more than the sick and the weak, the very young and the elderly.
Now, the report, below says that the two H1N1's are "distant cousins" and "totally not related", but...
The newer "swine flu" H1N1 strain also seems to be following that pattern -- killing teens and "the very healthy" more than the old or young people, in spite of their relative health.
The Spanish Flu made the body attack itself -- the healthier you were, the worse the reaction Click Here:
The Spanish flu, also known as La Gripe Española, or La Pesadilla, was an unusually severe and deadly strain of avian influenza, a viral infectious disease, that killed some 50 million to 100 million people worldwide over about a year in 1918 and 1919. It is thought to be one of the most deadly pandemics in human history. It was caused by the H1N1 type of influenza virus.[4]
The 1918 flu caused an unusual number of deaths, possibly due to it causing a cytokine storm in the body.[5][6] (The current H5N1 bird flu, also an Influenza A virus, has a similar effect.)[7] The Spanish flu virus infected lung cells, leading to overstimulation of the immune system via release of cytokines into the lung tissue. This leads to extensive leukocyte migration towards the lungs, causing destruction of lung tissue and secretion of liquid into the organ. This makes it difficult for the patient to breathe. In contrast to other pandemics, which mostly kill the old and the very young, the 1918 pandemic killed unusual numbers of young adults, which may have been due to their healthy immune systems mounting a too-strong and damaging response to the infection.[2]
The term "Spanish" flu was coined because Spain was at the time the only European country where the press were printing reports of the outbreak, which had killed thousands in the armies fighting World War I. Other countries suppressed the news in order to protect morale.[8]
Perhaps there is something to this study. Now, I don't believe studies as a rule and I have criticized the same, but logic and history seem to add evidence to the *strong* correlation.
As to this study, I think it's a lot closer to being airtight than most (very large sample size, fractional percent margin of error, good science, peer reviews, findings being scrutinized and met with skepticism):
Sadly, I'm not as dubious of this Canadian study as others and will weigh my options for my family....
BTW, PHP is the undisputed king in web development and compares favorably with Java and C#, in terms of sites, code, and jobs. It's also faster, easier to learn, and cleaner than Perl.
Perl definitely has more legacy code and sites than Ruby on Rails, sure.
I'd submit that RoR code is better/cleaner and supports larger teams of coders.
Even if all you do is get proficient with Ruby and later RoR, you will change the way you code in Perl/PHP/whatever.
BTW, if imitation is the most sincere form of flattery, see CakePHP, Groovy on Grails, ColdFusion on Wheels, the Castle Project, and Mojo. RoR is influencing frameworks on PHP, Groovy/Java, Cold Fusion, C#, and Perl, respectively.
...yet in practice, CPAN has trouble compiling large numbers of libraries on "tier 2" platforms, such as AIX and HPUX.
Try getting Expect from CPAN for HP/UX, some time.... Expect works, Perl works, Expect.pm does not.
In practice, even Solaris 8/9/10 has issues where package A depends on version x.y.z of package B which conflicts with version a.b.c of package C, and package C needs a newer version of package A than will compile on Solaris, due to C-library vs. Xyz.pm issues.
Where I worked, it was often nightmarish to compile/make the 150+ CPAN packages and install tons of GNU libraries, to make a typical Apache-based website that had both Websphere and Perl CGI.pm-based apps. We loved Perl and touted it, even as we were cursing CPAN packages under our breath.
To me, an ex-Perl programmer, it doesn't matter if it compiles on "hundreds" of platforms, if my platform runs only the parts of CPAN I don't need....
Also, I wrote well-documented code, compared to most Perl programmers. Yes, I have read much Perl code over the years, at work, home, and on the 'net -- my own and others.
Perl is notorious for unreadable code! Just check the opinions of *seasoned* Perl programmers on the net. There is an attitude that "if it was hard to write, it should be hard to read."
Perl has never been known for clear, clean code -- short code but not clean code. It's "blessed" object model, for instance is an ugly, bolt-on hack.
I have no interest in Perl 6, ever since I read that its backward compatibility with Perl 5 was even worse than Python 3 was with Python 2.x (which has a converter) and also after I spoke to somebody on the Perl 6 team who said that the spec, years later, was not even close to complete. Two years later, it still isn't.
Who really trusts Perl 6 in a mission-critical production environment? Many do daily with Java, C#, vb.net, Python, Cold Fusion, Ruby, asp, vbscript, etc. Perl 6, of course, isn't "finished" yet.
I believe Perl 6 has no future. This was the final nail in the coffin for me to explore this up-and-coming Ruby. Many Perlers, back then, were open-minded enough to try Ruby, as were many in the Java world.
I made the switch, and while I am still more proficient with Perl (after 13 years of Perl 4/5 vs. about 1-2 with Ruby), I find a "programmer's joy" with Ruby and a learning experience nearly every time I use it. My code is cleaner, more readable, more concise, and more reusable in Ruby. It is fun, enlightening, and better for scripting.
Try Ruby, you might like it. I've "evangelized" Ruby to Perl and Python addicts at work. Much to their delight, Ruby becomes something they quickly begin to prefer over Perl and Python. Almost every time they use it, they find the same "profound enlightenment" moments I have. Lispers have this same experience, although probably to a greater degree.
Nobody is saying you have to be an exclusive Rubyist. I still do use Perl, for the quick-and-dirty. I still use bash and am learning Python.
I now know a little Rails, which (make no mistake) has a steep learning curve.
Who says RoR doesn't work in practice? Twitter? LinkedIn? Hemnet? Shopify? Doodlekit? 43Things? Nope.
In each of the above cases, the site either has to scale/perform like crazy, has complex data needs, needs rich content, or all of the above. It works in practice...
Again, be open-minded and try Ruby. You just might like it. Unlike Perl 6, it's here and now. If you are stuck in a Java-only environment, try JRuby 1.x, which is Ruby for the Java masses.
OK, then there's Ruby. It preserves the best pieces of Perl, Smalltalk, Python, and Lisp.
Perl's `qw(one two three);` actually works in Ruby as `%w{one two three}` but many constructs are semi-close to Perl.
It is considered to be in the Perl family of languages but is a supremely cleaned up / ultra powerful OOP language, in the Smalltalk vein.
In general, Ruby is as pragmatic as Perl, if not more so. It has a cleaner, more readable syntax, and code is very/most often shorter than a Perl equivalent.
As an ex-Perler myself, I'm not looking back. Ruby is a far more powerful language, and I can read other's code (and even my code, 6 months later).
Ruby exceeds Perl in web development, a la Rails (or Merb). It comes with many "hackers' libraries" built in, such as Expect, Erb, and Net::. Ruby Gems has Rubyforge, Raa, and GitHub as sources, which are functionally similar to CPAN. However, Gems is cleaner, without all manner of compilation and portability issues (and less code rot).
Ruby's lambdas, open classes (monkey patching,) and method_missing() make Perl hackery look anemic and juvenile, by comparison. If you need a different way to program, try building a DSL in Ruby, which is similar in functionality to Lisp's macros, just without S Expressions.
In short, Ruby is a better Perl 5/6 than Perl 5/6....
Please enlighten us, could we have your full email address, to verify your spam percentage?
Belittling British Boffins Bears Bad Backlash!
Correct, Science != Public Policy.... Science == Private Policy.
Step 1. Parents must get much more involved with their children and their education.
Step 2. Parents must stop relying on anybody else to educate their children and take control of their education. (See also step 1).
Step 3. Parents must emphasize all areas of education, including math and science, showing interest, themselves. (See step 1).
Step 4. Parents need to appropriately remove distractions to education, such as TV, Internet, Games, Disruptive Friendships, and teach a work ethic. (See step 1, once again).
Step 5. Parents may want to look at alternatives to where/how their kids get educated, such as private schooling, charter schooling, homeschooling, private tutoring, or supplemental education. (Again, see step 1).
Step 6. Parents should learn the subjects with their children (if they don't know the subject) and tutor them, if possible. (Really, see step 1).
Step 7. Parents should be sure their children have unconditional love by the parents. (Most important and saved for last).
If one family does this, their children excel. If millions do, a country excels.
The status quo of relying on the public school system to do all the education, discipline, and raising of children does not and never will work. We keep throwing more dollars at the problem and it keeps getting worse (at a rate faster than inflation).
Take a look at John Taylor Gatto's books, such as Dumbing Us Down: The Hidden Curriculum of Compulsory Schooling and The Underground History of American Education or here. While this is not a 100% solution, it should spur parents to do the steps, above.
> That's just in the rack consumption. I would imagine these probably run cooler, too, which will help with HVAC costs.
I understand that for every "power watt," it takes 1-2 additional "cooling watts" additional power, in a server room.
So, if a rack takes 10KW, expect an additional 10-20KW of electricity to cool the server room.
I'd, then, estimate 30KW total for a 10KW rack, just to be safe.
So, an 18% savings on 10KW (1.8KW saved), is really saving you on the order of 3.6KW to 5.4KW, when you include cooling!
At $0.10/KWH, you save a bunch of money in electricity.... Just an 18% savings on 10KW (20KW to 30KW total with cooling), means a total savings of $259.20 to $388.80 a month!
It is easier to write an incorrect program than understand a correct one.
