Thoughts

Thoughts — 2 Comments
10
Apr 10

The Repeating History of Closed Platforms

I was one of the many that loved the iPhone AppStore platform.  Consumers marveled at how we could easily buy any application we might want, vetted with a nice rating system.   Developers were shocked at the ease with which it seemed possible to monetize on simple applications.   The only downside seemed to be the occasional political or ambiguous AppStore rejection.

Looking back now, the recent changes to Apple’s developer terms of service are not so much of a shock.  They are just the continuation of Apple’s past policies.  It’s the same pattern of gradual erosion of Consumer and Maker rights we see on any platform over time.  If you look beyond the scope of software and include any marketable good, you see a long history of this pattern repeated over and over.  Consider cable television and the music industry.

At first, closed platforms are great.  They get the both the Consumer and the Maker what they need as fast and easily as possible, because that’s the platform provider’s job.  The platform providers are competing against each other and so must cater to both the Consumer and the Maker.  However, this soon changes.

Over time, one of two things happen, both bad:  Either a single provider wins out and gains a monopoly, or platform providers conspire together.  The platform then becomes a weapon in the corporate war chest.  The ultimate end is control over both the Makers and the Consumers until a new revolutionary platform emerges, catches the old players off guard and the process begins again.

The only escape from this pattern seems to be the open source community, a community in which the Makers have taken complete control by keeping out profit-seeking Providers.  However, this seems to have the unfortunate side effect of alienating Consumers.  Perhaps this can be remedied by a benevolent Platform Provider, but I’m not holding my breath.

Thoughts — 11 Comments
14
Mar 10

Code Bubbles and the Keyboard

I was catching up on reading one of my favorite blogs today, Lambda the Ultimate, and was not disappointed in the least.  At the top of the list sat Code Bubbles, a whole new take on the IDE.  Code Bubbles shocked me because it’s visually manifest much of what I had in mind when I wrote almost two years ago on leaving flat files behind.  That said, I think Code Bubbles has a long way to go before it’s a reasonable platform to choose for active development.

From a high-level point of view, Code Bubbles is a modern programmer’s dream.  With organized tasks it would be much easier keep your mind focused on what you are trying to accomplish.  With code represented outside of its restrictive flat file format, you would need not repeatedly wade through piles of irrelevant cruft to reach the small pieces of code you need to change or consider.  Even the integration with bug tracking and email looks quite promising.

However, the actual process of using Code Bubbles looks to be an experienced programmer’s worst nightmare.  To be tied so extensively to the mouse would mean we all would need to move to one handed keyboards.  To organize everything by drag and drop on the screen would mean we would end up spending much of our time organizing the layout of code on our screen instead of its actual contents.  Also, due to the nature of the scroll-and-select interface, finding what you need in a large project could quickly become quite annoying.

Even at the most basic level, just reaching for the mouse has a huge impact on programmer performance.  Many think of it much like a cache miss.

The good news is that none of these problems seem insurmountable.  An intelligent keyboard shortcut scheme could be invented.   A snap-in grid layout would speed drag and drop, although automatic layout needs to happen eventually.  Perhaps the scroll and select could be made less frustrating with a textbox filter (ala Firefox config).

An even more far reaching solution to this mousyness might be something like NDepend style querying.  Even just Windows 7-style keyword search would be a huge boon.  The IDE practically screams for keyboard queries.

That said, I for one am looking forward to the day I can use Code Bubbles (or something similar) as a mature and robust IDE.  With the monstrous computing beasts we have under our desks, the layout of on disk or in memory should not limit the ways in which we are able to interact with our code.

Update: Additional commentary is available on programming reddit.

Thoughts — 4 Comments
6
Mar 10

Abstract Thoughts about F# Abstractions

My recent work on Professional F# 2.0 has left me thinking a lot about the nature of abstractions.

In computation, different types of abstraction are trade-offs between clarity and freedom in different areas.   As you move away from the machine architecture, you lose the freedom to push bits around in whichever way you might want.  In the case of garbage collection, this means you might not be able to hand optimize your memory usage.  For managed code, this might mean you can no longer hand optimize your code to a CPU-instruction level.  With even a small degree of abstraction, your choices are cut down to only a small subset of what was previously possible.

In exchange for this loss, you get to think about problems in a constrained way.  This means you can make more valid assumptions about what is going on.  You can express ideas cleanly, without additionally expressing the machine’s management of the resources involved in those ideas.  You can manage less and express more.

The benefit of these constraints goes beyond just what you personally have to worry about while programming.  Some types of abstraction, such as function signature standardization or managed assemblies, enable post-compilation binary compatibility.  Other types of abstraction, such as immutability, allow the compiler to do high level optimizations beyond what was previously possible.

So, while you might be able to do everything with the JMP instruction that you can with C#’s foreach, it takes much more effort to express the same idea with JMP, and a lot more can go wrong.  Similarly, while you may be able to express all of the ideas in C# that you can in F#, it takes much more effort to express those same ideas in C#, and a lot more can go wrong.

And who knows… In the future, we F# users might even get some sweet optimizations out of the deal.

Thoughts — 2 Comments
21
Feb 10

On Finding Mentors Through Issuing Challenges

I hear it again and again: the key to a successful career is in finding good mentors. According to the Women in Tech panel I attended at PDC, lack of female mentors is the number one reasons for our gender dichotomy in tech.  I’ve also seen much of my success through mentoring. Were it not for Steve Hawley and Lou Franco at Atalasoft, the paths to accomplishing things like applying for a patent or speaking at an event would have continued to remain a mystery.  Once something has been shown possible it becomes much more accessible.

So, how to find mentors?  As with anything people related, it’s all about generating good feelings. Consider two ways to accomplish this:  Making a personal connection and offering a defeatable challenge.

Finding Mentors through Friendship

Make friends with someone more knowledgeable than you and of course that person will want to share their knowledge with you. It’s always good to invest time in getting to know those who are more experienced. This can be accomplished with something as simple as asking someone if they’d like to go get lunch. This is the traditional way to find a mentor. It might even be considered common knowledge.

However, as you accomplish more and more in your career, the mentors you need are busier and busier people and thus harder and harder to gain access to. How might you incentivize them to spend time on your education?

Finding Mentors through Challenge

This one only occurred to me recently and was the impetus for this post.  The idea was inspired by the recent exchange of posts by Chris Smith and Brian McNamara on the F# Team. Through a series of technically escalating blog posts each out-optimized the other.  What better way is there to get someone to spend a lot of time on teaching you than to challenge them on a topic they know well? Nothing motivates like a challenge to the ego.

Did you ever get in a fight with someone in grade school and become fast friends after? I know it happened to me. When the victor reaches out his hand in friendship to the bested, acknowledging their strength in offering or standing to face a challenge, a strong bond can be created. The victor is now the mentor, the bested the student.

The big risk in a professional setting is in how things work out afterward. If things get too intense your relationship might be damaged. I believe this risk can be measured in terms of the work environment and how used to conflict the members are. If a large amount of tension was a allowed to build up before the challenge, people are likely to take the challenge personally. However, if things have been kept playful with a small amount of constant challenge, escalating is much less likely to have any repercussions.