Somewhere I recently heard someone say something like, "Programming is easy; all the interesting problems have already been solved by mathematics." I was a bit taken aback by this at first, but it got me thinking about what problems I am solving when I write code. When I'm programming, am I more often addressing a real-world problem, or some kind of software problem? How much of my code is spent on converting, transforming, serializing, deserializing, logging, formatting, validating, and error handling? Usually too much to be very interesting. It's all plumbing, but what I really want is water.
If I look at the systems I have worked on professionally, an alarming number of them do exactly the same thing, regardless of the business or the problem domain. It's just setting up a place to store data, a way to present it to users, and a way to translate it back and forth. There is still the question of where and how to build in domain logic and intelligence, and that's where most of the interesting debates take place, but this is still a woefully small slice of the pie. Maybe this is why I love writing command line programs. Come to think of it, maybe this is also why I love writing unit tests. There's no user interface, no data persistence, just logic. Okay, you're right, there is still setup and teardown plumbing, but it's not too hard to keep that stuff separate and out of the way. I also love working through the Project Euler problems. The programs feel pure. Just find the answer, and that's it.
I recently completed an online course in machine learning from Stanford Engineering. I loved it. It covered common applications of machine learning such as reading human handwriting, recognizing objects in images, and recommending movies and music. These applications are driving major features of Gmail, Facebook, Amazon, Netflix, and Pandora, to name a few. I was surprised to find that most of the course focused on math. The programming part was not much more than an afterthought. We did programming exercises in a language called Octave, but the work could have been done in any language. These problems are solved by math, not by programming. The programming just does the math. It's a lot like the role your calculator plays in your calculus class. You solve the problems; the calculator just does the math.
I was intrigued by the scene in the The Social Network where Zuckerberg has the idea and hacking skills to slam Facemash together, but he has to ask his buddy Eduardo Saverin, not a code slinger, for the "key ingredient": a ranking algorithm. The problem has already been solved by mathematics.
There are countless opportunities in the world today to make a dent in the universe by applying some existing mathematical solution to a modern problem. I'm looking for one.
Saturday, December 31, 2011
Sunday, December 4, 2011
Compassion-Driven Development
I have been developing software for a pretty long time now. I have worked on a lot of systems in a lot of different environments. In several of these places my orientation process included a visit to the place where the end users were, a call center or client site or whatever, to see what they did and how they used the system. Oddly enough, this usually happened once when I first started, but pretty much never again.
I recently wrapped up a project that afforded me an opportunity I had never had before as a software developer. I sat with my end users every day. I lived with them. This may sound like a bad idea, and in many cases it might be, but in this particular context I loved it. I have never had such a tight feedback loop. I could push out a new feature and within five minutes hear someone down the row yell, "Hey, look at this!"
Not only did it give me the chance to experience their reactions to my work, but more importantly it gave me the chance to see what they needed. While we geeks love to complain about users asking too much, sometimes they ask too little. Being in the midst of these folks gave me the chance to see them doing what they did everyday. They were working with a legacy system that left a lot to be desired in the way of user experience, and they had come to accept far too many inconveniences as facts of life. They were doing so many manual tasks that were easy to incorporate into the system. They had built processes around design flaws and browser limitations.
They may have had ideas, complaints, and requests, as users always do, but they often overlooked the most obvious things. There is pain in every job, and sometime users can't quite imagine how software improvements could relieve it. Or maybe they've lived with the pain for so long that it no longer occurs to them that they're wasting time and energy. Being with these folks every day as they worked gave me the chance to say to them, "You should not have to do this."
I call this Compassion-Driven Development.
Sunday, September 4, 2011
C# REPL
I started a new job recently that has taken me from a primarily interpreted, dynamically typed existence to one that is primarily compiled and statically typed. More specifically, I have gone from Ruby back to C#. This transition is only around my day job; I still love dynamic languages. But since I spend a good bit of time at work, this has affected a significant chunk of my programming life.
So what is my primary pain point coming back to the .NET world after a couple of years of peace, love, and Volkswagen minibuses? No surprises here; it's Visual Studio. In my day-to-day work I do everything I possibly can in VIM. So light, so immediate. Please don't make me open Visual Studio. It is so slow in everything that it does, even just opening and closing. You know, I'm not always creating a multi-tiered enterprise solution with three UI alternatives and seven WCF services. I very often want to write just one or two lines of code to clarify my understanding of some language behavior or some detail of the framework. It is at these times that I most resent waiting two minutes for the IDE to open. And please don't make me create a new solution just to run one line of code. Can't I just get straight to the language for a second?
One thing that Ruby got me addicted to was the instant feedback afforded by irb. Irb stands for "interactive Ruby." It is nothing unique; it's just Ruby's REPL. If you're not familiar with this term, a REPL is a read-evaluate-print loop. It's a command line shell in which you can type a line of code and have it execute immediately and print the result. For you Visual Studio folks, it's kind of like the Immediate Window, but it doesn't require a paused executing application.
Of course the REPL was not born with Ruby. I think it originated with LISP (before I was born), but you get one with Python, Scala, Haskell, Perl, Prolog—lots of languages. Modern web browsers with good debugging tools provide a REPL for JavaScript, but I prefer the one you get with Node. You might notice that these are all non-Microsoft languages, but my first experience with a REPL was in BASIC, and it was there in the version that came with MS-DOS back in the early 80s.
What is so special about a REPL? If programming is the way we communicate to a computer what we want it to do, must there be so much ceremony around saying anything at all? Writing an application is like writing a book. A small program might be more like a personal letter. But what if you just want to say something, or ask a single question? What's the largest integer value? Can you implicitly cast a float to a Boolean? What happens if I try to add a decimal and a null? What date is ninety days from today? Can you square a list of integers in one line of code? This is where the REPL shines. It's more like a conversation.
If you're like me, you've been spoiled by a REPL in another environment, and now you're spending your days in .NET, you've got to be mourning the loss of that instant feedback. If this a luxury you have never had, I'm telling you now what you've been missing. The good news is that there is a C# REPL in Mono. I don't know why I have not heard more talk about it, but it is a big deal to me. It is totally worth installing Mono for, even if you use it for nothing else.
Just head over to mono-project.com and install Mono. You don't even need MonoDevelop (although it is worth checking out). Add Mono's bin folder to your path, and you've suddenly got this at your disposal:
C# in a REPL. No Visual Studio. No project. And if that's not cool enough for you, it's Mono, so it works on OS X and Linux, too. Use wisely. Enjoy.
So what is my primary pain point coming back to the .NET world after a couple of years of peace, love, and Volkswagen minibuses? No surprises here; it's Visual Studio. In my day-to-day work I do everything I possibly can in VIM. So light, so immediate. Please don't make me open Visual Studio. It is so slow in everything that it does, even just opening and closing. You know, I'm not always creating a multi-tiered enterprise solution with three UI alternatives and seven WCF services. I very often want to write just one or two lines of code to clarify my understanding of some language behavior or some detail of the framework. It is at these times that I most resent waiting two minutes for the IDE to open. And please don't make me create a new solution just to run one line of code. Can't I just get straight to the language for a second?
One thing that Ruby got me addicted to was the instant feedback afforded by irb. Irb stands for "interactive Ruby." It is nothing unique; it's just Ruby's REPL. If you're not familiar with this term, a REPL is a read-evaluate-print loop. It's a command line shell in which you can type a line of code and have it execute immediately and print the result. For you Visual Studio folks, it's kind of like the Immediate Window, but it doesn't require a paused executing application.
Of course the REPL was not born with Ruby. I think it originated with LISP (before I was born), but you get one with Python, Scala, Haskell, Perl, Prolog—lots of languages. Modern web browsers with good debugging tools provide a REPL for JavaScript, but I prefer the one you get with Node. You might notice that these are all non-Microsoft languages, but my first experience with a REPL was in BASIC, and it was there in the version that came with MS-DOS back in the early 80s.
What is so special about a REPL? If programming is the way we communicate to a computer what we want it to do, must there be so much ceremony around saying anything at all? Writing an application is like writing a book. A small program might be more like a personal letter. But what if you just want to say something, or ask a single question? What's the largest integer value? Can you implicitly cast a float to a Boolean? What happens if I try to add a decimal and a null? What date is ninety days from today? Can you square a list of integers in one line of code? This is where the REPL shines. It's more like a conversation.
If you're like me, you've been spoiled by a REPL in another environment, and now you're spending your days in .NET, you've got to be mourning the loss of that instant feedback. If this a luxury you have never had, I'm telling you now what you've been missing. The good news is that there is a C# REPL in Mono. I don't know why I have not heard more talk about it, but it is a big deal to me. It is totally worth installing Mono for, even if you use it for nothing else.
Just head over to mono-project.com and install Mono. You don't even need MonoDevelop (although it is worth checking out). Add Mono's bin folder to your path, and you've suddenly got this at your disposal:
C# in a REPL. No Visual Studio. No project. And if that's not cool enough for you, it's Mono, so it works on OS X and Linux, too. Use wisely. Enjoy.
Friday, March 4, 2011
Underwater
If I'm going underwater, and I need to get something done, I will be focused from the start. I've got 30 seconds' worth of oxygen in my lungs; I can't just dive in, turn a couple of flips, wave at the camera, and maybe plan my dinner menu for the week. If I do that, I'm definitely not going to get the lock open. Fortunately, as my body gets desperate for oxygen, the survival instinct will kick in, and I'll go scrambling for the surface. So I may fail, but at least I won't die.
Unfortunately I was not born with similar instincts for dealing with my computer. I have one thing I need to do. Maybe I need to send one email. Maybe I need to check tomorrow's weather. Maybe I need to make one tiny update to some web page. It doesn't matter what is. I need to hold my breath, dive in, do the thing, and get back to the surface. But my mind does not have the same fearful respect for the internet that it has for water.
I go in casually, oblivious to the danger, with no sense of urgency. I look at email, RSS feeds, Twitter, Facebook, CNN, Reddit. I willingly expose myself to every source of distraction conceivable. If I see anything interesting in one of these places, it pulls me further in. What's worse, if I don't see anything interesting in one of these places, I'm just stupid enough to think about where else I might look to find something interesting. It's a black hole. At this point I have already failed to meet my goal, to accomplish my one meager task, whatever it was. But the really tragic part is that I don't have the sense to scramble back to the surface to catch my breath. I'm already lost, and now the giant leech has attached itself to my life clock, gently sucking away the hours.
Computers are my livelihood, and I enjoy them. It's hard to imagine life without them, but sometimes I like to try. Yes, they may make our lives hundreds of times easier and more efficient, but as good as they are at helping us get things done, I think they might be even better at helping us not get things done. Don't get me wrong; I'm not going anti-tech on you. I'm just wishing there were a way to automate self-discipline.
There's no app for that.
Sunday, February 6, 2011
Io - The Language
As a participant in the NashDL Book Club, I've been working my way through Bruce Tate's Seven Languages in Seven Weeks. To be fair, we only meet once every two weeks, and we're hitting one language per meeting, so in our case it's seven languages in fourteen weeks. The first language we looked at was Ruby, which is of course an interesting language, but one that most of us were familiar with already. The real fun of this book is learning new languages, so I'm excited to have moved on to language number two, Io.
It must be acknowledged that this is a terrible name for a programming language if only for its ungooglability. It might as well be named Stack Space or Garbage Collection. This dynamic language is primarily inspired by Smalltalk, which I have had very limited experience with. Io is prototype-based, which makes me relate it to JavaScript, but Io is more strictly prototype-based. In JavaScript you can make a function act like a class and use it to create objects, but in Io there is nothing that even resembles classes. Types of objects are defined by building up prototypes and cloning them. The genesis of all things is the clone method of the Object type.
All types are wide open to be modified in most any way, similar to the way classes are in Ruby. Properties and methods can be added, removed, and redefined at any time. Of course, this opens the door to both magic and disaster, so hack responsibly.
Io has an extremely simply syntax and some handy features that lend themselves nicely to creating DSLs. For example, to define the meaning of curly braces, you just create a method called curlyBrackets. Same with squareBrackets. Io also lets you define your own operators. This takes me straight to when Uncle Bob said that what killed Smalltalk was how easy it was to make a mess. It looks to me like that part of the Smalltalk legacy has been preserved here. It's very cool, but it reminds me of Inception when Ariadne starts getting too creative with her architecture. Sure, she is able to fold the world over on top of itself, but then she's got some seriously agitated projections to deal with.
Io is not the fastest language out there, but it might make up for that with some nice features for concurrency and asynchronous i/o. Anyone up for a new implementation of node.js? Might be fun.
I don't know if I will ever use Io in real life, but I have found it useful for helping me to think in a more prototype-oriented manner, which is necessary for writing good JavaScript. I'm still working to make amends with JavaScript after years of trying to treat it like C#. I think it's starting to forgive me. Thanks, Io.
It must be acknowledged that this is a terrible name for a programming language if only for its ungooglability. It might as well be named Stack Space or Garbage Collection. This dynamic language is primarily inspired by Smalltalk, which I have had very limited experience with. Io is prototype-based, which makes me relate it to JavaScript, but Io is more strictly prototype-based. In JavaScript you can make a function act like a class and use it to create objects, but in Io there is nothing that even resembles classes. Types of objects are defined by building up prototypes and cloning them. The genesis of all things is the clone method of the Object type.
Person := Object clone Developer := Person clone IOer := Developer clone
All types are wide open to be modified in most any way, similar to the way classes are in Ruby. Properties and methods can be added, removed, and redefined at any time. Of course, this opens the door to both magic and disaster, so hack responsibly.
Io has an extremely simply syntax and some handy features that lend themselves nicely to creating DSLs. For example, to define the meaning of curly braces, you just create a method called curlyBrackets. Same with squareBrackets. Io also lets you define your own operators. This takes me straight to when Uncle Bob said that what killed Smalltalk was how easy it was to make a mess. It looks to me like that part of the Smalltalk legacy has been preserved here. It's very cool, but it reminds me of Inception when Ariadne starts getting too creative with her architecture. Sure, she is able to fold the world over on top of itself, but then she's got some seriously agitated projections to deal with.
Io is not the fastest language out there, but it might make up for that with some nice features for concurrency and asynchronous i/o. Anyone up for a new implementation of node.js? Might be fun.
I don't know if I will ever use Io in real life, but I have found it useful for helping me to think in a more prototype-oriented manner, which is necessary for writing good JavaScript. I'm still working to make amends with JavaScript after years of trying to treat it like C#. I think it's starting to forgive me. Thanks, Io.
Subscribe to:
Posts (Atom)