The summary text is completely misleading vs. the article text. The mosquitoes don't "deliver" a vaccine. A combination technique is used, involving an existing anti-malarial drug and repeated exposure to the parasites via mosquitoes, to cause natural immunity to develop, essentially controlling a known path to malaria immunity. The article indicates this approach isn't usable on a practical scale, yet is important because:
"This is not a vaccine" as in a commercial product, but a way to show how whole parasites can be used like a vaccine to protect against disease, said one of the Dutch researchers, Dr. Robert Sauerwein.
The article does mentions separate work to commercialize a related approach involving weakened malaria parasites.
Right, all excellent points. Also, I neglected the even more straightforward scenario of internal attackers. Sigh. Note to self: don't reason about computer security before being truly awake.;-)
People, you're getting your kickers in a twist over a fault that only occurs, per TFA, when:
The exploit can only be used directly from outside your network over the internet if you have enabled remote Web GUI management in the Administration tab.
That is, you not only have to have installed custom firmware on your router, but you have to be sufficiently non-paranoid to have exposed its admin interface to the open Internet. Yes, people should patch it, but really... YAWN.
Sounds like a great new technology but I get frustrated when product seems to take forever to get to market.
It's important to keep perspective on news items like this as "research results" rather than "products." That misunderstanding takes the fun out of a great spectator sport.;-) Sometimes results out of the lab are immediately applicable, more often they take a quite a number of years to work out the practical kinks. E.g. this recent article on silicon for photo detectors in Tech Review has a good examples of the kinds of problems researchers have to muddle through on the way from breakthrough to reality. It doesn't help that popular tech reporting (and some researchers) love to add 'hooks' of tantalizing applications for new work... but for all those lofty dreams it's still just a research result.
In short, it's best not to hitch one's proverbial horse to any one of these announcements. Instead, read a lot of them to get a good sense of where technology is headed and where academia and industry are investing their efforts.
<video codec="blah"> and let the content providers decide.
You fail to grasp the concept. The browser can only decode video for formats that it has decoder software for. If the content provider sends video in XYZZY format, which no one on Earth has ever heard of before, it's worthless. More to the point, if a content provider sends H.264 (or Theora) to a browser that doesn't support it, it's also worthless. The whole point of the <video> element is to allow content providers to choose one of the always supported formats and therefore know a-priori that it will work in the user's browser. A "choose one from this list" strategy, or creating a new plugin-hell for codecs doesn't accomplish this end.
Huh? Theora would have hardware support fired up within three blinks of its ratification as part of HTML5 and the release of browsers supporting it. For many (most? all?) instances, such "hardware" support is often implemented on DSP core(s), not a dedicated ASIC just for a specific codec, making the update just a matter of new firmware for existing systems.
Allowing a "pick one" scenario means that third-party content providers have no freaking clue what format they can present their data in for their users. The worst of all worlds: everyone has to transcode and store video into N different formats, because the industry can't get their ducks aligned...
No, one doesn't need to be utterly self-denying. GP's statement was phased differently by Bill and Ted: "Be excellent to each other." A Slashdotter, however, might require the double-negative form: "don't be an asshat.";-) Neither of these forms include "to the exclusion of oneself."
Paying attention to one's own needs is basic to the ability to interact with the world in a healthy way. People (and corporations) who deny this tend to get rather screwed up and/or end up playing doormat to others' desires.
In the case of corporations, they DO have a responsibility to the societies that permit them to exist beyond just "the shareholders." This is a stupid fallacy that I'd love to see die. Occasionally, corporations forget this and get smacked down for it -- see the history of laws and legal actions relating to pollution, lemon laws, anti-trust, etc.
Reading between Apple's lines here: many of the new features are really developer-facing instead of end-user facing. Of particular note is the category of changes referred to on Apple's Snow Leopard page called "Grand Central" -- focused on driving hard on OS X's support for multi-core software, as well as developer support for multi-core apps. See also the blurb on OpenCL support.
It's an interesting and strategic move to spend resources enabling developers to rapidly produce high-performance applications. Snow Leopard is thus a long-term investment in Apple's OS platform.
Unfortunately, you'll be forced to upgrade periodically if you rely upon either application's links to online financial institutions--that access expires every other year for Money and after every three versions for Quicken.
Most folks here knew the idea of "TCO is paid upfront" was disingenuous to say the least, for any software. There's training costs, upgrade costs ("our whole company just had to switch to Office 2007..."), and so forth. This is even true for open-source; just consider the time and energy spent by developers moving to new source control systems, ala CVS -> SVN -> (git,hg,bzr). But here, we also have the great fun of a bald-faced lie! So how many other MS products have explicit obsolescence logic?
How about we stop runnaway spending and reduce the national debt.
Spending on R&D should be expected to have a substantial return on investment. That is, it makes money. This is about reinvesting in ourselves in a way that maintains and enhances US technical and scientific leadership, which has both economic and political implications and benefits. Industry, by design, doesn't have the attention span for basic research or even for a lot of really useful applied work.
Yes. There's also Skim for OS X, which is far and away my favorite PDF reader for any platform. It's actually designed by and for people who really want to read, quickly search, and annotate PDFs.
Here are two of Skim's great features that I'd love to to see in other PDF readers:
Fast search with great presentation. Skim's PDF text search is blazing fast, provides a concise one-hit per line view, as well as thumbnails of the page around the search target on mouse hover. The thumbs are great for quickly winnowing down to the correct hit; you often don't need to even read the text, just the "look" is enough to know you've got the right thing.
The ability to easily spin off small windows frozen to a part of a page -- great for popping open a diagram or other material referenced across multiple pages of a text.
I do believe that Skim relies heavily on various OS X frameworks (e.g. for PDF rendering, Spotlight support for search, etc.). That definitely goes to show the value of providing functionality via general, well-conceived and well-implemented frameworks instead of being wrapped up inside of monolithic applications.
It's a bit depressing how these recent Internet-based "communication technologies" are all centralized. In some sense, this seems to be a natural offshoot of applications springing up on the web -- individual websites are centralized entities by design. It's also about control and monetization, which is good for the service provider... perhaps less so for the user and for reliability/redundancy/etc.
But I also wonder how much the unanswered technical challenges presented by anonymous internet-based attackers hinders development and adoption of new distributed protocols. The last thing anyone wants is another medium for distributing spam, malware, and so on.
So what will these academics predict? Another Facebook? Or another World Wide Web?
Windows XP SP2 and Windows 2000 are due for retirement on 7/13/2010.
As long as Firefox waits until after that date to yank support from non-test code, I don't see a problem.
I disagree. It'd be a waste of resources for Mozilla to commit development and QA resources to supporting platforms that will be within scant months of their retirement date by the time "Firefox.next" is out.
The allegorical rat flees the ship while it is sinking, not afterwards.
"forcing developers to support aged buggy platforms with dropping adoption levels"
There, fixed that for ya. Really, it's disingenuous to whine about there being a user impact when dropping support for these platforms without also acknolwedging the ongoing support cost to Mozilla's finite development and QA resources.
WinOld users will still be free to use Firefox 3.5, and will get updates for a good while. And since the source code is available, users of Win 2000 through XP SP 2 can band together to produce their own updates if so desired.
However, my bet is on no one caring enough to waste the time or energy.
You can do it by paying attention to what your users need, not just what you want. OpenOffice.org may be an acceptable substitute for MS Office apps in your organization. Or, you may hobble the faculty because they're required to submit Word documents for various publications, using Word templates. It's bad enough having to suffer through this in Word, but having to manage this with another layer of indirection sounds utterly intolerable. That situation sucks, but you aren't going to change it by unilateral decree.
Likewise, using the GIMP vs. Photoshop may be great for some of your users. But if they're using features daily in Photoshop that aren't supported in GIMP, soon they'll be GIMP'ing up dartboards with your face on it.
Simply put, users care about applications that meet their needs and organizations should too. If you are truly in a position to influence these decisions, then your responsibility is to understand and meet those needs, not serve your own ideology. Working contrary to users' needs is a terrible way to promote the OSS software cause; you'll make more enemies for OSS than friends.
Here's my take, having used both languages in anger. First off, let me call out a number of similarities between these languages. They're both OO, dynamic, and provide reflection capabilities (useful for meta-programming). They've both been influenced by functional languages. They both have active, vibrant user communities. Both have many open-source and shipping commercial applications that leverage or are fully built on these languages. While there are notable syntactic differences, I find that there's a certain shared "feel" between Python and Ruby.
Now I'll call out the differences I find interesting. Python's import model (akin to #include for you C folk) is stronger than Ruby's require when it comes to larger applications. By "stronger", I mean that it's more explicit and therefore provides greater assurance against unintended effects from referencing a different module/class/object than you intended. This is a two-edged sword, since Ruby's code loading approach is less verbose and affords the construction of tools like Rails' Dependencies module which automatically finds code via a convention-over-configuration model. (e.g. calling require is never needed for the main application code of a Rails application if you just follow the file vs. class naming conventions -- this is *very* handy, IMO.)
I'm big on powerful abstractions in programming languages. On this count, I find that Ruby wins hands down. The Python community has had a muddled approach to some key areas that Ruby had early clarity on via lessons learned from Smalltalk. Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python. Blocks are nothing more or less than anonymous functions, aka "lambdas", but their beauty lies in their syntatic integration. Consider the Ruby iterator pattern: a = [3,4,5] a.each do |x|
puts x end
The do... end construct is a block. a is a Ruby Array object. The conventional iterator method each calls the block once for every element in order, as you'd expect. The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer. Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library: File.open('foo.txt','w') do |f|
f.write(some_content) end This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as: class File
def File.open(name,mode)
file = File.new(name,mode)
if block_given?
begin
yield
ensure
file.close
end
else
return file
end
end end
And the list of uses goes on and on. Blocks are a foundation component that makes Ruby well-suited for writi
>> dd if=/dev/random bs=200 count=1 | tr -c -d 'A-Za-z0-9!@#$%^&*()_+'; echo1+0 records in 1+0 records out 200 bytes transferred in 0.000068 secs (2943371 bytes/sec) tr: Illegal byte sequence
>> printenv LC_CTYPE en_US.UTF-8
>> (export LC_CTYPE=C; dd if=/dev/random bs=200 count=1 | tr -c -d 'A-Za-z0-9!@#$%^&*()_+'; echo) 1+0 records in 1+0 records out 200 bytes transferred in 0.000054 secs (3711773 bytes/sec) ntAzlJkArsfaMJXM^0ugwmhHxGiCZ)HVFg@JN4!HOM3tn&pWQ&pu6g
The default locale values on my US mac are "en_US.UTF-8". Per the tr man page on OS X:
ENVIRONMENT
The LANG, LC_ALL, LC_CTYPE and LC_COLLATE environment variables affect the execution
of tr as described in environ(7).
When LC_CTYPE has a UTF-8 encoding, tr requires that the input byte stream be well-formed UTF-8; not all random byte strings adhere to this. In the working example, I set LC_CTYPE to "C", which one can think of as "binary, with no encoding".
All teachers of programming find that their results display a 'double hump'.
"pretty strong evidence" my ass. First, any claim that this test identifies "innate" ability is nonsense. There's no part of the associated studies which even approaches a "nature" vs "nurture" type result. First clue of no real results: ZERO application of statistical analysis in the paper. This submission would be a big laugh to any serious social sciences forum. A population split is claimed, and a proposed test to identify that split is presented. No claim as to why that split exists is made. (If it exists! The paper far from proves that.)
For example, that data (if correctly gathered, is statistically meaningful, etc.) might simply reference the quality of the mathematics education the students received well prior to taking this CS class. If that were the case, it'd be VERY STRONG reinforcement for the ACM's case. Likewise, such a test might then indicate required remediation for students rather than kicking them out of CS entirely.
E.g. did the students have to really learn long division in school? That's their first exposure to a rigorous CS-style algorithm. How was the student's algebra education? That's the introduction to the abstraction of variables. The computer scientist who doesn't deeply grok abstraction gets precisely nowhere. The list goes on. These are core skills which allow a student to find success in CS work. These can be likened to the "literacy" requirements to comprehend Computer Science topics... are we simply producing "illiterate" students? We don't yet know, and this work, while stimulating, doesn't provide any answers.
Is CS such a basic subject, at the level of science or math, that it makes sense to (try to) teach its principles to every elementary school child?
Yes, inasmuch as understanding the basics of algorithmics and computing provides foundation knowledge that impacts virtually all modern technology. Just as basic science classes serve to provide valuable insights into how the world and various technologies work, so can appropriately structured CS education.
We already teach basic algorithms in math classes, starting with long division. A lot of people (even teachers) have the gross misconception that the utility of long division is solely the result of dividing two numbers. Sadly, the "math is hard"[1] and "why bother, when we have calculators" contingents have been eliminating this important topic from classrooms for years now. But learning long division, i.e. the first algorithm, is a very important step for basic mathematical reasoning much less any CS topics.
[1] Damnable "reform math" proponents should be skewered then roasted on a spit.
Duh, what? Yes, requiring industry to figure out what it's going to dump on us before it does so can be a "burden". So be it. At the same time, it drives innovation into avenues that don't dump pollution on the rest of us. And as more people get into the act, "green" approaches previously not up for consideration are discovered to often yield better results (more efficient, cheaper, etc.). The more baseline work that goes into sustainable industry, the easier it gets for everyone.
Also, take a walk on the other side for a minute -- a friend visited Shanghai a few weeks ago. The air pollution was often so bad that he could barely see a block ahead from the brown haze. Quote, "my lungs feel tanned." Look also at the environmental disaster zone that are the former Soviet states. One Russian I spoke to put it this way: many people there know that excessive smoking and drinking aren't good for their health, but do it anyway out of the belief that it won't really matter because of everything else they're exposed to.
What site is this again?
on
Web Singletons?
·
· Score: 5, Funny
And does anything approach the singular time-wasting abilities of IMDB or Wikipedia?
What, as in "newspeak"? I think not. Orwell put the kibosh on that quite firmly.
As for complaining about the use of the Greek "neo" as a prefix, that horse left the barn at least two hundred years ago. See "neologism", coined in 1803.
Apple recently became famous (or infamous) for stealing other people's ideas when they rolled out their Dashboard in Mac OS X, which had many similarities to a desktop widget program named the Konfabulator, which later became Yahoo widgets.
ScuttleMonkey, you should have scuttled this post! ARRRR!: Someone who bitches about patents, which are intended to limit the free application of certain ideas, then bitching about the free application of ideas in the same breath.
Wow, kids, let's try that template again:
[OSS developers] recently became famous (or infamous) for stealing other people's ideas when they rolled out their [GIMP] in [Linux], which had many similarities to a desktop [...] program named [Photoshop] [...]
Wash, rinse, repeat! It's the hypocrisy generator!
Slashdot Mirror
The summary text is completely misleading vs. the article text. The mosquitoes don't "deliver" a vaccine. A combination technique is used, involving an existing anti-malarial drug and repeated exposure to the parasites via mosquitoes, to cause natural immunity to develop, essentially controlling a known path to malaria immunity. The article indicates this approach isn't usable on a practical scale, yet is important because:
"This is not a vaccine" as in a commercial product, but a way to show how whole parasites can be used like a vaccine to protect against disease, said one of the Dutch researchers, Dr. Robert Sauerwein.
The article does mentions separate work to commercialize a related approach involving weakened malaria parasites.
So little can be done, except power off your iPhone to avoid being hacked
Little can be done... except block such messages entirely at the provider level. When the attack vector is clearly defined, it's easy to scan for it.
Right, all excellent points. Also, I neglected the even more straightforward scenario of internal attackers. Sigh. Note to self: don't reason about computer security before being truly awake. ;-)
People, you're getting your kickers in a twist over a fault that only occurs, per TFA, when:
The exploit can only be used directly from outside your network over the internet if you have enabled remote Web GUI management in the Administration tab.
That is, you not only have to have installed custom firmware on your router, but you have to be sufficiently non-paranoid to have exposed its admin interface to the open Internet. Yes, people should patch it, but really... YAWN.
Sounds like a great new technology but I get frustrated when product seems to take forever to get to market.
It's important to keep perspective on news items like this as "research results" rather than "products." That misunderstanding takes the fun out of a great spectator sport. ;-) Sometimes results out of the lab are immediately applicable, more often they take a quite a number of years to work out the practical kinks. E.g. this recent article on silicon for photo detectors in Tech Review has a good examples of the kinds of problems researchers have to muddle through on the way from breakthrough to reality. It doesn't help that popular tech reporting (and some researchers) love to add 'hooks' of tantalizing applications for new work... but for all those lofty dreams it's still just a research result.
In short, it's best not to hitch one's proverbial horse to any one of these announcements. Instead, read a lot of them to get a good sense of where technology is headed and where academia and industry are investing their efforts.
<video codec="blah"> and let the content providers decide.
You fail to grasp the concept. The browser can only decode video for formats that it has decoder software for. If the content provider sends video in XYZZY format, which no one on Earth has ever heard of before, it's worthless. More to the point, if a content provider sends H.264 (or Theora) to a browser that doesn't support it, it's also worthless. The whole point of the <video> element is to allow content providers to choose one of the always supported formats and therefore know a-priori that it will work in the user's browser. A "choose one from this list" strategy, or creating a new plugin-hell for codecs doesn't accomplish this end.
Theora's hardware support is non-existent
Huh? Theora would have hardware support fired up within three blinks of its ratification as part of HTML5 and the release of browsers supporting it. For many (most? all?) instances, such "hardware" support is often implemented on DSP core(s), not a dedicated ASIC just for a specific codec, making the update just a matter of new firmware for existing systems.
Allowing a "pick one" scenario means that third-party content providers have no freaking clue what format they can present their data in for their users. The worst of all worlds: everyone has to transcode and store video into N different formats, because the industry can't get their ducks aligned...
No, one doesn't need to be utterly self-denying. GP's statement was phased differently by Bill and Ted: "Be excellent to each other." A Slashdotter, however, might require the double-negative form: "don't be an asshat." ;-) Neither of these forms include "to the exclusion of oneself."
Paying attention to one's own needs is basic to the ability to interact with the world in a healthy way. People (and corporations) who deny this tend to get rather screwed up and/or end up playing doormat to others' desires.
In the case of corporations, they DO have a responsibility to the societies that permit them to exist beyond just "the shareholders." This is a stupid fallacy that I'd love to see die. Occasionally, corporations forget this and get smacked down for it -- see the history of laws and legal actions relating to pollution, lemon laws, anti-trust, etc.
Hypocrisy is the essence of pure evil.
No, hyperbole is. ;-)
Reading between Apple's lines here: many of the new features are really developer-facing instead of end-user facing. Of particular note is the category of changes referred to on Apple's Snow Leopard page called "Grand Central" -- focused on driving hard on OS X's support for multi-core software, as well as developer support for multi-core apps. See also the blurb on OpenCL support.
It's an interesting and strategic move to spend resources enabling developers to rapidly produce high-performance applications. Snow Leopard is thus a long-term investment in Apple's OS platform.
Quoth Dr. Cheikh Modibo Diarra:
You buy Microsoft software, and you buy it once and for all, the cost that we tell you is the total cost for ownership.
Now consider Microsoft Money, as reviewed by CNet:
Unfortunately, you'll be forced to upgrade periodically if you rely upon either application's links to online financial institutions--that access expires every other year for Money and after every three versions for Quicken.
Most folks here knew the idea of "TCO is paid upfront" was disingenuous to say the least, for any software. There's training costs, upgrade costs ("our whole company just had to switch to Office 2007..."), and so forth. This is even true for open-source; just consider the time and energy spent by developers moving to new source control systems, ala CVS -> SVN -> (git,hg,bzr). But here, we also have the great fun of a bald-faced lie! So how many other MS products have explicit obsolescence logic?
How about we stop runnaway spending and reduce the national debt.
Spending on R&D should be expected to have a substantial return on investment. That is, it makes money. This is about reinvesting in ourselves in a way that maintains and enhances US technical and scientific leadership, which has both economic and political implications and benefits. Industry, by design, doesn't have the attention span for basic research or even for a lot of really useful applied work.
Yes. There's also Skim for OS X, which is far and away my favorite PDF reader for any platform. It's actually designed by and for people who really want to read, quickly search, and annotate PDFs.
Here are two of Skim's great features that I'd love to to see in other PDF readers:
I do believe that Skim relies heavily on various OS X frameworks (e.g. for PDF rendering, Spotlight support for search, etc.). That definitely goes to show the value of providing functionality via general, well-conceived and well-implemented frameworks instead of being wrapped up inside of monolithic applications.
Didn't that used to be a given?
No. Only in some romanticized version of the past.
It's a bit depressing how these recent Internet-based "communication technologies" are all centralized. In some sense, this seems to be a natural offshoot of applications springing up on the web -- individual websites are centralized entities by design. It's also about control and monetization, which is good for the service provider... perhaps less so for the user and for reliability/redundancy/etc.
But I also wonder how much the unanswered technical challenges presented by anonymous internet-based attackers hinders development and adoption of new distributed protocols. The last thing anyone wants is another medium for distributing spam, malware, and so on.
So what will these academics predict? Another Facebook? Or another World Wide Web?
Windows XP SP2 and Windows 2000 are due for retirement on 7/13/2010.
As long as Firefox waits until after that date to yank support from non-test code, I don't see a problem.
I disagree. It'd be a waste of resources for Mozilla to commit development and QA resources to supporting platforms that will be within scant months of their retirement date by the time "Firefox.next" is out.
The allegorical rat flees the ship while it is sinking, not afterwards.
"forcing developers to support aged buggy platforms with dropping adoption levels"
There, fixed that for ya. Really, it's disingenuous to whine about there being a user impact when dropping support for these platforms without also acknolwedging the ongoing support cost to Mozilla's finite development and QA resources.
WinOld users will still be free to use Firefox 3.5, and will get updates for a good while. And since the source code is available, users of Win 2000 through XP SP 2 can band together to produce their own updates if so desired.
However, my bet is on no one caring enough to waste the time or energy.
You can do it by paying attention to what your users need, not just what you want. OpenOffice.org may be an acceptable substitute for MS Office apps in your organization. Or, you may hobble the faculty because they're required to submit Word documents for various publications, using Word templates. It's bad enough having to suffer through this in Word, but having to manage this with another layer of indirection sounds utterly intolerable. That situation sucks, but you aren't going to change it by unilateral decree.
Likewise, using the GIMP vs. Photoshop may be great for some of your users. But if they're using features daily in Photoshop that aren't supported in GIMP, soon they'll be GIMP'ing up dartboards with your face on it.
Simply put, users care about applications that meet their needs and organizations should too. If you are truly in a position to influence these decisions, then your responsibility is to understand and meet those needs, not serve your own ideology. Working contrary to users' needs is a terrible way to promote the OSS software cause; you'll make more enemies for OSS than friends.
Here's my take, having used both languages in anger. First off, let me call out a number of similarities between these languages. They're both OO, dynamic, and provide reflection capabilities (useful for meta-programming). They've both been influenced by functional languages. They both have active, vibrant user communities. Both have many open-source and shipping commercial applications that leverage or are fully built on these languages. While there are notable syntactic differences, I find that there's a certain shared "feel" between Python and Ruby.
Now I'll call out the differences I find interesting. Python's import model (akin to #include for you C folk) is stronger than Ruby's require when it comes to larger applications. By "stronger", I mean that it's more explicit and therefore provides greater assurance against unintended effects from referencing a different module/class/object than you intended. This is a two-edged sword, since Ruby's code loading approach is less verbose and affords the construction of tools like Rails' Dependencies module which automatically finds code via a convention-over-configuration model. (e.g. calling require is never needed for the main application code of a Rails application if you just follow the file vs. class naming conventions -- this is *very* handy, IMO.)
I'm big on powerful abstractions in programming languages. On this count, I find that Ruby wins hands down. The Python community has had a muddled approach to some key areas that Ruby had early clarity on via lessons learned from Smalltalk. Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python. Blocks are nothing more or less than anonymous functions, aka "lambdas", but their beauty lies in their syntatic integration. Consider the Ruby iterator pattern:
... end construct is a block. a is a Ruby Array object. The conventional iterator method each calls the block once for every element in order, as you'd expect. The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
a = [3,4,5]
a.each do |x|
puts x
end
The do
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer. Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
class File
def File.open(name,mode)
file = File.new(name,mode)
if block_given?
begin
yield
ensure
file.close
end
else
return file
end
end
end
And the list of uses goes on and on. Blocks are a foundation component that makes Ruby well-suited for writi
>> dd if=/dev/random bs=200 count=1 | tr -c -d 'A-Za-z0-9!@#$%^&*()_+'; echo1+0 records in
1+0 records out
200 bytes transferred in 0.000068 secs (2943371 bytes/sec)
tr: Illegal byte sequence
>> printenv LC_CTYPE
en_US.UTF-8
>> (export LC_CTYPE=C; dd if=/dev/random bs=200 count=1 | tr -c -d 'A-Za-z0-9!@#$%^&*()_+'; echo)
1+0 records in
1+0 records out
200 bytes transferred in 0.000054 secs (3711773 bytes/sec)
ntAzlJkArsfaMJXM^0ugwmhHxGiCZ)HVFg@JN4!HOM3tn&pWQ&pu6g
The default locale values on my US mac are "en_US.UTF-8". Per the tr man page on OS X:
ENVIRONMENT
The LANG, LC_ALL, LC_CTYPE and LC_COLLATE environment variables affect the execution
of tr as described in environ(7).
When LC_CTYPE has a UTF-8 encoding, tr requires that the input byte stream be well-formed UTF-8; not all random byte strings adhere to this. In the working example, I set LC_CTYPE to "C", which one can think of as "binary, with no encoding".
From the abstract of the referenced paper:
All teachers of programming find that their results display a 'double hump'.
"pretty strong evidence" my ass. First, any claim that this test identifies "innate" ability is nonsense. There's no part of the associated studies which even approaches a "nature" vs "nurture" type result. First clue of no real results: ZERO application of statistical analysis in the paper. This submission would be a big laugh to any serious social sciences forum. A population split is claimed, and a proposed test to identify that split is presented. No claim as to why that split exists is made. (If it exists! The paper far from proves that.)
For example, that data (if correctly gathered, is statistically meaningful, etc.) might simply reference the quality of the mathematics education the students received well prior to taking this CS class. If that were the case, it'd be VERY STRONG reinforcement for the ACM's case. Likewise, such a test might then indicate required remediation for students rather than kicking them out of CS entirely.
E.g. did the students have to really learn long division in school? That's their first exposure to a rigorous CS-style algorithm. How was the student's algebra education? That's the introduction to the abstraction of variables. The computer scientist who doesn't deeply grok abstraction gets precisely nowhere. The list goes on. These are core skills which allow a student to find success in CS work. These can be likened to the "literacy" requirements to comprehend Computer Science topics... are we simply producing "illiterate" students? We don't yet know, and this work, while stimulating, doesn't provide any answers.
Is CS such a basic subject, at the level of science or math, that it makes sense to (try to) teach its principles to every elementary school child?
Yes, inasmuch as understanding the basics of algorithmics and computing provides foundation knowledge that impacts virtually all modern technology. Just as basic science classes serve to provide valuable insights into how the world and various technologies work, so can appropriately structured CS education.
We already teach basic algorithms in math classes, starting with long division. A lot of people (even teachers) have the gross misconception that the utility of long division is solely the result of dividing two numbers. Sadly, the "math is hard"[1] and "why bother, when we have calculators" contingents have been eliminating this important topic from classrooms for years now. But learning long division, i.e. the first algorithm, is a very important step for basic mathematical reasoning much less any CS topics.
[1] Damnable "reform math" proponents should be skewered then roasted on a spit.
Enivonmental Impact Statement
Duh, what? Yes, requiring industry to figure out what it's going to dump on us before it does so can be a "burden". So be it. At the same time, it drives innovation into avenues that don't dump pollution on the rest of us. And as more people get into the act, "green" approaches previously not up for consideration are discovered to often yield better results (more efficient, cheaper, etc.). The more baseline work that goes into sustainable industry, the easier it gets for everyone.
Also, take a walk on the other side for a minute -- a friend visited Shanghai a few weeks ago. The air pollution was often so bad that he could barely see a block ahead from the brown haze. Quote, "my lungs feel tanned." Look also at the environmental disaster zone that are the former Soviet states. One Russian I spoke to put it this way: many people there know that excessive smoking and drinking aren't good for their health, but do it anyway out of the belief that it won't really matter because of everything else they're exposed to.
And does anything approach the singular time-wasting abilities of IMDB or Wikipedia?
looks up at teh awesome bar (cough).
looks at uid.
sighs.
Just say NEW.
What, as in "newspeak"? I think not. Orwell put the kibosh on that quite firmly.
As for complaining about the use of the Greek "neo" as a prefix, that horse left the barn at least two hundred years ago. See "neologism", coined in 1803.
Apple recently became famous (or infamous) for stealing other people's ideas when they rolled out their Dashboard in Mac OS X, which had many similarities to a desktop widget program named the Konfabulator, which later became Yahoo widgets.
ScuttleMonkey, you should have scuttled this post! ARRRR!: Someone who bitches about patents, which are intended to limit the free application of certain ideas, then bitching about the free application of ideas in the same breath.
Wow, kids, let's try that template again:
[OSS developers] recently became famous (or infamous) for stealing other people's ideas when they rolled out their [GIMP] in [Linux], which had many similarities to a desktop [...] program named [Photoshop] [...]
Wash, rinse, repeat! It's the hypocrisy generator!