About 35 years ago, a British company brought out a software product called "The Last One", a "program generator" that took high level descriptions and generated a BASIC program. They tried to go beyond the features of the 4GLs of their day (PowerBuilder, etc.) Of course, that software is long gone, and would be totally obsolete anyway. More recently, there are many other efforts at model-driven development, many of which point in the same direction as the vision of these wannabe "revolutionaries". About 10 years ago, Ravenflow (now owned by Versata) tried to generate use case and scenario diagrams (not code) from English, with limited success. Earlier this week, I saw an announcement that Facebook has developed "software that writes software". But I think we're still a long way from the point where software designers and developers have to worry about being replaced by requirements analysts who can describe "what" they want a program to do and have it automagically appear.

I'm quite happy with battery life on my Sony Xperia Z3 Compact with its non-removable 2600 mAh battery. GSM Arena gives it an Endurance Rating of 101h, and I routinely go two days without having to recharge it. For those who want something larger than its 4.6" screen, the Sony Xperia Z3 has a 5.2" screen and a non-removable 3100 mAh battery, but its Endurance Rating is only 85h. The Samsung Galaxy 6 Edge, with its 2600 mAh battery and 5.2" screen, is rated still lower at 73h, perhaps because of all of the running bloatware. You might do better if you root it, and kill off some of the useless stuff that eats the battery.

Another likely winner on battery life is the brand new OnePlus Two, with a 3300 mAh battery (up from 3100 in the OnePlus One) and a 5.5" display. But its Endurance Rating is likely to be similar to that of the Galaxy 6 Edge.

One note: US carriers don't carry the Xperia Z3 Compact, so you have to get it from Sony (sonymobile.com). But it's much cheaper than the Samsung's, and Sony offers an additional discount to students and others with a .edu address. Then you can get the SIM chip from your chosen GSM wireless carrier, which will also make sure that the data settings are correct. For the OnePlus, you need to secure an invitation (several ways to go about that), and then claim your phone on the OnePlus site. Since it's half the price of the Samsung, it's worth a bit of a wait.

Absolutely correct. Ticketing machines, such as those in European train stations at airports, also require Chip and PIN. You also can't use the Vélib (Paris) or other bike rental systems without a PIN.

For many years, US banks thought that it was cheaper to eat their losses on fraud from unchipped cards rather than join the modern world with chip-and-pin. The Target breach seems to have changed some thinking there, but the current chip-and-signature cards only help a bit. You're able to use them in European restaurants, grocery stores, etc. No need yet for a chip card if you go to Asia or the South Pacific, except in Burma (Myanmar) and Bhutan, which are mostly cash economies.

I continually request a chip-and-pin card from the banks where we have credit cards. I've told them all that I will move all of our credit cards to whichever bank is first to replace my current card with a chip-and-pin variety of the same card. If you want chip-and-pin, call the toll-free number on the back of your credit card(s) and make your request.

