Uhm, it does in fact cost money to post job ads on Craigslist. See http://www.craigslist.org/abou... . It's one of their major sources of money, along with hooker ads (oops, "therapeutic services", my bad).
Why you would do so, however, eludes me. As with the poster above, at multiple employers that have tested the Craigslist waters we've never had anybody remotely qualified respond to one of our Craigslist ads. They're just pocket change compared to Dice.com or compared to paying a recruiter's fee, so it was a "why not?". But every one of our hires seems to have been either a personal referral from a current employee, or a recruiter lured them away from another company.
Manual? What is that? Paper service manuals have gone the way of buggy whips in the auto service industry. Nobody publishes them anymore except maybe General Motors. It's all regularly-updated computer-based manuals for everybody else. Independents use Alldata, which gets updates on a regular basis from manufacturers, and dealerships use their manufacturer's computer system that does the same thing (such as Chrysler TechAuthority). For most newer cars if you are an end user who wants factory service info you go to AlldataDIY.com because paper service manuals are no longer published. For parts lists it's even simpler, you don't have to pay Alldata, the modern mechanic goes to the manufacturer's web site like Mopar.com or to some third party vendors which similarly give access to the manufacturer parts database and look up the part number there. If you pull an old part and put the part number off of it into the parts site search box, the computer will say "Superseded by" and give you the new part number. If there's no part number on the part, you drill down the assemblies list on the parts site until you see the labeled picture with your part on it, and the current part number will be in the list beneath that illustration.
And of course if you go to the dealership parts window, they put in the old part number into their computer, it says "superseded by part XYYZ", and they give you part XYYZ instead.
This is the 21st century. We have these COMPUTER thingies now. Just sayin'. There's no longer an excuse to *not* change the part number when the part has, in fact, changed. And I know for a fact that several part numbers on my Jeep have changed multiple times since it was manufactured in 2011. Which is why any modern automotive engineer has to be suspicious when GM did not change the part number on that ignition switch when, in fact, it's an entirely redesigned ignition switch...
Which, in combination with $1, will buy you a cup of coffee. I haven't noticed that Eastern European or Chinese spammers and attackers have been deterred one whit by those bilateral trade agreements.
Spammers definitely will *not* get a whole Amazon netblock blacklisted. Amazon firewalls outgoing port 25 traffic. If you want to send email from AWS you need to bounce it via authenticated port 465 or 537 through a mail service on some other ISP.
I'm not quite sure what you're talking about. Auto-scaling groups are the only thing that can restart a terminated instance (actually, they start a *new* instance). If you somehow managed to create an auto-scaling group and don't know how to set its parameters (min/max/desired) down to zero, when it's right there on the GUI, I don't know what to tell you.
Nobody really writes new applications in it, but there's a bajillion Java applications running most major corporations now the way COBOL used to in the old days.
That said, when looking for an engineer I'm not looking for someone who knows Java (even though that's what a lot of our product is written in). I'm looking for someone who understands computational complexity, is familiar with common algorithms and data structures, and has some notion of object oriented programming and software engineering. Anybody who's written a lot of code can pick up Java fairly swiftly at least to the "getting s**t done" stage, it took me roughly a week to do so ("oh, so it's like Python with C++ syntax, except with only single inheritance and with templates!"), but if you don't understand the why of what you're doing, you're not going to do well in our shop.
So: Get a computer science degree. Or at least significant computer science coursework. And not from Joe's Plumbing and Programming School, get one from some place that teaches actual computer science, not programming. Either that, or write some Open Source applications and contribute to the Linux kernel. Nobody cares what school you went to if you can write Linux drivers, all they care about is that you know the difference between a BIO and an SK_BUF. But they want to see your name in the Linux changelogs first.
A company which sells a solution at a higher price than other companies because of a higher cost of developing the software is soon to be an ex-company.
You're talking technology. But technology does not determine whether a company stays in business. Delivering in a timely manner a solution that works well enough for a cost equal to or less than the competition is what determines whether a company stays in business. There's a large number of application areas where Windows is what allows that. Luckily that's not *every* industry, or else I would have problems. (Disclaimer: I have been writing commercial software for Linux since 1996, yep, 18 years now).
My brother works in the SCADA industry. All of their stuff is Windows, mostly Windows XP Embedded. Why? Simple. It's the tools. There are various toolkits out there that make building a SCADA application almost drag-and-drop. It'd take four times as many people twice as long to hack all that up in C or C++ under Linux. And they simply don't sell enough SCADA systems to justify that kind of effort -- it's a crowded market where no single vendor manages to sell more than a few hundred instances of any particular model, so per-unit development cost difference between Windows and Linux far outweighs the OS cost difference.
As for why SCADA toolchain vendors don't port their tools to Linux, usually their tools are a large array of components from various vendors strung together with DCOM. Distributed SCADA systems in particular are heavily invested in Microsoft's DCOM OPC for communications between SCADA components such as pipeline pressure monitors, valve position sensors, billing stations, and operational monitoring stations. Linux doesn't support DCOM OPC as such, or any equivalent to it, with any standard libraries though there are emulators that may or may not work. The industry standardized on DCOM OPC for practical reasons -- it existed at the time they started doing all this (back in Windows NT days) while nothing like it existed on Linux back then, and they can write binary components that work pretty much on any Windows system, as versus with Linux where the distributions are not binary compatible and where five year old binaries will rarely run on a modern Linux system. Linux is great when you're selling a whole solution from top to bottom, but if you're trying to sell commercial software to SCADA system developers, Linux presents significant practical difficulties compared to WIndows. So there simply is no incentive to move off of Windows even though they're likely going to now be targeting later embedded Windows versions rather than embedded XP.
I'm not up on ATM's. But it would surprise me if ATM developers did not in fact use similar tools to create their product -- tools that are Windows-centric not because of Linux hatred, but because of history and the practical problems of trying to sell binary-blob commercial software on Linux (which is a task akin to nailing jelly to a tree).
H1B visas *can* be transferred, but it's a major annoyance. One of our H1B's was "officially" still on the payroll of the parent company after our division was split off as a separate company. This annoyed our former parent company greatly, since they had to pay him then bill us for his pay and benefits, but part of the divestment agreement called for them to do that for him until we could get the visa transferred. It took roughly six months to get the visa transferred:(.
BTW, the United States is not the world. For example, the UK likes to poach the best and brightest H1B's from the US, I know three Indians formerly in the US on H1B's who've ended up in London. Canada also loves Indian immigrants who have a computer science degree and five years of work experience in computer fields, they put such immigrants on a fast track to a work permit and citizenship since they're perceived as having valuable skills and as being easy to assimilate. The notion that the H1B's only have a choice of India and the US as places to work is a false one. The US is still a major draw but if the US mistreats immigrants, they'll go elsewhere and the US will basically have spent a small fortune training them up for the UK, Canada, and other nations to get the advantage of such training.
Often the lowest-paid H1B's, the ones working for contracting companies like Tata, are stacked in communal apartments. One 1-bedroom apartment I visited had eight people living in it, they slept on futon mattresses thrown on the floor of the living room and bedroom and eat communally in the kitchen/dining area (there are multiple Indian grocers within walking distance of that apartment complex so it is easy to get cheap eats, though they tend to not be good cooks -- I almost swore off of Indian food after tasting a sample!). They rarely have cars, they rely on mass transit or employer bus to get to work. I drive by a bus stop every morning that has two dozen H1B's waiting for the bus so they can get to Cisco where they work. (I know it's Cisco because they have various Cisco-related stickers, binders, backpacks, etc. as well as Cisco badges that serve as their bus fare due to a special agreement Cisco made with the local transit authority).
Then there are the H1B's who are here because other work visas are too expensive, but otherwise are just normal employees. Several of my co-workers at my last company were H1B's. They had been working in the India office of the company when the India office was closed down as the company downsized, but were critical employees (they'd "owned" major parts of the technology as engineers and basically were irreplaceable due to their institutional knowledge of the innards of the technology) so were brought over on H1B. There needs to be a better way of handling that kind of thing other than the H1B with all its limitations and restrictions, but right now there really isn't, not unless your name is Linus Torvalds and you're brought in on a "genius" visa. We were always nervous when one of them went back home on vacation as to whether they'd be able to get back into the country. We endured the legal nightmare that was their work visa because they really were that important to our company. I presume they were paid accordingly.
In general I have no problem with the notion that it's a good idea to have work visas that can be issued to the best and brightest from all over the world. But let's not use bogus reasons to justify it. And the H1B with its myriad of limitations and restrictions is just plain obnoxious, we need something better if we really are trying to bring in the best and the brightest.
There are literally hundreds of thousands of trained and experienced American software engineers "on the bench" right now and 50% of graduates of U.S. computer science and IS programs don't even manage to find a job in the field. Google gets over 1,000,000 resumes per year. Microsoft may not get that many due to Microsoft's reputation as a "stodgy" and "yesterday's technology" company amongst the best and brightest (yes, I know that's unfair, but that's MS's reputation outside the MS "bubble") but I would be seriously surprised if Microsoft got less than 500,000 resumes per year. Microsoft hires about 3,000 people per year -- or roughly 0.6% of the people who submit resumes.
Given that, the notion that Microsoft can't find sufficient talent without H1B's says more about Microsoft's hiring process and Microsoft's reputation than it says about the availability of Americans with a background and training in software engineering. Especially telling is your notion that Microsoft should only look at the "top 20%" from a few "elite" universities. Frankly, given the criteria you mentioned, I wouldn't have been qualified to work for Microsoft upon college graduation because I wasn't "in the top 20%" -- mostly because I'd been working multiple jobs while in college, including writing actual software products shipped to actual real paying customers either as a contractor for various local companies or as an employee of a relative's company. I think my record over the past twenty years (multiple products shipped in multiple technologies ranging from PIC firmware for a front panel processor to Linux kernel driver work to Groovy/Grails code for a web app) shows just how silly Microsoft's criteria really are. There's a lot of talent out there that never makes it past that initial pre-screen where Microsoft immediately discards 80% of the applicants as "not good enough" without a single technical person ever talking to the applicant.
Frankly, our biggest problem when we go to hire people is not a shortage of candidates. It's too *many* candidates. My team doesn't have time to interview all the possible candidates who are submitted when we have a job opening, meaning it's a heavy filtering process. We rely on recruiters that we trust to do the initial prescreening, the ones we work with have technical backgrounds. Once they do the prescreening my boss is the guy doing the next level of filtering, and luckily he has a technical background too. The handful of candidates who make it to actual interviews generally all would be capable of doing the job, it becomes a case of deciding whether a candidate would fit with the team, stands out in some way, etc.
Unfortunately at many major corporations the people doing the initial filtering don't have a technical background and end up filtering on trivial criteria that discard good candidates for no good reason. That mostly lame people get dumped on your desk doesn't surprise me. It seems to be the norm for major corporations today where HR is doing the filtering. But that says more about a broken hiring process than it says about any shortage of trained and often experienced software talent.
I'm one of those "too hard to retrain" older programmers. I helped develop the new technologies, so clearly I know them better than some newbie right out of college, so all I can say is WTF? In my experience newbies right out of college don't even know how to properly do object oriented programming, much less know the ins and outs of new technologies such as, say, Groovy/Grails. Which, BTW, I picked up within a few weeks when I needed to do so, because it's just an interpreted Ruby-like language with Java syntax and a thin layer over Hibernate for persistence along with a JSP-like rendering language, all of which were technologies I already knew, so...
Of course the next big new web framework technology is going to be Scala / Play which is, uhm, pretty much like other technologies I already know, just "fresh" and "new" (and with some interesting contrasts to Groovy/Grails) so I expect when it comes time to do so, I'll pick it up in a few weeks, far less time than it takes to import an H1B from India. But hey, I'm a Neanderthal too hard to retrain, right?
Oh wait, the H1Bs can be warehoused 20 to the apartment and paid $12,000/year. Alrighty, then!
What tech stack? I suppose "Linux". The more apt question would be what have I *not* done, from firmware for a PIC front panel processor to Linux kernel driver maintenance to Linux distribution design from bootloader contents to application payload to design and implementation of web app back ends in Java, Groovy, and Grails. I've used C, C++, Ruby, Java, Python, Groovy, Perl,/bin/sh, a couple of assembly languages, and probably more that I've actually forgotten. My last job I was specifying the hardware for a storage appliance, creating the Linux distribution that ran on it, and maintaining / refreshing / updating some of the drivers that ran it as well as modifying the core storage stack to run on the new Linux distribution and devising a much better scheme for imaging and upgrading appliances. The job before that was writing a the management infrastructure for a firewall appliance as well as debugging some kernel driver issues such as a buggy I2C driver. This job I'm doing Groovy / Grails programming while automating cloud deployment in the EC2 cloud and managing the entire deployment process. It's not necessarily that I move around a lot, it's that when companies need something done, they know that if I'm assigned a responsibility it gets done. Indeed, I didn't even switch desks when I moved from maintaining the storage appliance to automating the cloud deployment process (BTW, whoever specified JSON for CloudFormation needs to be beat over the head with a Clue Stick, JSON doesn't have comments so is a *terrible* configuration language). Though the company did change around me:).
As for age, I saw human beings bouncing around on the Moon. On live TV. Not on History Channel replays. Do your own math:).
Oddly enough, my previous three job offers were for salaries well above my salary expectations, In some cases significantly above. In my case it's not my salary expectations that are the problem (I live frugally and have a significant chunk of change in the bank and typically choose jobs based on what interests me rather than the size of the offer), it's the industry's perception of what my salary expectations must be given my experience level that are (conceivably) the problem. I say "conceivably" because thus far when I've actively looked for a job the problem is choosing between multiple competing job offers, not a lack of job offers.
My commute in the Silicon Valley is 20 minutes, and I find it annoying because my last commute in the Silicon Valley was 10 minutes. It's all about location, location, location, I choose to live near where the jobs are, not in some awful out of the way place like Fremont (BTW, 880 is a bit better now that they *finally* finished the Mission Blvd project after ten years). I worked all over the country before moving here ten years ago. The reason I moved here ten years ago is because this is where the jobs I like -- mostly hacking Linux distributions and internals for companies making actual hardware products --- are located. No more moving to another city for the next job. In fact, I lived at my last apartment for six years, and have been in my current place for four years. How refreshing after years of being one place for a few years, then another city entirely halfway across the country for the next few years.
I'm in the Silicon Valley. I work for a 16 person startup. Our youngest engineer is 22. Our oldest engineer is sixty-something and kicks a** and takes names while accomplishing more in the past week than the youngest engineer accomplished in a month. As someone else noted, it's all about ownership. Our ownership doesn't care what age their engineers are, just that things get done. Same has been true of the last three startups that I worked at, there were greybeards and college interns and everything inbetween. But they were all in "real" (as in, actual product solving real problems for real people) fields, not a startup that produced Flappy Bird clones for iPhones. Folks trying to solve real problems for real people don't have time to indulge in ageism, they're trying to get adequate-quality product out the door in as timely a manner as possible. Note that most of the annoying Social App Ivy League hipster startup type people have moved to San Francisco, the traditional Silicon Valley area (the South Bay) is now full of iron-mongers -- computer manufacturers, networking gear and storage gear people. Well, and Google. But Google is its own Googly thing.
BTW, as you can probably guess from my low user ID, I've been around for a while. No problem finding a job, just a problem with too many recruiters calling or emailing me wanting me to go to work for their client.
I've been in charge of update deployment and strategy for several companies now. There's a few issues that come into play when deciding whether an update can be reverted or not. For a trivial app that doesn't maintain much data there's no real issue. Anything that does maintain real data, you must determine whether the database schema change between version A and version B is backwards compatible so that you can roll from B back to A. If the database schema change is incompatible, then you can't roll back. Same thing with on-disk data formats in general. I have Fedora 20 installed on one of my systems. If I wanted to roll back to the previous Centos 6 I couldn't, because the XFS file system format changed between 2.6.32 and 3.12. Centos won't mount Fedora 20 XFS filesystems.
Then there's binary compatibility issues. One release of one employer's software was based on Fedora 7 with a lot of modifications (different kernel, various applications updated, etc.). The next major release was, due to a gigantic change in hardware architecture for their newest systems, based on Fedora 13, including a major version update to Postgres for the database. The upgrade process runs out of a special imaging initrd and consists of save off the database with pg_dump to a couple of data drives, wipe out the base OS, plop on the new base OS, install the new application layer on top of the base OS, and restore the database with pg_restore. The pg_dump and pg_restore are necessary because the binary format of Postgres databases changed between the two different versions of Postgres. Downgrading in this case is impossible because the older version didn't know how to do pg_dump and pg_restore, since its previous releases had used the same antique version of Postgres (a version so old it wouldn't even compile under Fedora 13).
Finally, there's the question of whether an update scheme even has provisions for forcing arbitrary versions. The ones I've designed did, mostly because they were for very large data storage appliances where you didn't want anything updating automatically because scheduling a service outage for the update is a Big Deal for big data storage systems and where you needed the ability to roll back to the previous version if the update happened half-baked (if, say, the power supplies both blew out halfway through the update and left it only halfway on the disk). So you had to manually select which version you wished to update to, based on a list of what was compatible with your hardware and current installed version. But it appears to me that Apple has no such ability within their App Store interface. They make only the latest version available, period, even if it isn't compatible with your older iDevice.
So: Being able to roll back to the older version of the software is a lofty goal. But sometimes it just isn't feasible. On our web application once the database format has been updated to a new incompatible schema and new data is flowing in, there's no going back -- even though we saved off a copy of the old database before doing the database schema change, going back would discard all the new data that's flowed in since. So we cross our fingers, run it in parallel with a clone of the old system's data stream for a while to assure ourselves it won't blow up, and test the bleep out of it before cutting it over as the active version. Because once it's been in service for over a couple of hours there's no going back -- people may tolerate losing a few updates, but not days worth.
That said, when I had my Europa Universalis IV save games wiped out by an update to EUIV that Steam auto-updated without my consent or knowledge, I certainly was peeved! I should have at least been given the opportunity to *not* update, which even Apple gives you. That would have allowed me to spend a couple of days researching the update and waiting for people's feedback on whether it was worthy or not. Instead... sigh. So it goes.
The primary reason why most laptop vendors don't offer a hard drive in place of the optical drive is power consumption. Optical drives use basically nothing when they're sitting there idle, and since most optical drives today are used about as much as floppy drives were used in the mid 1990's (i.e., virtually never, only to install software, and even that is going away with Internet delivery of software), that means that they can spec the rest of the laptop around a lower power draw, which allows them to claim a longer battery life and allows them to use a smaller fan to cool the laptop and a smaller brick to power the laptop and allows you to actually set the laptop on your lap without scorching your lap and requiring a trip to the surgery suit for skin grafts. The large desktop replacement laptops from Dell and HP (amongst others) actually do have space for multiple hard drives, but those are more portable desktops than laptops -- you aren't going to unplug one of those and walk across the lab with it to plug into a different network to sniff for a rogue machine that's brought your installation to a crawl, they sit on a desk and stay there, with short excursions to the car and home perhaps, because they are large, bulky, hot, will last maybe 20 minutes on battery power, and have power bricks the size of concrete blocks.
Given that, if you need a lot of space in a single 2.5" form factor package to fit into, say, a current Apple Macbook Pro (where Apple very highly optimizes the power consumption and the OS really doesn't deal well with you removing the optical drive and putting in a second hard drive using a third-party bracket, it won't go to sleep correctly much of the time), the hybrid approach makes a lot of sense. The primary issue with the prior generation of the Momentus XT in that application was a) it topped off at 500GB, and b) it consumed more power than a 750GB 7200 RPM Western Digital Black drive. The current generation solves the capacity problem, but I'll need to take a close look at power consumption, because power budgets in many modern slim (i.e., actually portable) laptops are quite tight.
The core problem with SSD's is write speed on workloads that have a large number of small updates. My testing on the older 500GB Momentus XT showed that in general it had better write speed doing, e.g., a Fedora install, than the 80GB Intel SSD that I benchmarked it against (same generations of product here, about a year ago), due to the large number of small updates that the non-SSD-aware EXT3/4 filesystems do during the course of installing oodles of RPM's. Because the Momentus only caches *read* requests in the SSD (write requests flow right through it, other than to invalidate anything in its internal cache that is getting written), writes went through at full 7200 rpm 2.5" hard drive speed. In general when I benchmarked writes on similar-generation 7200 rpm 2.5" hard drives and SSD's, the hard drives ended up faster for virtually all real-world workloads, so the end result of my benchmarking was that on real-world workloads the hybrid drive was faster at reads than a hard drive (primarily due to SSD-cached filesystem metadata) and faster at writes than an SSD.
Please not that I have *not* tested the current generation of SSD's and Momentus XT. Just that it's baffling that the Momentus XT never seemed to really get any traction in the marketplace, given the performance advantages of the approach for many real-world tasks.
Wow, great job reciting Fox News talking points. Too bad they have nothing to do with reality. I know what my local school districts' pay scale is. I know what I get paid as a top software engineer. I know what my benefits are, and I know what my local school districts' benefits are. Here's some facts:
* I get free health, dental, life, and disability insurance as a software engineer. Teachers in the local district pay 100% of the cost of their health insurance. * The top pay scale for a teacher with 20 years experience and an advanced degree in my district is less than half of my salary as a software engineer. * Tenure rights for public school teachers are based on Constitutional due process and as long as due process is followed, any teacher can be fired for any *valid* reason (i.e., not just because the principal doesn't like gays or Mormons). Any principal who says he has a problem getting rid of an incompetent teacher is either himself incompetent or is lying to you, there is due process to follow but in every state of the nation an incompetent teacher can be fired regardless of tenure. * Tenure rights don't have anything to do with layoffs. 40% of teachers in some of our local districts got layoff notices this year. A large percentage of those teachers had tenure. * I will receive more money from Social Security when I retire (due to maxing out the contribution limit each year) than the teachers in the top pay scale at my local district will receive from CALPERS. And because of the double-dipping penalty in the Social Security formula, they'll never make more combined pension and Social Security than I get from Social Security when I retire.
Really, with a disrespectful and ignorant attitude being the norm, why *would* I want to teach? So people like you could spit on me for doing a job that's ten times harder than software engineering? Been there, done that. No thanks.
I am wondering what in the world you are talking about. During the three years I was teaching, a) my highest salary was the munificent sum of $21,800 per year (roughly $40K/year in today's dollars), b) I paid 100% of my health insurance costs (NO district subsidy of the cost), and c) the retirement benefit was 40% of my ginormous salary if I managed to survive 30 years without stroking out, being knifed or shot by one of my students, or being thrown under the bus by a school administrator upset that I cared about whether my students learned or not (and note that I did NOT pay into Social Security and if I had managed to get Social Security via some other job, there's a "double dipper" penalty in the SS formula that would take most of that away from me). In the years since I switched to doing software engineering rather than teaching mathematics I've sometimes worked 60+-hour weeks and multiple all-nighters but never worked anywhere near as hard as I worked as a teacher and get paid more than three times as much money than a teacher. If you paid me the same six-figure salary I make as a senior-level engineer I still wouldn't go back, because the job is thankless, never-ending, and utterly exhausting both physically and intellectually if you're doing it right. My hats off to those teachers who stay on the job and do it well, year after year, because the fools who criticize such teachers have not a clue.
BTW, once you get above 35 students in a classroom, it becomes simply impossible to manage in a way conducive to learning. Above 35 students learning starts dropping off rapidly, past 40 it's just baby-sitting and make-work. Teachers know this the hard way. The fact that politicians and parents talk about 40+ student classrooms as if that were some reasonable solution to the cost of running public schools tells me that either a) they don't care about education, they just want free babysitting to keep kids off the streets, or b) they're clueless cretins who need to be drummed about the head with a clue stick. That is all.
Perhaps Media Molecule should think about hiring some of the 50%+ of UK Computer Science graduates who cannot find a job in the field? When I see statistics that say that 70% of Computer Science graduates are not working in the field five years later, I call balderdash on the notion of a shortage of software engineers in the UK. If Media Molecule truly believes that 50%+ of UK Computer Science graduates are unqualified to write software, it sounds to me as if their beef is with the universities that credential people not worthy of said credential, not with anything happening at the primary school level.
I saw my first computer at age 17. I've been making a living writing software or doing other related things for over 20 years now and while I'm no Linus Torvalds, I still don't have any problem finding a job when I need one and making significant contributions everywhere I go. What differentiates those who will be good at writing software from those who will never be has nothing to do with how young you are when you encounter computers, and everything to do with your ability to think in a logical and straightforward manner. I would much rather see our schools teach thinking skills than computer skills. Thinking skills are useful for other things (say, in figuring out which politicians are lying to you and thus you should vote for the one *not* lying to you, for example), while skill writing computer programs is useful only for a small set of problems. I don't write algorithms to go grocery shopping or change the cat box. Just sayin'.
One thing I'll note is that MIT MACLisp had a functional compiler that compiled all the way down to machine code before most of Slashdot's readers were born. The original MIT Multics Emacs was written in MACLisp, I looked at the resulting ALM (Assembly Language Multics) from the compilation process for a few functions just to see how well it compiled, and it was pretty close to the output I saw from the PL/1 compiler, which had an excellent optimizer for that era. There's nothing inherent about Lisp that makes it impossible to compile and optimize, Bernie Greenberg and David A. Moon certainly proved that.
That said, I'm of the opinion that the age of extension languages embedded into applications is over. The extension language paradigm explicitly limits the extension language to manipulating a single application, when what we have open on our modern desktop is dozens of applications and we'd like to create something new from all of them. What is needed, instead, is a universal interface exported by applications to use to script applications. Think Windows PowerShell rather than Emacs Lisp -- the shell lives outside the application and calls a defined application API to perform actions. SOAP/XML-RPC/REST are far more important to the future of scriptability than some archaic concept from the 1960s and 1970's, if I implement one of those interfaces to the core functionality of my application I can write my extensions in *anything* -- Perl, Java, Python, you name it. The problem of course is that SOAP/XML-RPC/REST are also horrendously inefficient, surely we can do better than marshalling and demarshalling everything to/from XML or JSON. Still, I present this as a conceptual thought -- though I might point out that the Amiga *almost* managed something similar with AREXX (theoretically it was possible to use the "AREXX port" to control Amiga applications from other scripting languages, though it was rarely done).
Slashdot Mirror
Uhm, it does in fact cost money to post job ads on Craigslist. See http://www.craigslist.org/abou... . It's one of their major sources of money, along with hooker ads (oops, "therapeutic services", my bad).
Why you would do so, however, eludes me. As with the poster above, at multiple employers that have tested the Craigslist waters we've never had anybody remotely qualified respond to one of our Craigslist ads. They're just pocket change compared to Dice.com or compared to paying a recruiter's fee, so it was a "why not?". But every one of our hires seems to have been either a personal referral from a current employee, or a recruiter lured them away from another company.
Manual? What is that? Paper service manuals have gone the way of buggy whips in the auto service industry. Nobody publishes them anymore except maybe General Motors. It's all regularly-updated computer-based manuals for everybody else. Independents use Alldata, which gets updates on a regular basis from manufacturers, and dealerships use their manufacturer's computer system that does the same thing (such as Chrysler TechAuthority). For most newer cars if you are an end user who wants factory service info you go to AlldataDIY.com because paper service manuals are no longer published. For parts lists it's even simpler, you don't have to pay Alldata, the modern mechanic goes to the manufacturer's web site like Mopar.com or to some third party vendors which similarly give access to the manufacturer parts database and look up the part number there. If you pull an old part and put the part number off of it into the parts site search box, the computer will say "Superseded by" and give you the new part number. If there's no part number on the part, you drill down the assemblies list on the parts site until you see the labeled picture with your part on it, and the current part number will be in the list beneath that illustration.
And of course if you go to the dealership parts window, they put in the old part number into their computer, it says "superseded by part XYYZ", and they give you part XYYZ instead.
This is the 21st century. We have these COMPUTER thingies now. Just sayin'. There's no longer an excuse to *not* change the part number when the part has, in fact, changed. And I know for a fact that several part numbers on my Jeep have changed multiple times since it was manufactured in 2011. Which is why any modern automotive engineer has to be suspicious when GM did not change the part number on that ignition switch when, in fact, it's an entirely redesigned ignition switch...
Which, in combination with $1, will buy you a cup of coffee. I haven't noticed that Eastern European or Chinese spammers and attackers have been deterred one whit by those bilateral trade agreements.
Spammers definitely will *not* get a whole Amazon netblock blacklisted. Amazon firewalls outgoing port 25 traffic. If you want to send email from AWS you need to bounce it via authenticated port 465 or 537 through a mail service on some other ISP.
I'm not quite sure what you're talking about. Auto-scaling groups are the only thing that can restart a terminated instance (actually, they start a *new* instance). If you somehow managed to create an auto-scaling group and don't know how to set its parameters (min/max/desired) down to zero, when it's right there on the GUI, I don't know what to tell you.
Nobody really writes new applications in it, but there's a bajillion Java applications running most major corporations now the way COBOL used to in the old days.
That said, when looking for an engineer I'm not looking for someone who knows Java (even though that's what a lot of our product is written in). I'm looking for someone who understands computational complexity, is familiar with common algorithms and data structures, and has some notion of object oriented programming and software engineering. Anybody who's written a lot of code can pick up Java fairly swiftly at least to the "getting s**t done" stage, it took me roughly a week to do so ("oh, so it's like Python with C++ syntax, except with only single inheritance and with templates!"), but if you don't understand the why of what you're doing, you're not going to do well in our shop.
So: Get a computer science degree. Or at least significant computer science coursework. And not from Joe's Plumbing and Programming School, get one from some place that teaches actual computer science, not programming. Either that, or write some Open Source applications and contribute to the Linux kernel. Nobody cares what school you went to if you can write Linux drivers, all they care about is that you know the difference between a BIO and an SK_BUF. But they want to see your name in the Linux changelogs first.
A company which sells a solution at a higher price than other companies because of a higher cost of developing the software is soon to be an ex-company.
You're talking technology. But technology does not determine whether a company stays in business. Delivering in a timely manner a solution that works well enough for a cost equal to or less than the competition is what determines whether a company stays in business. There's a large number of application areas where Windows is what allows that. Luckily that's not *every* industry, or else I would have problems. (Disclaimer: I have been writing commercial software for Linux since 1996, yep, 18 years now).
My brother works in the SCADA industry. All of their stuff is Windows, mostly Windows XP Embedded. Why? Simple. It's the tools. There are various toolkits out there that make building a SCADA application almost drag-and-drop. It'd take four times as many people twice as long to hack all that up in C or C++ under Linux. And they simply don't sell enough SCADA systems to justify that kind of effort -- it's a crowded market where no single vendor manages to sell more than a few hundred instances of any particular model, so per-unit development cost difference between Windows and Linux far outweighs the OS cost difference.
As for why SCADA toolchain vendors don't port their tools to Linux, usually their tools are a large array of components from various vendors strung together with DCOM. Distributed SCADA systems in particular are heavily invested in Microsoft's DCOM OPC for communications between SCADA components such as pipeline pressure monitors, valve position sensors, billing stations, and operational monitoring stations. Linux doesn't support DCOM OPC as such, or any equivalent to it, with any standard libraries though there are emulators that may or may not work. The industry standardized on DCOM OPC for practical reasons -- it existed at the time they started doing all this (back in Windows NT days) while nothing like it existed on Linux back then, and they can write binary components that work pretty much on any Windows system, as versus with Linux where the distributions are not binary compatible and where five year old binaries will rarely run on a modern Linux system. Linux is great when you're selling a whole solution from top to bottom, but if you're trying to sell commercial software to SCADA system developers, Linux presents significant practical difficulties compared to WIndows. So there simply is no incentive to move off of Windows even though they're likely going to now be targeting later embedded Windows versions rather than embedded XP.
I'm not up on ATM's. But it would surprise me if ATM developers did not in fact use similar tools to create their product -- tools that are Windows-centric not because of Linux hatred, but because of history and the practical problems of trying to sell binary-blob commercial software on Linux (which is a task akin to nailing jelly to a tree).
H1B visas *can* be transferred, but it's a major annoyance. One of our H1B's was "officially" still on the payroll of the parent company after our division was split off as a separate company. This annoyed our former parent company greatly, since they had to pay him then bill us for his pay and benefits, but part of the divestment agreement called for them to do that for him until we could get the visa transferred. It took roughly six months to get the visa transferred :(.
BTW, the United States is not the world. For example, the UK likes to poach the best and brightest H1B's from the US, I know three Indians formerly in the US on H1B's who've ended up in London. Canada also loves Indian immigrants who have a computer science degree and five years of work experience in computer fields, they put such immigrants on a fast track to a work permit and citizenship since they're perceived as having valuable skills and as being easy to assimilate. The notion that the H1B's only have a choice of India and the US as places to work is a false one. The US is still a major draw but if the US mistreats immigrants, they'll go elsewhere and the US will basically have spent a small fortune training them up for the UK, Canada, and other nations to get the advantage of such training.
Often the lowest-paid H1B's, the ones working for contracting companies like Tata, are stacked in communal apartments. One 1-bedroom apartment I visited had eight people living in it, they slept on futon mattresses thrown on the floor of the living room and bedroom and eat communally in the kitchen/dining area (there are multiple Indian grocers within walking distance of that apartment complex so it is easy to get cheap eats, though they tend to not be good cooks -- I almost swore off of Indian food after tasting a sample!). They rarely have cars, they rely on mass transit or employer bus to get to work. I drive by a bus stop every morning that has two dozen H1B's waiting for the bus so they can get to Cisco where they work. (I know it's Cisco because they have various Cisco-related stickers, binders, backpacks, etc. as well as Cisco badges that serve as their bus fare due to a special agreement Cisco made with the local transit authority).
Then there are the H1B's who are here because other work visas are too expensive, but otherwise are just normal employees. Several of my co-workers at my last company were H1B's. They had been working in the India office of the company when the India office was closed down as the company downsized, but were critical employees (they'd "owned" major parts of the technology as engineers and basically were irreplaceable due to their institutional knowledge of the innards of the technology) so were brought over on H1B. There needs to be a better way of handling that kind of thing other than the H1B with all its limitations and restrictions, but right now there really isn't, not unless your name is Linus Torvalds and you're brought in on a "genius" visa. We were always nervous when one of them went back home on vacation as to whether they'd be able to get back into the country. We endured the legal nightmare that was their work visa because they really were that important to our company. I presume they were paid accordingly.
In general I have no problem with the notion that it's a good idea to have work visas that can be issued to the best and brightest from all over the world. But let's not use bogus reasons to justify it. And the H1B with its myriad of limitations and restrictions is just plain obnoxious, we need something better if we really are trying to bring in the best and the brightest.
There are literally hundreds of thousands of trained and experienced American software engineers "on the bench" right now and 50% of graduates of U.S. computer science and IS programs don't even manage to find a job in the field. Google gets over 1,000,000 resumes per year. Microsoft may not get that many due to Microsoft's reputation as a "stodgy" and "yesterday's technology" company amongst the best and brightest (yes, I know that's unfair, but that's MS's reputation outside the MS "bubble") but I would be seriously surprised if Microsoft got less than 500,000 resumes per year. Microsoft hires about 3,000 people per year -- or roughly 0.6% of the people who submit resumes.
Given that, the notion that Microsoft can't find sufficient talent without H1B's says more about Microsoft's hiring process and Microsoft's reputation than it says about the availability of Americans with a background and training in software engineering. Especially telling is your notion that Microsoft should only look at the "top 20%" from a few "elite" universities. Frankly, given the criteria you mentioned, I wouldn't have been qualified to work for Microsoft upon college graduation because I wasn't "in the top 20%" -- mostly because I'd been working multiple jobs while in college, including writing actual software products shipped to actual real paying customers either as a contractor for various local companies or as an employee of a relative's company. I think my record over the past twenty years (multiple products shipped in multiple technologies ranging from PIC firmware for a front panel processor to Linux kernel driver work to Groovy/Grails code for a web app) shows just how silly Microsoft's criteria really are. There's a lot of talent out there that never makes it past that initial pre-screen where Microsoft immediately discards 80% of the applicants as "not good enough" without a single technical person ever talking to the applicant.
Frankly, our biggest problem when we go to hire people is not a shortage of candidates. It's too *many* candidates. My team doesn't have time to interview all the possible candidates who are submitted when we have a job opening, meaning it's a heavy filtering process. We rely on recruiters that we trust to do the initial prescreening, the ones we work with have technical backgrounds. Once they do the prescreening my boss is the guy doing the next level of filtering, and luckily he has a technical background too. The handful of candidates who make it to actual interviews generally all would be capable of doing the job, it becomes a case of deciding whether a candidate would fit with the team, stands out in some way, etc.
Unfortunately at many major corporations the people doing the initial filtering don't have a technical background and end up filtering on trivial criteria that discard good candidates for no good reason. That mostly lame people get dumped on your desk doesn't surprise me. It seems to be the norm for major corporations today where HR is doing the filtering. But that says more about a broken hiring process than it says about any shortage of trained and often experienced software talent.
I'm one of those "too hard to retrain" older programmers. I helped develop the new technologies, so clearly I know them better than some newbie right out of college, so all I can say is WTF? In my experience newbies right out of college don't even know how to properly do object oriented programming, much less know the ins and outs of new technologies such as, say, Groovy/Grails. Which, BTW, I picked up within a few weeks when I needed to do so, because it's just an interpreted Ruby-like language with Java syntax and a thin layer over Hibernate for persistence along with a JSP-like rendering language, all of which were technologies I already knew, so ...
Of course the next big new web framework technology is going to be Scala / Play which is, uhm, pretty much like other technologies I already know, just "fresh" and "new" (and with some interesting contrasts to Groovy/Grails) so I expect when it comes time to do so, I'll pick it up in a few weeks, far less time than it takes to import an H1B from India. But hey, I'm a Neanderthal too hard to retrain, right?
Oh wait, the H1Bs can be warehoused 20 to the apartment and paid $12,000/year. Alrighty, then!
What tech stack? I suppose "Linux". The more apt question would be what have I *not* done, from firmware for a PIC front panel processor to Linux kernel driver maintenance to Linux distribution design from bootloader contents to application payload to design and implementation of web app back ends in Java, Groovy, and Grails. I've used C, C++, Ruby, Java, Python, Groovy, Perl, /bin/sh, a couple of assembly languages, and probably more that I've actually forgotten. My last job I was specifying the hardware for a storage appliance, creating the Linux distribution that ran on it, and maintaining / refreshing / updating some of the drivers that ran it as well as modifying the core storage stack to run on the new Linux distribution and devising a much better scheme for imaging and upgrading appliances. The job before that was writing a the management infrastructure for a firewall appliance as well as debugging some kernel driver issues such as a buggy I2C driver. This job I'm doing Groovy / Grails programming while automating cloud deployment in the EC2 cloud and managing the entire deployment process. It's not necessarily that I move around a lot, it's that when companies need something done, they know that if I'm assigned a responsibility it gets done. Indeed, I didn't even switch desks when I moved from maintaining the storage appliance to automating the cloud deployment process (BTW, whoever specified JSON for CloudFormation needs to be beat over the head with a Clue Stick, JSON doesn't have comments so is a *terrible* configuration language). Though the company did change around me :).
As for age, I saw human beings bouncing around on the Moon. On live TV. Not on History Channel replays. Do your own math :).
I was especially amused when they invented "agile" and "scrum". Remember when we were doing that in 2000? :)
Oddly enough, my previous three job offers were for salaries well above my salary expectations, In some cases significantly above. In my case it's not my salary expectations that are the problem (I live frugally and have a significant chunk of change in the bank and typically choose jobs based on what interests me rather than the size of the offer), it's the industry's perception of what my salary expectations must be given my experience level that are (conceivably) the problem. I say "conceivably" because thus far when I've actively looked for a job the problem is choosing between multiple competing job offers, not a lack of job offers.
My commute in the Silicon Valley is 20 minutes, and I find it annoying because my last commute in the Silicon Valley was 10 minutes. It's all about location, location, location, I choose to live near where the jobs are, not in some awful out of the way place like Fremont (BTW, 880 is a bit better now that they *finally* finished the Mission Blvd project after ten years). I worked all over the country before moving here ten years ago. The reason I moved here ten years ago is because this is where the jobs I like -- mostly hacking Linux distributions and internals for companies making actual hardware products --- are located. No more moving to another city for the next job. In fact, I lived at my last apartment for six years, and have been in my current place for four years. How refreshing after years of being one place for a few years, then another city entirely halfway across the country for the next few years.
I'm in the Silicon Valley. I work for a 16 person startup. Our youngest engineer is 22. Our oldest engineer is sixty-something and kicks a** and takes names while accomplishing more in the past week than the youngest engineer accomplished in a month. As someone else noted, it's all about ownership. Our ownership doesn't care what age their engineers are, just that things get done. Same has been true of the last three startups that I worked at, there were greybeards and college interns and everything inbetween. But they were all in "real" (as in, actual product solving real problems for real people) fields, not a startup that produced Flappy Bird clones for iPhones. Folks trying to solve real problems for real people don't have time to indulge in ageism, they're trying to get adequate-quality product out the door in as timely a manner as possible. Note that most of the annoying Social App Ivy League hipster startup type people have moved to San Francisco, the traditional Silicon Valley area (the South Bay) is now full of iron-mongers -- computer manufacturers, networking gear and storage gear people. Well, and Google. But Google is its own Googly thing.
BTW, as you can probably guess from my low user ID, I've been around for a while. No problem finding a job, just a problem with too many recruiters calling or emailing me wanting me to go to work for their client.
I've been in charge of update deployment and strategy for several companies now. There's a few issues that come into play when deciding whether an update can be reverted or not. For a trivial app that doesn't maintain much data there's no real issue. Anything that does maintain real data, you must determine whether the database schema change between version A and version B is backwards compatible so that you can roll from B back to A. If the database schema change is incompatible, then you can't roll back. Same thing with on-disk data formats in general. I have Fedora 20 installed on one of my systems. If I wanted to roll back to the previous Centos 6 I couldn't, because the XFS file system format changed between 2.6.32 and 3.12. Centos won't mount Fedora 20 XFS filesystems.
Then there's binary compatibility issues. One release of one employer's software was based on Fedora 7 with a lot of modifications (different kernel, various applications updated, etc.). The next major release was, due to a gigantic change in hardware architecture for their newest systems, based on Fedora 13, including a major version update to Postgres for the database. The upgrade process runs out of a special imaging initrd and consists of save off the database with pg_dump to a couple of data drives, wipe out the base OS, plop on the new base OS, install the new application layer on top of the base OS, and restore the database with pg_restore. The pg_dump and pg_restore are necessary because the binary format of Postgres databases changed between the two different versions of Postgres. Downgrading in this case is impossible because the older version didn't know how to do pg_dump and pg_restore, since its previous releases had used the same antique version of Postgres (a version so old it wouldn't even compile under Fedora 13).
Finally, there's the question of whether an update scheme even has provisions for forcing arbitrary versions. The ones I've designed did, mostly because they were for very large data storage appliances where you didn't want anything updating automatically because scheduling a service outage for the update is a Big Deal for big data storage systems and where you needed the ability to roll back to the previous version if the update happened half-baked (if, say, the power supplies both blew out halfway through the update and left it only halfway on the disk). So you had to manually select which version you wished to update to, based on a list of what was compatible with your hardware and current installed version. But it appears to me that Apple has no such ability within their App Store interface. They make only the latest version available, period, even if it isn't compatible with your older iDevice.
So: Being able to roll back to the older version of the software is a lofty goal. But sometimes it just isn't feasible. On our web application once the database format has been updated to a new incompatible schema and new data is flowing in, there's no going back -- even though we saved off a copy of the old database before doing the database schema change, going back would discard all the new data that's flowed in since. So we cross our fingers, run it in parallel with a clone of the old system's data stream for a while to assure ourselves it won't blow up, and test the bleep out of it before cutting it over as the active version. Because once it's been in service for over a couple of hours there's no going back -- people may tolerate losing a few updates, but not days worth.
That said, when I had my Europa Universalis IV save games wiped out by an update to EUIV that Steam auto-updated without my consent or knowledge, I certainly was peeved! I should have at least been given the opportunity to *not* update, which even Apple gives you. That would have allowed me to spend a couple of days researching the update and waiting for people's feedback on whether it was worthy or not. Instead... sigh. So it goes.
The primary reason why most laptop vendors don't offer a hard drive in place of the optical drive is power consumption. Optical drives use basically nothing when they're sitting there idle, and since most optical drives today are used about as much as floppy drives were used in the mid 1990's (i.e., virtually never, only to install software, and even that is going away with Internet delivery of software), that means that they can spec the rest of the laptop around a lower power draw, which allows them to claim a longer battery life and allows them to use a smaller fan to cool the laptop and a smaller brick to power the laptop and allows you to actually set the laptop on your lap without scorching your lap and requiring a trip to the surgery suit for skin grafts. The large desktop replacement laptops from Dell and HP (amongst others) actually do have space for multiple hard drives, but those are more portable desktops than laptops -- you aren't going to unplug one of those and walk across the lab with it to plug into a different network to sniff for a rogue machine that's brought your installation to a crawl, they sit on a desk and stay there, with short excursions to the car and home perhaps, because they are large, bulky, hot, will last maybe 20 minutes on battery power, and have power bricks the size of concrete blocks.
Given that, if you need a lot of space in a single 2.5" form factor package to fit into, say, a current Apple Macbook Pro (where Apple very highly optimizes the power consumption and the OS really doesn't deal well with you removing the optical drive and putting in a second hard drive using a third-party bracket, it won't go to sleep correctly much of the time), the hybrid approach makes a lot of sense. The primary issue with the prior generation of the Momentus XT in that application was a) it topped off at 500GB, and b) it consumed more power than a 750GB 7200 RPM Western Digital Black drive. The current generation solves the capacity problem, but I'll need to take a close look at power consumption, because power budgets in many modern slim (i.e., actually portable) laptops are quite tight.
The core problem with SSD's is write speed on workloads that have a large number of small updates. My testing on the older 500GB Momentus XT showed that in general it had better write speed doing, e.g., a Fedora install, than the 80GB Intel SSD that I benchmarked it against (same generations of product here, about a year ago), due to the large number of small updates that the non-SSD-aware EXT3/4 filesystems do during the course of installing oodles of RPM's. Because the Momentus only caches *read* requests in the SSD (write requests flow right through it, other than to invalidate anything in its internal cache that is getting written), writes went through at full 7200 rpm 2.5" hard drive speed. In general when I benchmarked writes on similar-generation 7200 rpm 2.5" hard drives and SSD's, the hard drives ended up faster for virtually all real-world workloads, so the end result of my benchmarking was that on real-world workloads the hybrid drive was faster at reads than a hard drive (primarily due to SSD-cached filesystem metadata) and faster at writes than an SSD.
Please not that I have *not* tested the current generation of SSD's and Momentus XT. Just that it's baffling that the Momentus XT never seemed to really get any traction in the marketplace, given the performance advantages of the approach for many real-world tasks.
Wow, great job reciting Fox News talking points. Too bad they have nothing to do with reality. I know what my local school districts' pay scale is. I know what I get paid as a top software engineer. I know what my benefits are, and I know what my local school districts' benefits are. Here's some facts:
* I get free health, dental, life, and disability insurance as a software engineer. Teachers in the local district pay 100% of the cost of their health insurance.
* The top pay scale for a teacher with 20 years experience and an advanced degree in my district is less than half of my salary as a software engineer.
* Tenure rights for public school teachers are based on Constitutional due process and as long as due process is followed, any teacher can be fired for any *valid* reason (i.e., not just because the principal doesn't like gays or Mormons). Any principal who says he has a problem getting rid of an incompetent teacher is either himself incompetent or is lying to you, there is due process to follow but in every state of the nation an incompetent teacher can be fired regardless of tenure.
* Tenure rights don't have anything to do with layoffs. 40% of teachers in some of our local districts got layoff notices this year. A large percentage of those teachers had tenure.
* I will receive more money from Social Security when I retire (due to maxing out the contribution limit each year) than the teachers in the top pay scale at my local district will receive from CALPERS. And because of the double-dipping penalty in the Social Security formula, they'll never make more combined pension and Social Security than I get from Social Security when I retire.
Really, with a disrespectful and ignorant attitude being the norm, why *would* I want to teach? So people like you could spit on me for doing a job that's ten times harder than software engineering? Been there, done that. No thanks.
I am wondering what in the world you are talking about. During the three years I was teaching, a) my highest salary was the munificent sum of $21,800 per year (roughly $40K/year in today's dollars), b) I paid 100% of my health insurance costs (NO district subsidy of the cost), and c) the retirement benefit was 40% of my ginormous salary if I managed to survive 30 years without stroking out, being knifed or shot by one of my students, or being thrown under the bus by a school administrator upset that I cared about whether my students learned or not (and note that I did NOT pay into Social Security and if I had managed to get Social Security via some other job, there's a "double dipper" penalty in the SS formula that would take most of that away from me). In the years since I switched to doing software engineering rather than teaching mathematics I've sometimes worked 60+-hour weeks and multiple all-nighters but never worked anywhere near as hard as I worked as a teacher and get paid more than three times as much money than a teacher. If you paid me the same six-figure salary I make as a senior-level engineer I still wouldn't go back, because the job is thankless, never-ending, and utterly exhausting both physically and intellectually if you're doing it right. My hats off to those teachers who stay on the job and do it well, year after year, because the fools who criticize such teachers have not a clue.
BTW, once you get above 35 students in a classroom, it becomes simply impossible to manage in a way conducive to learning. Above 35 students learning starts dropping off rapidly, past 40 it's just baby-sitting and make-work. Teachers know this the hard way. The fact that politicians and parents talk about 40+ student classrooms as if that were some reasonable solution to the cost of running public schools tells me that either a) they don't care about education, they just want free babysitting to keep kids off the streets, or b) they're clueless cretins who need to be drummed about the head with a clue stick. That is all.
Perhaps Media Molecule should think about hiring some of the 50%+ of UK Computer Science graduates who cannot find a job in the field? When I see statistics that say that 70% of Computer Science graduates are not working in the field five years later, I call balderdash on the notion of a shortage of software engineers in the UK. If Media Molecule truly believes that 50%+ of UK Computer Science graduates are unqualified to write software, it sounds to me as if their beef is with the universities that credential people not worthy of said credential, not with anything happening at the primary school level.
I saw my first computer at age 17. I've been making a living writing software or doing other related things for over 20 years now and while I'm no Linus Torvalds, I still don't have any problem finding a job when I need one and making significant contributions everywhere I go. What differentiates those who will be good at writing software from those who will never be has nothing to do with how young you are when you encounter computers, and everything to do with your ability to think in a logical and straightforward manner. I would much rather see our schools teach thinking skills than computer skills. Thinking skills are useful for other things (say, in figuring out which politicians are lying to you and thus you should vote for the one *not* lying to you, for example), while skill writing computer programs is useful only for a small set of problems. I don't write algorithms to go grocery shopping or change the cat box. Just sayin'.
One thing I'll note is that MIT MACLisp had a functional compiler that compiled all the way down to machine code before most of Slashdot's readers were born. The original MIT Multics Emacs was written in MACLisp, I looked at the resulting ALM (Assembly Language Multics) from the compilation process for a few functions just to see how well it compiled, and it was pretty close to the output I saw from the PL/1 compiler, which had an excellent optimizer for that era. There's nothing inherent about Lisp that makes it impossible to compile and optimize, Bernie Greenberg and David A. Moon certainly proved that.
That said, I'm of the opinion that the age of extension languages embedded into applications is over. The extension language paradigm explicitly limits the extension language to manipulating a single application, when what we have open on our modern desktop is dozens of applications and we'd like to create something new from all of them. What is needed, instead, is a universal interface exported by applications to use to script applications. Think Windows PowerShell rather than Emacs Lisp -- the shell lives outside the application and calls a defined application API to perform actions. SOAP/XML-RPC/REST are far more important to the future of scriptability than some archaic concept from the 1960s and 1970's, if I implement one of those interfaces to the core functionality of my application I can write my extensions in *anything* -- Perl, Java, Python, you name it. The problem of course is that SOAP/XML-RPC/REST are also horrendously inefficient, surely we can do better than marshalling and demarshalling everything to/from XML or JSON. Still, I present this as a conceptual thought -- though I might point out that the Amiga *almost* managed something similar with AREXX (theoretically it was possible to use the "AREXX port" to control Amiga applications from other scripting languages, though it was rarely done).