By that theory, you should be able to hop into a plane without any training and just fly wherever you want, too.

You have the right to travel: on foot.

By that argument, we should have a serious shortage of mathematicians since the invention of the scientific calculator.

We should also have a lot of bookkeeppers and no accountants.

Automation reduces the "grunt work"; it does not remove the need to think. If your job can be accomplished purely through the "grunt work" done by something like http://msscodefactory.sourceforge.net/ without you having to do any customization work or handle any special cases that aren't automated, you were never a real programmer to begin with, and your project was a joke in the first place.

When an SSL or HTTPS connection is established, the existing RSA key is used to negotiate the connection, but a connection-specific key is generated and shared over the RSA-keyed initial connection. It's that generation of the connection-specific key that is compute-intensive. If I recall correctly, that secondary key is usually done using a symmetric algorithm that can be processed faster than AES encryption can be, with the caveat that it requires sharing the key, so it can only be safely used if the initial communication of the key is secure and the key is discarded after the connection closes.

It isn't all that many years ago that the floating point was handled by either software emulation or a co-processor. Now we're using GPUs as co-processors. There are also audio designs that act as co-processors. Several enterprise systems have encryption co-processors. IBM is notorious for putting specialized processors in their mainframes. Several chips have the GPUs embedded on-chip already.

I'd argue that putting specialized chips on-die doesn't affect the general-purpose nature of the compute core that controls those resources at all. The whole article is red herring trying to establish a distinction between on-chip and off-chip processing that has to do more with the scalability of silicon manufacturing techniques than it does any distinguishing feature of the designs.

Let's face it -- if you want to really accelerate a task, you design silicon specifically for that task and interface it to a general purpose core. The article discusses nothing new in the world of computing.

And your point would be?

We're talking about APIs here -- the interfaces. The source code compatability layer.

GNUstep is therefore compatible within the context of the discussion, regardless of Apple's implementation of those APIs.

I miss the good ole' days when Slashdot was about technology, not navel-gazing bullshit about American politics and policy. :(

Most of what I read on Crapbook is still text written by friends. Most of them don't even post camera-phone pictures of what's going on, never mind take videos.

Zuckerberg overestimates the ease of creating videos and uploading them to any service. Even if it were easy, people still don't tend to be taking video of what's going on in their lives. They're too busy living their lives to play videographer.

Telling someone to come here for a sec so you can take a "selfie" together is no big deal. Sitting on the sidelines and video taping the party that's going on would be rude and would take you out of the social scene while you're recording it.

Damned kids.

A personal computer could be an Atari, an Amiga, a DOS box, a Sun workstation, ....

You overestimate the flexibility of the hardware. You have pushbuttons, sliders, and meters available for use in the control panels. You have a primitive scripting language for assigning those controls to specific wire ports/devices, and the crudest forward/backward navigation buttons you can imagine.

If you think you're going to get a powerful and flexible tool you can extend and embrace from the manufacturer of a home automation hardware platform, you've got another think coming.

The more flexibility and power a language provides, the more opportunities you have to hang yourself with it.

Personally what I hate are loosely, dynamically typed languages. They provide no compile-time checking at all that I can detect, which means that in order to even guess whether the code is "correct" you have to run through all the possible use cases. I realize that it's an ideal to test all possible inputs (especially boundary conditions), but that just isn't practical for most project schedules and budgets.

As powerful as functional languages can be, the restrictions imposed by them can lead to difficulty implementing certain behaviours in the code. In fact, one Erlang project I worked on proved to have such an extreme difficulty implementing an algorithm that we had to cancel the project, even though the rest of the project had been completed. (That function was *the* heart of the system: the scheduling algorithm>)

Much as the researchers discovered, I've never really found the programming language itself to have much of an impact on the code quality or readability of the code if the code was competently written. That said, even the best of languages can be turned into unmaintainable gobbledygook by a dedicated bonehead, especially consultants who know damned well they'll be long gone before the project enters maintenance/enhancement mode.

What I found really degrades quality is not the language, but an overemphasis on code style at some companies. Instead of code reviews focusing on the functionality of the code being reviewed, they spend all their time nit-picking about variable names and whether to use camel-case or underscores.

I consider the maintainability and readability of code to be at least as important as any metrics about the number of bugs in a project. If you can't read and understand the code easily, fixing a bug when it is discovered becomes a hellish nightmare.

I programmed an automation system for a 1.5 million dollar house a few years back. The owner spent gobs of money running extra wiring from every light, outlet, and socket to the central control circuit panel that ran most of the functionality. They sprang for 4 CAT6 lines to each room, with a fiber drag to supplement "future expansion", all of which ran to a router in the basement (Cisco, no less) and to a PBX system.

After the whiz-bang wore off in a month, the owner really regretted spending close to $150,000 on the automation. In the end, the only thing even his wife really liked was the automated drape controls and the cameras monitoring the property. All the fancy light dimmers and thermostats were more of a pain to use and set up than their analogue counterparts, and the remote was so complex that they didn't use it at all because it was far easier to just walk to the wall controller and use that.

Automation has always been more of a whiz-bang for a select few than a real necessity for anyone. For the most part, having tri-wired switches with switches at each of the two entries to a room is more than adequate for "automation."

The owner's kids absolutely hated the automation -- it was impossible to sneak in late at night without all the lights coming on and alerting Mom and Dad to just how late it was when they got home. :D

Yes, because responding to a line of the summary is clearly "off topic". *LMAO*

I could see rating my post as "troll" for the inflammatory language, but "off topic"?

How much more "on topic" does one get than responding directly to the summary or article?

What the hell is with people thinking they can dictate what kind of responses they get to summaries lately?

People will post what they post, regardless of your control-freak fantasies of filtering out the chaf.

The biggest clue shortage on the hiring side is requiring x years of experience with a tool or product that has only been out for less time than they're demanding. I've lost count of the numbers of times I've seen such asinine job posting requirements.

Another good clue shortage is expecting x years with one product, y years with another product, and z years with a third, while specifying that it's an intermediate position. Make up your mind -- either you want someone with only 5 years of experience or you want someone who's spent time with the tools you're requesting -- the two are mutually exclusive!