I've seen occasional questions about IFTTT security issues (link, link, link), but nothing that isn't theoretical or speculative. Seems like there are a lot of avenues for compromising your network security and privacy. I'd love to see some hard facts about IFTTT security.

I bet one of those AIs would pass a Turing test—and not the one that can win at Jeopardy or beat a Go champion.

WARNING: If you're "still" using a computer that's more than 2 years old because its good enough, this post may male you feel like you made the right decision.

Sad? No, this is sad. I would love to buy a new Apple (I need a laptop, and I need to stick with Apple because of various constraints). Unfortunately, they won't sell me a new one that's much better than my "sad" old one.

I started looking for a replacement for my 2012 MacBook Pro a few months ago, fully expecting to buy myself a performance boost. I couldn't believe that Apple simply doesn't make a laptop that's significantly faster than my four year old computer.

Here's the benchmark for my 2012 MacBook Pro: http://browser.primatelabs.com/geekbench3/4933459

Compare that with the results from recent MBPs: http://browser.primatelabs.com/mac-benchmarks

Wow. It's four years later and I still can't buy a significant performance boost from Apple. The best I can do is an almost unnoticeable bump in speed.

Maybe more people would stop using "sad" old computers if Apple gave them a compelling reason to upgrade.

Annoying? Only like someone who never had a boot sector virus wipe out half their files because it detected it was the 26th of the month would dismiss DOS viruses as "anoying". Or, worse, someone who never had to work on a support desk when that happened.

Or someone who's only lived in a time when all computers are networked, so backing up a hard drive doesn't involve swapping 3.5" (or 5.25"!!) floppies in and out of your machine for half an hour, or waiting two hours for your tape backup to finish.

Annoying? Ha.

I think git can meet all of your needs, and personally I love it.
- It's a free, well-established, and well-documented open source project.
- There are plenty of GUIs.
- For inexperienced developers, there are tutorials like this one.
- Here's decent guide to getting password-less authentication via ssh working on Windows to connect to a server running locally on a Windows box (as long as it's running OpenSSH, maybe via cygwin).
- You can use Git hooks to do notifications, run syntax checks, etc.

For those who don't know, COCOMO is an algorithm that was developed in 1981 by Barry Boehm for estimating the cost of building software (typically in person-hours). The numbers in the article were generated by the basic COCOMO calculation in David Wheeler's free SLOCCount toolset.

One drawback is that SLOCCount uses the basic COCOMO calculation, which is based on historical data gathered by Boehm in 1981. Here's a COCOMO-81 calculator in case you want to play with your own code. Sometimes its estimates are pretty good, but I've sometimes found that applying line counts from my projects in some modern languages (especially functional ones like Scala) throw it off. That could definitely affect the "1,356 developers 30 years" estimate in the article.

Wheeler has a good discussion of COCOMO in SLOCCount if you want to learn more about it.

How to fake fingerprints, in case you want to know what to do with them.

Search your favorite job postings website for project manager jobs. Ten out of ten of them will say that a PMP certification is either required or preferred.

A few reasons employers look for a PMP certification: a) several years of professional project management experience are required in order to qualify to take the exam, b) it shows a certain level of commitment to furthering one's career as a project manager, and c) if someone has taken and passed the PMP exam, it means they're at least familiar with standard project management tools, techniques, and practices.

Tom me, those seem like reasonable reasons for adding the PMP certification as a requirement for a project manager job posting. But it definitely means that if you want to move your project management career forward, you should really consider the PMP certification.

Are 'config t' and 'write erase' too difficult to remember? Bothered by all those inconvenient keystrokes? Try the new EasyBoot(TM) from Cisco, the most convenient way to reset your router!

I know a lot of us like to blame people for their own problems, but in this case he knows it's his own fault—which, to me, makes the whole situation even more sad and awful. I feel really bad for him, and I hope he can find a way to come back from this.

From TFA:

“I look around my house and see images of my son and feel such intense shame and crippling sadness,” Pranger wrote on Facebook. “I know that if I can’t find a job at least as good as this one, I won’t be able to provide for my family I’ve lost them their health coverage and their security. I also know that I’ve probably lost a good deal of my friends, just because I know how hard it can be to stay in touch with someone when the convenience of proximity is lost. I’m so sorry to everyone. I’ve failed you. You believed in me and supported me and trusted me and I’ve failed you. I’ve failed me.”

