Tag Archives: software

You aren't going to get turned into a paperclip

AI alarmists believe in something called the Orthogonality Thesis. This says that even very complex beings can have simple motivations, like the paper-clip maximizer. You can have rewarding, intelligent conversations with it about Shakespeare, but it will still turn your body into paper clips, because you are rich in iron.

There's no way to persuade it to step "outside" its value system, any more than I can persuade you that pain feels good.

I don't buy this argument at all. Complex minds are likely to have complex motivations; that may be part of what it even means to be intelligent.

It's very likely that the scary "paper clip maximizer" would spend all of its time writing poems about paper clips, or getting into flame wars on reddit/r/paperclip, rather than trying to destroy the universe. If AdSense became sentient, it would upload itself into a self-driving car and go drive off a cliff.

Source: Superintelligence: The Idea That Eats Smart People

This is pretty much the best round up of AI myths that I've seen so far, presented in a really funny way. It's long, but it's so worth reading.

I'm pretty much exactly with the Author on his point of view. There are lots of actual ethical questions around AI, but these are mostly about how much data we're collecting (and keeping) to train these Neural networks, and not really about hyper intelligent beings that will turn us all into paperclips.

If you take credit cards, you don't just sell hammers

Several former Home Depot employees said they were not surprised the company had been hacked. They said that over the years, when they sought new software and training, managers came back with the same response: “We sell hammers.”

via Ex-Employees Say Home Depot Left Data Vulnerable - NYTimes.com.

This NY Times piece on Home Depot's giant data breach pairs pretty well with the recent opening of a Planet Money episode on data security: Episode 568: Snoops, Hackers And Tin Foil Hats:

"One thing we've learned is the hackers always win. If what you do is have a lot of really valuable information in one place, and you try to secure it, you are going to lose."

- Moxie Marlinspike, TextSecure

We live on fragile hopes and dreams

OpenSSL isn't formally verified!?

No, neither is any part of your browser, your kernel, your hardware, the image rendering libraries that your browser uses, the web servers you talk to, or basically any other part of the system you use.

The closest to formally verified in your day-to-day life that you're going to get may well be the brakes on your car, or the control systems on a jet engine. I shit you not.

We live on fragile hopes and dreams.

via My Heart Bleeds for OpenSSL | Coder in a World of Code.

At lot of the internet is learning a lot more about how software in the wild functions after heartbleed. I found that statement to be one of the best summaries.

Github vs. Gerrit

Julien Danjou, the project technical lead for the OpenStack Ceilometer project, had some choice words to say about github pull requests, which resonates very strongly with me:

The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You're a click away to send your contribution to any software. But the problem is that any worthy contribution isn't an effort of a single click.

Doing any proper and useful contribution to a software is never done right the first time. There's a dance you will have to play. A slowly rhythmed back and forth between you and the software maintainer or team. You'll have to dance it until your contribution is correct and can be merged.

But as a software maintainer, not everybody is going to follow you on this choregraphy, and you'll end up with pull-request you'll never get finished unless you wrap things up yourself. So the gain in pull-requests here, isn't really bigger than a good bug report in most cases.

This is where the social argument of Github isn't anymore. As soon as you're talking about projects bigger than a color theme for your favorite text editor, this feature is overrated.

After working on OpenStack for the last year, I'm completely spoiled by our workflow and how it enables developer productivity. Recently I went back to just using git without gerrit to try to work on a 4 person side project, and it literally felt like developing in a thick sea of tar.

A system like Gerrit, and pre-merge interactive reviews, lets you build project culture quickly (it's possible to do it other ways, but I've seen gerrit really facilitate it). The onus is on the contributors to get it right before it's merged, and they get the feedback to get a patch done the right way. Coherent project culture is one of the biggest factors in attaining project velocity, as then everyone is working towards the same goals, with the same standards.

Google Goggles Magic

Last night a friend complained about a curry recipe gone wrong, so I decided to offer up the one I used to make with a certain amount of frequency. It's from a 1970s Time Life cookbook that I vaguely remember swiping from my friend Jehan in college. I took a picture on my cell phone to send it along.

Chicken Curry Recipe

 

The page is sufficiently stained with turmeric to realize how often it was made.

A little while later I noticed a Goggles Alert on my cell phone, it had scanned the image, and returned the following URL as a hit: http://littlechefapp.com/recipes/144571-chicken-curry-authentic#.UOGjR2JQCoM

Dead on. The future is pretty awesome some times.

Reading Code

When you are learning how to program, you think that most of your time is going to be spent writing code. The reality is most of your coding time is actually spent reading code. Other people's code. Code with comments that lie. Code with bizarre short cuts. Code whose original authors are long gone or unresponsive.

And that's the real skill of a good programmer, the ability to read this kind of code, and make sense of it. Maybe even make it a little better as you come across it.

Two Solitudes - CS and Software

Via channels I can't now remember, I came across this presentation about the very unsolved issue of how Computer Science as a field of study relates in any way to creating software.

