Google wrote their own language for parallelism called Sawzall. I'm not sure where they're using it in particular (possibly as a front-end to MapReduce), but they've published some research papers about it.
SUSE was never the distro of choice for free-software coders -- it's always been targeted at enterprise users. The hackers have traditionally used Fedora and Debian. Novell's pact with Microsoft did piss off the FOSS fundamentalists, but they weren't developing on SUSE anyway. This is how old-timer volunteer coders swing.
On the other hand, corporate customers generally kind of like having Microsoft's "protection" for their distro of choice. Novell pays a lot of developers to work on SUSE, too.
The point being: there are coders, and there are fundamentalists, and these are completely orthogonal. The fundamentalists don't contribute to Mono or pay for SLED licenses, but they do write useful code. No distro is an island.
Thanks for adding that. Yes, there are inept people in engineering, as in any other field. Generally the ineptitude goes pretty far up the management chain, as well, for the group to continue releasing inadequate work.
Have any of these situations ended in disaster (yet) that you personally knew of? I'd imagine that if a building does spontaneously collapse in a flaming wreckage, lawsuits would be launched against every company involved, and the suits against the engineering firm that designed it and the contractor that build it would be most likely to succeed. The employees of those companies wouldn't be personally liable, except possibly a top executive or two. Right? That's kind of the point of incorporating, as I understand it.
Designing to code generally implies that the structure will be safe, so an unsafe structure (e.g. Tacoma Bridge) that was built to code would not be a liability for the engineering firm that built it. Failure to meet code is what would make them liable, not just the consequences of it.
I assume you've crawled through Wikipedia already -- they break it down pretty well. Also, remember that a startup can be anything, not just a specific kind of work like you've seen in school. It's common in the biotech industry to make your career out of a string of startups; you'll get a pike of options from each, and most won't go anywhere, but one or two probably will, and you can benefit from that even after you've left.
The question is for 2-4 years out -- after grad school -- not right now. Computational biology and bioinformatics are unusual undergraduate degrees, so CompSci -> CompBio sounds pretty sane. Since it's such a new field, there's room for experimentation in the graduate programs to prepare for different career styles -- not even the professors will know all the possibilities. Granted, tossing the question out to Slashdotters instead is kind of a Hail Mary...
Of course it will. Java is huge in high-performance computing, oddly enough. The old-timers like using Fortran, C and C++, but only because they associate that with performance psychologically. Java's thread support wins on distributed-memory systems with large numbers of processors -- not as much as languages actually designed for parallelism, but better than C++ by a long shot.
It hits "good enough" on enough of these points -- familiarity, memory safety, concurrency support, comprehensive library, ubiquitous VM that lets hotshots run a better language (e.g. Scala or Clojure) on top of it -- that Java's probably the best bet for enterprise supercomputing.
Same here. I've also been reading the headlines via RSS first, and almost all of them have been clearly flamebait lately, so I don't bother looking at the comments on those. Still not sure what the root cause is, but maybe flamebait headlines -> pointless, reactionary comments -> bored mods -> editors see site traffic dropping and post even flamier headlines.
Or else the regular mods are rebelling against the new discussion system. I like the inline posting concept but the implementation is hella slow.
Good call. This means that Adobe (and the pile of hardware and media companies listed in the press release) are no longer afraid of Microsoft. It's actually kind of similar to Sun's finally GPL-ing Java, versus.NET.
Since the rc1 of Firefox is due before the end of this month and the final release is due around June 1, it won't be too long before the stable version is in the repositories.
Most big organizations wait much longer than a month before trying a major upgrade like this.
Canonical was considering releasing a sort of "SP1" disk in early July, which would be the same as an up-to-date Hardy installation at that time. That disk would have the fully baked Firefox 3.
Firefox 2 will be deprecated before Hardy's long-term support ends, so FF3 needs to be available in the main distribution.
In case of emergency, Firefox 2 is still easily available from the main repository.
Firefox 3 is actually a really good browser; for instance, the GUI it uses native Gnome widgets, making Ubuntu look much better and more integrated. Compiz is sketchy too, so we've seen that Canonical will accept a little instability in a desktop app if it's something a typical Ubuntu user would want anyway.
IMHO, Mozilla's combination of long development times and short support for older releases is acceptable on Windows, where users manually upgrade whenever a new release comes out, but causes problems for Linux distros that include it through a package manager.
It looked to me like the actual "news" in the article was that Red Hat is taking another shot at providing a cheap, consumer-level desktop for rapidly developing markets (BRIC). But dealing with the consumer PC market, resellers, licensing codecs, etc. delayed it -- "the desktop business model is tough", as they say.
The RHEL/Fedora combination is nothing new, though; the headline is just a troll.
Here's what the article says:
Considering our goals listed above, our desktop product plans for 2008 and 2009 include:
* Red Hat Enterprise Linux Desktop. This is our fully supported, commercial product. It is 100 percent compatible with the Red Hat Enterprise Linux server products. Its focus is to provide a desktop environment that is secure and easily managed. And it is upgradeable with the Multi-OS option (which provides virtualization support) or the Workstation option (which provides high-end workstation capabilities).
* Fedora. This is a Red Hat sponsored, fast-growing, free product. While Red Hat doesn't formally support Fedora, users can turn to a healthy online community to obtain help when they need it.
* Red Hat Global Desktop (RHGD). Plans for this product were originally announced at the 2007 Summit Conference. It is designed exclusively for small, reseller supplied, deployments in emerging markets (e.g. primarily the BRIC countries), and will be supplied by a number of Intel channel partners.
We originally hoped to deliver RHGD within a few months, and indeed the technology side of the product is complete. There have, however, been a number of business issues that have conspired to delay the product for almost a year. These include hardware and market changes, startup delays with resellers, getting the design and delivery of appropriate services nailed down and, unsurprisingly, some multimedia codec licensing knotholes. Right now we are still working our way through these issues. As mentioned earlier, the desktop business model is tough, so we want to be prepared before delivering a product to the emerging markets. This means that, as you probably expected, Red Hat is focusing their for-sale desktop on the enterprise market, and letting the consumer market use the free, unsupported Fedora for now. The "tough" comment was about a new low-cost consumer offering outside the U.S.
The headline should be: "Red Hat Delays Low-Cost Consumer Desktop, Says Business Model Is Tough".
This was released today. The releases on this and OMS don't mention each other by name, but I think it's pretty clear what they're planning to do with the finished media stack.
Agreed, although the net profit calculation is a little hard to explain to you boss when the only benefit is employee happiness. If (e.g.) I can get my job done without Cygwin but having it would be a little beam of sunshine in my work environment, depriving me of it might notch up my activity level on Monster/CareerBuilder. But obviously all I can say to my boss is, "It would mean a lot to me," and hope the message gets across. Personally, I usually strike up a conversation with someone in IT before asking my boss to intervene -- if there's a real risk I'm not aware of, I'd like to learn about that, and then I'll probably let the idea go willingly.
Yep, that's the problem -- the boundaries can never be totally clear-cut. Any journalist worth their salt will ask a person how they want to be identified for a story, even when it would be pretty easy to guess. Is "person of color" an accurate term? The only way to know is to ask the person you're referring to. And the connotations of demographic terminology are always changing; see "United Negro College Fund" and "National Association for the Advancement of Colored People". Even the preference "American Indian" versus "Native American" varies with who you're talking to. Social change is reflected in the language.
But there's no need to walk on eggshells as long as everyone realizes demographic categorization is mostly edge cases. I guess you could say, use tagging instead of a hierarchy. The tags "black", "brown" and "white" make perfect sense for a passing reference to skin color, but to talk about American racial politics/sociology (as in TFA) you might need a keyword like "African-American" or "Latino". And of course, ask before you tag someone personally.
Fact: Black activists in the 1960s started calling themselves "African-American" instead of Negro in order to connect their fight for civil rights to the various independence movements in Africa happening at the same time. It caught on more over time. Malcolm X noted the term in his autobiography.
Not only that, but any startup that's built with this infrastructure would be incredibly easy for Google to buy and integrate if they become successful. If YouTube had been built with this, it would have been a drop-in replacement for Google Video. Or even better, Writely, kicking off Google's semi-recent bid for the Enterprisey market. For Google, any new online Office-style productivity apps that spring up and happen to be built with this framework will look like a Christmas present with a bow on it.
From today's WSJ:
"A recession is possible," Mr. Bernanke told a congressional committee Wednesday, citing turmoil in the housing and credit markets. He added, "We're slightly growing at the moment, but we think that there's a chance that for the first half as a whole there might be a slight contraction." [...] Many private-sector economists, who often define a recession as two straight quarters of economic contraction, have been saying for weeks that the U.S. is either on the verge of a recession or already in one. Generally, we're never sure whether a period of time was a recession until it's already happened. But the Fed and White House have been rightfully phobic of discussing it, and the mainstream media were actually slower to catch onto recession fears than serious economists. Recession is a serious possibility, and speculating about it online does not warrant a reaction involving the caps-lock key. The more open the discussion, the better, in my opinion.
This is getting a little out of context. When Google started saying "Don't be Evil (TM)" internally, it was pretty obvious to anyone in Silicon Valley what that meant. Don't Be Microsoft. More specifically, don't create artificial lock-in for their platform. And so, they don't. It was probably part of the original corporate philosophy that openness and trustworthiness* would allow them to create a product that (1) would succeed, and (2) a lock-in-obsessed competitor would be inherently unable to match.
Yahoo never really thought the same way; their philosophy was more like "Don't get crushed by Evil (with all due respect to Evil)". It didn't quite occur to them that doing the Internet the same way software was always done could be a weakness. They made/bought some good products, whored their brand out, and occasionally stumbled across openness and compatibility. It didn't have the same focus as explicitly stating that Microsoft's approach was the wrong way to do the Web.
[* "If I commit to your platform, how do I know you won't screw me later on?" If you're not locked into a system, you don't have to trust the provider nearly as much.]
Presumably because they thought this might happen. OpenOffice already supports pretty much every format under the sun, so deliberately ignoring OOXML would be obvious, petty, and somewhat self-destructive.
It would be a lock-in tactic, and open-source software isn't really capable of that: If there was demand for OOXML import/export, and Sun didn't implement it, someone else would write an extension for it anyway (or worse, fork the whole project). If organizations are going to ask for OOXML support (if only to handle the stray.docx file that comes from outside), then it's better to have OOo support it competently than require an extension that does it poorly.
Good call. I remember Google trying to do some VLC-based thing to portably embed videos, but eventually giving up and going with Flash for Google Video. Then they realized they were just playing catch-up with YouTube and did the logical thing.
Which makes it even more disappointing that Ogg Theora didn't make it into the HTML5 spec. There still isn't a good, portable way to do video in a browser without relying on plugins.
And then there's the confusion of "parallelism" versus "concurrency".
I think when industry folks talk about parallel computing as an area for growth, they first mean finding foolproof ways to automatically dice up sections of imperative code for parallel computation, in order to make better use of multiple cores. The problem they're trying to solve is taking a mountain of existing C++ or Java code and coaxing it into using all the hardware available. New programming languages can make it easier, and so can MPI et al, but that still puts a huge burden on software companies with existing sequentially-coded apps to support. So, we're seeing OpenMP, Threading Building Blocks, etc. to make that part easier, and presumably there's a lot more room for improvement and even entrepreneurship.
As for offering a nicely packaged HPC product to consumers, I don't have any idea of how you'd do do/market that -- perhaps the author of TFA does, and that's why he has a startup company and I don't. But maybe the idea is to actually blur the distinction between real HPC and behind-the-scenes multi-processor computation on networked consumer/business machines. We'll see...
Javascript is good to know for web stuff. Greasemonkey on Firefox is a fun way to try it out -- save yourself the time of building a web page to manipulate by manipulating other people's pages instead. Since you already know Python and a bit of C++, the Javascript interpreter in Firefox should be very easy for you to pick up and start using. I found the small O'Reilly pocket reference to be helpful.
Try playing with Swig, too. Maybe use it to wrap someone else's code, as a way to get more comfortable with using C alongside Python. It may come in handy if you ever do have a problem with a bottleneck in your programs.
If you're working with some form of Unix, you'll become several levels more wizardly if you put some time into really learning Bash (or your shell of choice). The syntax isn't pretty, but it's essentially using Unix as the back-end for your interpreter, so while you're at it you'll learn a lot about how Unix works, how C is intended to work, and where Python gets some of its ideas about the os and subprocess modules. There are situations where a shell script can get the job done even more effectively than a Python script -- for example, Python generally chooses a portable subset of filesystem operations, where a shell command with the right options might let you do what you want more precisely, with fewer separate checks and followup operations. They might not look like "this needs bash" situations until you're aware of which things bash makes easy.
It doesn't have Lisp-style macros, but it does have eval, lambda (a.k.a. function), map, etc. Functions are first-class values. Typing is dynamic, with optional static declarations and a variety of exciting scoping declarations. Closures work. Last I heard, call-with-current-continuation will not be available per se, but there will be a nice range of flow-control constructs. Maybe continuations and coroutines; not sure. History: Javascript was originally written by Lisp hackers.
This review didn't specify whether Head First is written for Javascript 1.7 or the upcoming 2.0 (ECMAScript 4.0), which annoys me, as the latter is much more exciting. I'm pretty much holding out on really delving into Javascript until v2.0 is released... that seems to be the point where the designers really got it "right".
The two noncommercial standalone interpreters I'm aware of are SpiderMonkey and Rhino. Unfortunately the urge to use Python for any productive scripting is too much for me to resist, so I've mainly played with Javascript via Greasemonkey scripts. There, I found it to be about as easy to use as Python, but with everything slightly kludgier (e.g. "Foo".toLower() instead of "Foo".lower()).
Seems like most of the low-hanging fruit is in frameworks for connecting business rules to a database with the usual CRUD operations. IIRC, Zope formed out of this sort of need for reusable components for customized content-management systems.
I think the holy grail would be a standard mini-language or set of mini-languages for business logic, which specialized open-source frameworks could be developed for. (Maybe Ruby on Rails gets partway there, at least on the database/CRUD side.) Every business wants its domain experts to be able to put a set of rules into a spreadsheet or simple pseudocode, plug that into some well-tested software framework, and run it. Then the rest is IT setup, which is the kind of work software alone can't eliminate (and which, incidentally, probably accounts for a lot of Red Hat's support fees).
Slashdot Mirror
Google wrote their own language for parallelism called Sawzall. I'm not sure where they're using it in particular (possibly as a front-end to MapReduce), but they've published some research papers about it.
SUSE was never the distro of choice for free-software coders -- it's always been targeted at enterprise users. The hackers have traditionally used Fedora and Debian. Novell's pact with Microsoft did piss off the FOSS fundamentalists, but they weren't developing on SUSE anyway. This is how old-timer volunteer coders swing.
On the other hand, corporate customers generally kind of like having Microsoft's "protection" for their distro of choice. Novell pays a lot of developers to work on SUSE, too.
The point being: there are coders, and there are fundamentalists, and these are completely orthogonal. The fundamentalists don't contribute to Mono or pay for SLED licenses, but they do write useful code. No distro is an island.
Thanks for adding that. Yes, there are inept people in engineering, as in any other field. Generally the ineptitude goes pretty far up the management chain, as well, for the group to continue releasing inadequate work.
Have any of these situations ended in disaster (yet) that you personally knew of? I'd imagine that if a building does spontaneously collapse in a flaming wreckage, lawsuits would be launched against every company involved, and the suits against the engineering firm that designed it and the contractor that build it would be most likely to succeed. The employees of those companies wouldn't be personally liable, except possibly a top executive or two. Right? That's kind of the point of incorporating, as I understand it.
Designing to code generally implies that the structure will be safe, so an unsafe structure (e.g. Tacoma Bridge) that was built to code would not be a liability for the engineering firm that built it. Failure to meet code is what would make them liable, not just the consequences of it.
Here are some resources that might help you out.
Overview of the field:
http://bioinformatics.sdsu.edu/education.htm
News:
http://news.thinkgene.com/
http://www.bioinformatics.org/
Org:
http://www.iscb.org/
I assume you've crawled through Wikipedia already -- they break it down pretty well. Also, remember that a startup can be anything, not just a specific kind of work like you've seen in school. It's common in the biotech industry to make your career out of a string of startups; you'll get a pike of options from each, and most won't go anywhere, but one or two probably will, and you can benefit from that even after you've left.
The question is for 2-4 years out -- after grad school -- not right now. Computational biology and bioinformatics are unusual undergraduate degrees, so CompSci -> CompBio sounds pretty sane. Since it's such a new field, there's room for experimentation in the graduate programs to prepare for different career styles -- not even the professors will know all the possibilities. Granted, tossing the question out to Slashdotters instead is kind of a Hail Mary...
Of course it will. Java is huge in high-performance computing, oddly enough. The old-timers like using Fortran, C and C++, but only because they associate that with performance psychologically. Java's thread support wins on distributed-memory systems with large numbers of processors -- not as much as languages actually designed for parallelism, but better than C++ by a long shot.
It hits "good enough" on enough of these points -- familiarity, memory safety, concurrency support, comprehensive library, ubiquitous VM that lets hotshots run a better language (e.g. Scala or Clojure) on top of it -- that Java's probably the best bet for enterprise supercomputing.
Same here. I've also been reading the headlines via RSS first, and almost all of them have been clearly flamebait lately, so I don't bother looking at the comments on those. Still not sure what the root cause is, but maybe flamebait headlines -> pointless, reactionary comments -> bored mods -> editors see site traffic dropping and post even flamier headlines.
Or else the regular mods are rebelling against the new discussion system. I like the inline posting concept but the implementation is hella slow.
Good call. This means that Adobe (and the pile of hardware and media companies listed in the press release) are no longer afraid of Microsoft. It's actually kind of similar to Sun's finally GPL-ing Java, versus .NET.
IMHO, Mozilla's combination of long development times and short support for older releases is acceptable on Windows, where users manually upgrade whenever a new release comes out, but causes problems for Linux distros that include it through a package manager.
It looked to me like the actual "news" in the article was that Red Hat is taking another shot at providing a cheap, consumer-level desktop for rapidly developing markets (BRIC). But dealing with the consumer PC market, resellers, licensing codecs, etc. delayed it -- "the desktop business model is tough", as they say.
The RHEL/Fedora combination is nothing new, though; the headline is just a troll.
* Red Hat Enterprise Linux Desktop. This is our fully supported, commercial product. It is 100 percent compatible with the Red Hat Enterprise Linux server products. Its focus is to provide a desktop environment that is secure and easily managed. And it is upgradeable with the Multi-OS option (which provides virtualization support) or the Workstation option (which provides high-end workstation capabilities).
* Fedora. This is a Red Hat sponsored, fast-growing, free product. While Red Hat doesn't formally support Fedora, users can turn to a healthy online community to obtain help when they need it.
* Red Hat Global Desktop (RHGD). Plans for this product were originally announced at the 2007 Summit Conference. It is designed exclusively for small, reseller supplied, deployments in emerging markets (e.g. primarily the BRIC countries), and will be supplied by a number of Intel channel partners.
We originally hoped to deliver RHGD within a few months, and indeed the technology side of the product is complete. There have, however, been a number of business issues that have conspired to delay the product for almost a year. These include hardware and market changes, startup delays with resellers, getting the design and delivery of appropriate services nailed down and, unsurprisingly, some multimedia codec licensing knotholes. Right now we are still working our way through these issues. As mentioned earlier, the desktop business model is tough, so we want to be prepared before delivering a product to the emerging markets. This means that, as you probably expected, Red Hat is focusing their for-sale desktop on the enterprise market, and letting the consumer market use the free, unsupported Fedora for now. The "tough" comment was about a new low-cost consumer offering outside the U.S.
The headline should be: "Red Hat Delays Low-Cost Consumer Desktop, Says Business Model Is Tough".
I was curious too, so I looked on Google Finance. Most of their visible activity does seem to be dedicated to blogging and thwarting Microsoft, pretty much like IBM -- big iron and enterprisey stuff. But actually, the financial headlines do a much better job than sun.com at explaining how they make money. Here's a press release from today:
Sun Expands Sun Streaming System to Deliver Industry's Most Scalable and Flexible Video Delivery Over IP Platform
This was released today. The releases on this and OMS don't mention each other by name, but I think it's pretty clear what they're planning to do with the finished media stack.
Good links. The HP Linux stuff is amazingly hard to find on their site, but it's there:
http://h71028.www7.hp.com/enterprise/cache/321152-0-0-0-121.html
Lenovo is easier to find:
www.lenovo.com/think/linux
EmperorLinux.com is popular, too.
Agreed, although the net profit calculation is a little hard to explain to you boss when the only benefit is employee happiness. If (e.g.) I can get my job done without Cygwin but having it would be a little beam of sunshine in my work environment, depriving me of it might notch up my activity level on Monster/CareerBuilder. But obviously all I can say to my boss is, "It would mean a lot to me," and hope the message gets across. Personally, I usually strike up a conversation with someone in IT before asking my boss to intervene -- if there's a real risk I'm not aware of, I'd like to learn about that, and then I'll probably let the idea go willingly.
Yep, that's the problem -- the boundaries can never be totally clear-cut. Any journalist worth their salt will ask a person how they want to be identified for a story, even when it would be pretty easy to guess. Is "person of color" an accurate term? The only way to know is to ask the person you're referring to. And the connotations of demographic terminology are always changing; see "United Negro College Fund" and "National Association for the Advancement of Colored People". Even the preference "American Indian" versus "Native American" varies with who you're talking to. Social change is reflected in the language.
But there's no need to walk on eggshells as long as everyone realizes demographic categorization is mostly edge cases. I guess you could say, use tagging instead of a hierarchy. The tags "black", "brown" and "white" make perfect sense for a passing reference to skin color, but to talk about American racial politics/sociology (as in TFA) you might need a keyword like "African-American" or "Latino". And of course, ask before you tag someone personally.
Fact: Black activists in the 1960s started calling themselves "African-American" instead of Negro in order to connect their fight for civil rights to the various independence movements in Africa happening at the same time. It caught on more over time. Malcolm X noted the term in his autobiography.
The term "African-American"
Not only that, but any startup that's built with this infrastructure would be incredibly easy for Google to buy and integrate if they become successful. If YouTube had been built with this, it would have been a drop-in replacement for Google Video. Or even better, Writely, kicking off Google's semi-recent bid for the Enterprisey market. For Google, any new online Office-style productivity apps that spring up and happen to be built with this framework will look like a Christmas present with a bow on it.
[...]
Many private-sector economists, who often define a recession as two straight quarters of economic contraction, have been saying for weeks that the U.S. is either on the verge of a recession or already in one. Generally, we're never sure whether a period of time was a recession until it's already happened. But the Fed and White House have been rightfully phobic of discussing it, and the mainstream media were actually slower to catch onto recession fears than serious economists. Recession is a serious possibility, and speculating about it online does not warrant a reaction involving the caps-lock key. The more open the discussion, the better, in my opinion.
This is getting a little out of context. When Google started saying "Don't be Evil (TM)" internally, it was pretty obvious to anyone in Silicon Valley what that meant. Don't Be Microsoft. More specifically, don't create artificial lock-in for their platform. And so, they don't. It was probably part of the original corporate philosophy that openness and trustworthiness* would allow them to create a product that (1) would succeed, and (2) a lock-in-obsessed competitor would be inherently unable to match.
Yahoo never really thought the same way; their philosophy was more like "Don't get crushed by Evil (with all due respect to Evil)". It didn't quite occur to them that doing the Internet the same way software was always done could be a weakness. They made/bought some good products, whored their brand out, and occasionally stumbled across openness and compatibility. It didn't have the same focus as explicitly stating that Microsoft's approach was the wrong way to do the Web.
[* "If I commit to your platform, how do I know you won't screw me later on?" If you're not locked into a system, you don't have to trust the provider nearly as much.]
Presumably because they thought this might happen. OpenOffice already supports pretty much every format under the sun, so deliberately ignoring OOXML would be obvious, petty, and somewhat self-destructive.
.docx file that comes from outside), then it's better to have OOo support it competently than require an extension that does it poorly.
It would be a lock-in tactic, and open-source software isn't really capable of that: If there was demand for OOXML import/export, and Sun didn't implement it, someone else would write an extension for it anyway (or worse, fork the whole project). If organizations are going to ask for OOXML support (if only to handle the stray
Good call. I remember Google trying to do some VLC-based thing to portably embed videos, but eventually giving up and going with Flash for Google Video. Then they realized they were just playing catch-up with YouTube and did the logical thing.
Which makes it even more disappointing that Ogg Theora didn't make it into the HTML5 spec. There still isn't a good, portable way to do video in a browser without relying on plugins.
And then there's the confusion of "parallelism" versus "concurrency".
I think when industry folks talk about parallel computing as an area for growth, they first mean finding foolproof ways to automatically dice up sections of imperative code for parallel computation, in order to make better use of multiple cores. The problem they're trying to solve is taking a mountain of existing C++ or Java code and coaxing it into using all the hardware available. New programming languages can make it easier, and so can MPI et al, but that still puts a huge burden on software companies with existing sequentially-coded apps to support. So, we're seeing OpenMP, Threading Building Blocks, etc. to make that part easier, and presumably there's a lot more room for improvement and even entrepreneurship.
As for offering a nicely packaged HPC product to consumers, I don't have any idea of how you'd do do/market that -- perhaps the author of TFA does, and that's why he has a startup company and I don't. But maybe the idea is to actually blur the distinction between real HPC and behind-the-scenes multi-processor computation on networked consumer/business machines. We'll see...
Javascript is good to know for web stuff. Greasemonkey on Firefox is a fun way to try it out -- save yourself the time of building a web page to manipulate by manipulating other people's pages instead. Since you already know Python and a bit of C++, the Javascript interpreter in Firefox should be very easy for you to pick up and start using. I found the small O'Reilly pocket reference to be helpful.
Try playing with Swig, too. Maybe use it to wrap someone else's code, as a way to get more comfortable with using C alongside Python. It may come in handy if you ever do have a problem with a bottleneck in your programs.
If you're working with some form of Unix, you'll become several levels more wizardly if you put some time into really learning Bash (or your shell of choice). The syntax isn't pretty, but it's essentially using Unix as the back-end for your interpreter, so while you're at it you'll learn a lot about how Unix works, how C is intended to work, and where Python gets some of its ideas about the os and subprocess modules. There are situations where a shell script can get the job done even more effectively than a Python script -- for example, Python generally chooses a portable subset of filesystem operations, where a shell command with the right options might let you do what you want more precisely, with fewer separate checks and followup operations. They might not look like "this needs bash" situations until you're aware of which things bash makes easy.
It doesn't have Lisp-style macros, but it does have eval, lambda (a.k.a. function), map, etc. Functions are first-class values. Typing is dynamic, with optional static declarations and a variety of exciting scoping declarations. Closures work. Last I heard, call-with-current-continuation will not be available per se, but there will be a nice range of flow-control constructs. Maybe continuations and coroutines; not sure. History: Javascript was originally written by Lisp hackers.
This review didn't specify whether Head First is written for Javascript 1.7 or the upcoming 2.0 (ECMAScript 4.0), which annoys me, as the latter is much more exciting. I'm pretty much holding out on really delving into Javascript until v2.0 is released... that seems to be the point where the designers really got it "right".
The two noncommercial standalone interpreters I'm aware of are SpiderMonkey and Rhino. Unfortunately the urge to use Python for any productive scripting is too much for me to resist, so I've mainly played with Javascript via Greasemonkey scripts. There, I found it to be about as easy to use as Python, but with everything slightly kludgier (e.g. "Foo".toLower() instead of "Foo".lower()).
Seems like most of the low-hanging fruit is in frameworks for connecting business rules to a database with the usual CRUD operations. IIRC, Zope formed out of this sort of need for reusable components for customized content-management systems.
I think the holy grail would be a standard mini-language or set of mini-languages for business logic, which specialized open-source frameworks could be developed for. (Maybe Ruby on Rails gets partway there, at least on the database/CRUD side.) Every business wants its domain experts to be able to put a set of rules into a spreadsheet or simple pseudocode, plug that into some well-tested software framework, and run it. Then the rest is IT setup, which is the kind of work software alone can't eliminate (and which, incidentally, probably accounts for a lot of Red Hat's support fees).