Last time this project was posted here the lead researcher on the project answered questions, including addressing why they developed their own external language rather than using C/C++/Java/Python:

A. Robot swarms are a special kind of system. It's not just a collection of computers (like a network would be), but a collections of autonomous devices that occupy space and form networks with very volatile topology. Sure one could use C/C++/Java/Python to program them, but it gets fast very complex, due to the large number of interactions among robots. We believe that it's much better to have a language that natively provides you with the right kind of abstraction, and hides whatever is not necessary for swarm-level coordination.

And also, another reason:

In brief, we found no language with the features we wanted that would fit

Most animals don't live in a society, so the concept doesn't apply. Animals that do live in a society do have social justice ("justice in terms of the distribution of wealth, opportunities, and privileges within a society"). Some animal societies (eg. bee colonies) do a lot of resource sharing. It's not hard to see why this would be a useful group behavior to evolve.

You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s. :)

My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulation; you can't interpret the meaning of it until you have its context, in the form of a scope (or stack frame, etc.).

Symbolic manipulation versus semantic meaning is really important when you're proving things like computability. I remember back in a graduate mathematical logic course, we used only formal logic to prove some complex fundamental theorem of calculus—but the meaning of that theorem was completely irrelevant, we did the proof entirely through symbol manipulation. So we were able to derive the proof syntactically, without any of the calculus semantics. Not sure if that helps illustrate the difference. Like I said, it's been a while since I studied this stuff. :)

From a more practical perspective, this matters a lot when doing compiler optimization. When you use an anonymous function—where "anonymous" literally just means "doesn't have a name"—a typical compiler will do all sorts of optimizations. I see this a lot when doing .NET programming: if you have an anonymous method that has the same contents as a named method, the C# compiler will just call it, or if the anonymous method is only called once, it may just embed it directly into the calling method, etc. (You can actually see this yourself by writing some code, compiling it, and using ildasm to look at the byte code.) Capture is really important here: this won't work with a closure, because it has the scope. However, a lot of times something that looks like a closure doesn't actually require the scoped variables, or they can be passed in as references, so it can be compiled into an anonymous function.

I've been doing a lot of Scala programming lately, and it's done a lot differently behind the scenes in Scala—and the delineation between anonymous and named is a lot more blurry from a compiler perspective. If you define a Scala function:

object MyScalaObj { runAFunction(f: Int => Int) { println(f(3)) } }

this looks a lot like it takes as its f parameter the kind of method that's compiled into a compiler-named anonymous method. But Scala is bytecode-compatible with Java, so this is actually done on the object level—you can pass it an instance of an object (in this case, an instance of scala.runtime.AbstractFunction1):

static Function1 FunctionObj = new AbstractFunction1() {
      @Override
      public Object apply(Object i) {
            return (Integer)i + 6;
      }
};

and call it like this from Java:

MyScalaObj.runAFunction(FunctionObj);

So when the Scala compiler compiles an anonymous method, it generates an object like FunctionObj. The reason this is relevant is because what looks anonymous to Scala is actually not just a function with a stack context, but in fact an actual object on the heap. This is about as far from a literal function as you can get.

And now you know why I thanked Bob Harper in the preface to my most recent book. :)

Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.

So higher level function would return a closure value, which would be the function bound to the values in scope. Those aren't the same thing as anonymous functions. For example, they could all be reusing the same anonymous function—that function might be compiled into one location in the assembly or bytecode (if it's .NET bytecode, for example, it might have a generated name like "b__0"), and then called from within scope.

A composed function would generate another literal function valuelike if you have two functions F and G and compose them into lambda(i) => F(i) + G(i), then that lambda would return an anonymous function. But if you assign it to a variable and call it, then it's bound to a scope and becomes a closure.

Make sense?

Minor apologies for being a bit pedantic, but just in case anyone's confused by the possible misuse of the term "closure" in the summary...

From the Wikipedia entry on closures:

The term closure is often mistakenly used to mean anonymous function. This is probably because many programmers learn about both concepts at the same time, in the form of small helper functions that are anonymous closures. An anonymous function is a function literal without a name, while a closure is an instance of a function, a value, whose non-local variables have been bound either to values or to storage locations (depending on the language; see the lexical environment section below).