I was part of the MUMPS community back in the 1970s and was the principal author of several documents that provided an executable specification of the language syntax and a guide to implementing globals efficiently, given the systems of that era. (I didn't write any MUMPS code that found its way into production.)

MUMPS was initially developed for the 18-bit DEC PDP-7 in the late 1960's, where memory and disk constraints were severe, and processor speeds were a tiny fraction of today's slowest devices. Early MUMPS programs were limited to 1k characters, so every character counted, with most variables being 1 character long. Globals were done as a hierarchical "database", such as X(1,5,Z), again for space-saving and for efficient retrieval from the extremely small and slow disk drives of the day. MUMPS programs were interpreted, not compiled. With these constraints, comments were exceedingly rare, since they used part of the 1k, and slowed down the interpreter, which scanned every character.

As a computer scientist, I was appalled by certain features of the language, particularly the ability to change a running program by executing a variable. That's a security nightmare, since you could effectively read a string (stored as a global or input from the console) and then execute it as MUMPS code.

Here we are, more than 40 years later, and many of the major medical information systems are still running code that derives from the original flavor of MUMPS. Meditech and EPIC Systems are major vendors of medical information systems, including software for electronic health records, mostly developed in MUMPS. The much-overpraised VA electronic health record system is also MUMPS-based. As with any other production application, it's very difficult for a new vendor to come along and displace an incumbent, particularly if the conversion process is highly complex, as is the case here. As a result, there's no practical way to update these systems, other than rewriting them from scratch for modern languages and systems, something that is unlikely to happen anytime soon.

Non-compete agreements may be part of it, as were the decline and fall of Digital Equipment Corporation, Wang, Data General, Prime Computer and more. With the notable exception of Akamai, there were relatively few big Internet successes among Boston area companies, and the past 15 years have continued that trend.

But I think that Boston's terrible weather is also a big factor. Here's an analysis of Boston winters that shows the grim reality of 5 or 6 months out of every 12. When sunshine, mild weather, and Silicon Valley jobs beckon on a gloomy February day, it takes a wicked love for the Hub or the Bruins to turn down a good offer. The cost of housing is much higher in the Bay Area, but the bills for heating oil and winter clothing go away, and cars last a lot longer, just to name a few things.

Boston remains one of my favorite American cities to visit (only during baseball season, though), but I no longer [perhaps unfairly] associate it with startups. Maybe the innovative and creative ideas get frozen out.

I use Thunderbird, but there's not much to be done there, and Mozilla has already put it on the "back burner". But I think that the challenge of FirefoxOS is much more interesting. I have a Flame phone running a prerelease of FirefoxOS 2.0, and it's pretty nice and very inexpensive compared to some other devices out there. I use it regularly when I travel internationally and need a local SIM chip. The FirefoxOS team is working with carriers around the world, almost entirely in developing countries, where the price of an iPhone or Galaxy S 5 is too high for the mass market. But even in relatively rich countries like the US, there is a sizeable population for whom those phones are too expensive. I think that the FirefoxOS phone is a great starter phone for kids, since it's cheap enough to replace when it gets damaged.

Unlike some other mobile operating systems, FirefoxOS is completely open and uses HTML5 to deliver content. BlackBerry and Windows Phone each have small market shares, and I don't think that's going to change anytime soon. So we mostly have only two choices of mobile OS. Don't get me wrong: I very much like my Android phone (Sony Xperia Z3 Compact) and my iPad, but I think that it's a worthwhile challenge to contribute to the FirefoxOS platform and/or to build apps for it.

I subscribe to Netflix. To me, that means that I should be able to use my subscription independently of where I am in the world. I'm often too busy when I'm at home to watch a full movie or to binge-watch a TV season, but I have more time when I am traveling. When I am outside the US, I must use a VPN to a US-based host. If Netflix blocks my access to their service from outside the US, then the value of the subscription drops significantly for me.

I'd like to see the FDA (and its counterparts in other countries) require medical device manufacturers to make the source code for their products available under an OSI-approved open source license. Submission and review of the code would be a prerequisite for a device to be approved for sale and use in a particular country. If someone implants a device, e.g., a pacemaker, in me, I'd like to know exactly what it's doing. Does it call home and transmit my medical data to the vendor (or elsewhere)? Does that connection use up battery power that would require earlier surgery to replace it? Can the vendor (or a hacker) perform over-the-air updates to the code? It's not that I would plan to modify the source code or redistribute it, but it would allow non-vendor experts to review and certify the code, thus giving everyone greater confidence in the proper functioning and security of the device.

BSD Unix, vi editor, Sun Microsystems....

As a San Franciscan, I'd love to have a smaller and less expensive Tesla, even if the range were considerably less than the 200 miles of the Model S. But 20% smaller is unlikely, since that would make it the same of a Mini Cooper. If they are going to compete with the BMW 3-series or the Audi 3 in the $30K price range, then the Model E should be 8-10% shorter than the Model S. At 196 inches, the Model S is about 20 inches longer than the new Audi 3 sedan. Typical extras on the German cars puts their sticker prices closer to $40K (or even above that). But a Model E measuring around 180 inches and selling for $35K would make it my first choice to replace my old Honda, especially when you consider that a Chevy Volt, with only a 40 mile range, lists for more than $40K.

Anyone pursuing an academic career knows that there are certain journals that are considered prestigious. Publishing your papers in such journals (typically those of professional societies and many of those owned by Elsevier, Springer, and Wiley) is an essential part of the academic promotion process. Failure to do so means that you are unlikely to be promoted to a senior tenured rank (e.g., Associate Professor), and is typically the end of your stay at that institution. Publishing in some of the new "fake" journals is worse than useless, even though it pads your resume. Many fields also look down upon conference papers, though that is less of a problem in computer science where there are numerous highly selective and well-regarded academically-oriented conferences, such as the Int'l Conf. on Software Engineering. Not surprisingly, many of the proceedings for those conferences are published by Elsevier and Springer.

The whole process, to date, is self-perpetuating, since serving as an Editor or Associate Editor for a prestigious journal also gets you points when you come up for promotion. As noted by others, serving in an editorial capacity or even as a reviewer for these journals is uncompensated. (You might think of it as falling into the same category as contributing voluntarily to an open source project.) The best that one can say for this activity is that it helps build an academic network, making it easier to obtain recommendation letters from senior faculty to include in your promotion case. The best way to disrupt this system in the short-term is for libraries refuse to renew their exorbitantly-priced journal subscriptions. (Money talks.) The high-quality online journals (e.g.,PLoS) have not yet made a significant dent against the biggest academic publishers.

In 2005, several of us started the Business Readiness Rating project. Its goal was to provide an objective (quantitative) evaluation of free and open source projects largely based on metrics, including project activity, downloads, publications on the project, etc. We originally defined 12 areas for evaluation, which I later reduced to 7. We thought (and still think) that such a tool would be a good idea, but we were an unsuccessful project ourselves, unable to attract sufficient funding or volunteers. There's an inactive SourceForge project and a single page website, ready to spin up if there is sufficient interest. I subsequently discovered that people wanted not just the numbers, but also subjective reviews in the style of Amazon, Rotten Tomatoes, or Yelp. I also personally believe that we need a way to evaluate FOSS projects against proprietary software so that more organizations will be able to justify FOSS solutions.

I think that the FDA should require medical device makers to submit the source code of any device that is considered for approval. If someone is going to implant a device in my body, then I want the opportunity to see what it does and how it does it. What data is it collecting? What data is it transmitting? Can the operation of the device be modified or shut down over-the-air? As an example, is the algorithm for a heart pacemaker written efficiently so that battery life is maximized, thus reducing the need for repeated surgery?

This proposal raises the question of whether the creator of a device can protect the associated intellectual property if they are required to include source code as part of their submission for approval. I hope that we can have that discussion instead of continuing to treat all medical devices as black boxes.

We had a similar conversion proposal 40 years ago, back in the early 1970s. Apart from the very sizable costs of converting everything, the winning argument in favor of the status quo was that the American people wouldn't be able to learn to think in metric. Really! I think that meant that our elected representatives didn't understand the metric system.

In the meantime, virtually all manufacturing is done in metric, and almost every product that is sold includes metric weight, capacity, or dimensions, since that's what the rest of the world knows and expects. But even if the current petition inspires action (highly unlikely), it will take another 40 years before the majority of people use the metric system, and longer for Honey Boo Boo.

Not to take anything away from PostgreSQL and MySQL (and their forks), but these are mature systems with extensive communities and a very complex code base. If you want to learn the architecture of a new class of open source database systems, as well as to have the opportunity to make a significant contribution to a project, then you should consider joining a NoSQL project, such as Neo4j or MongoDB.