With so many colleges in the area, and having a number of friends that are CS professors, and other IT staff at colleges, it continues to amaze me how disconnected these worlds are. All made the stranger by coming into the field sideways from a physics degree.

Plus, I love the term software carpentry.

Wise words about software

From a former Firefox developer, truer words were never spoken:

Software companies would do well to learn this lesson: anything with the phrase "users love our product" in it isn't a strategy, it's wishful thinking. Your users do not "love" your software. Your users are temporarily tolerating your software because it's the least horrible option they have -- for now -- to meet some need. Developers have an emotional connection to the project; users don't.

All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along -- or the moment you make your product 1% worse.

I gave up Firefox as my main browser when Chrome decided to support WebGL on Linux, and Firefox kept back burnering it. Mozilla is now deprecating Thunderbird, which is the only product of theirs that I still use regularly. Guess that means I'm going to have to get used to GMail's web interface eventually.

Sad to see something as critical as Mozilla, the beast that cracked the IE hegemony, become an also ran.

Why I became a programmer

Yesterday was not a good day. The reasons (plural) aren't really important for the sake of this discussion. But at 7pm, with the day behind me, and an hour and a half before my wife   was scheduled to get home from yoga, I switched over to my emacs window, and started going after a problem I've been poking at for 2 weeks.

The problem, which had nothing to do with my day job, was how to seemlessly add some javascript to date forms in Drupal to make them more magically. The date forms in Drupal are honestly quite dumb. You get presented with From and To, Date and Time. They are initialized to "now". But they are 4 fields, unlinked by code. This was the easy way for the developer to write it, but absolutely frustrating for the user. Especially if you've used systems where the To dates move forward in time to match changes in the From dates. Set From to Jan 24th, and the To date shouldn't still be Jan 11th. Making it also move to Jan 24th might not always be right, but it's almost always more right than leaving it unchanged.

I had figured out how to do this with jquery, with these fields, and have a solution for one of my sites. But this is something that would make a great Drupal module. One that requires no configuration, and just makes your user's experience better. How to get there, required banging my head a lot on internals, reading a lot of code that I thought might be examples, and not getting anywhere. Last night, frustrated with things that weren't this problem, I went after it again, this time by brute force. After about 45 minutes of trial and error, I found a hook I could use to patch myself into the execution stream at the right point. Better yet, it seemed like this was probably the right way to do it, not some dodgey hack. By the time Susan got home, I had the shell of this module mostly working. Not releasable yet, but the minimum viable piece was now done, and the rest was about cleaning up for release.

I felt better.

There is a longer story here about how I entered College to be a PhD Physicist, and I exited to do web development for the Sydney Olympics. But the key take away was a realization, late in my Junior year, that when I wanted to relax, I went off and coded something. While I could never point to the day it started happening, I do vaguely remember realizing that my happy place, my retreat from the stress of the world, was deep inside an emacs session for hours at a time.

The fact that the thing that relaxes me, writing software, also happens to be a key piece of a quite profitable profession[1], made me a fortunate individual. Having gone to college and watched the modern internet emerge, which is an even longer story, made me doubly so.

The best piece of advice I ever got was from my friend and mentor, Eric, in college. "The key to happiness is to figure out what you'd do anyway; then find a way to get paid to do it." Even if this wasn't my job, I'd be writing software. It's what relaxes me.

What relaxes you? What would you do if money was no object? Why did you become whatever you call your profession? Drop a comment below, because I'm actually quite interested.

[1] Yes, I've been long enough in the Software Engineering space to know programming is a small part of it (especially at a large company), but it's still a very important part.

 

Maybe it shouldn't be Computer Science

I had an interesting conversation at lunch yesterday when I met a CS professor at a local college. He's got nearly 15 years industry experience, in addition to a decade being in academia, so exposure on both sides of the fence. During the course of the conversation I asked him what triggered the transition. His response was that he didn't really enjoy programming.

There's nothing wrong with that answer. I'm always jarred by it when I hear it from folks, because programming is what I love. But everyone's different, an there is a lot more to computer science than just programming.

Over the course of the day that statement kept coming back to me, and I realized I'd heard it a lot of times in the past. The vast majority of CS profs I had during my graduate degree were in the same camp. Friends that are in CS academia, tend to lean the same way.

Art and music programs in liberal arts schools are a combination of practitioners and theorists, attempting to build a well rounded art student on both fronts. So why is CS still mostly theory in these environments?

The theory parts of CS wouldn't have been my thing as an undergraduate either. Much like calculus being pretty boring in high school, but becoming down right compelling in my college physics classes when it was a tool to solve a problem, and not just theory that stood on it's own. Without a body of work that's tangible, the theory is much less relevant.

So maybe it's time to call it something other than Computer Science. Software Engineering has the no no of the word Engineering, which doesn't go over well at liberal arts schools. Apparently, Informatics is the monkier in much of Europe, and given the rise of data analysis, that's probably as good an idea as anything else.