Vincent Gable’s Blog

June 17, 2010

The Arrow Points Up

Filed under: Programming,Quotes | , , , , , ,
― Vincent Gable on June 17, 2010

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they’re current working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher.

First the C guys can’t imagine writing in assembly anymore, but C++’s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy “scripting” language for validating web forms. And on and on.

And in the short term, in the moment, they’re often right. But this arrow points only one way, and that’s in the direction of ever-higher abstraction. To judge how much time remains before the next leap forwards, look at the leading edge of the industry.

—John Siracusa (emphasis mine)

Here’s my two cents on the future of abstraction: systems are clearly getting wider (paralell), not faster; technologies like Grand Central Dispatch help us deal with concurrency today, but longer term, I think a functional programming abstraction is the answer.

October 26, 2009

Threading is Wrong

Filed under: Programming,Quotes,Usability | , , , ,
― Vincent Gable on October 26, 2009

I’m taking the following as an axiom: Exposing real pre-emptive threading with shared mutable data structures to application programmers is wrong. …It gets very hard to find humans who can actually reason about threads well enough to be usefully productive.

When I give talks about this stuff, I assert that threads are a recipe for deadlocks, race conditions, horrible non-reproducible bugs that take endless pain to find, and hard-to-diagnose performance problems. Nobody ever pushes back.

—Tim Bray

September 17, 2009

Big Freaking Systems

Filed under: Programming,Quotes,Research | , , , ,
― Vincent Gable on September 17, 2009

A programming language is a tool for handling design complexity. That’s what all of computer science is, really — languages, libraries, type systems, garbage collectors, everything you learn about programming. They’re ways to build more and more complex designs without losing your grip.

The way you manage complexity is to be able to ignore it. A good programming tool lets you forget about some part of the problem, so that you can focus on some other part. And it ensures that when you return to the parts you forgot, you haven’t accidentally broken them.

—Andrew Potkin

Years ago, When I was taking to programmers about what college I wanted to attend, I had in interesting conversation about how Computer Science education is an utter failure at preparing students for real-world programming. Outside of Software Development, no technical field accepts (sometimes prefers) candidates with “N years of experience” in place of a degree. I’m not sure I know why CS education fails so badly and universally. But my current best guess is that it’s because school never exposes you to enough complexity. Projects have to end in a semester. You never have to deal with a multimillion-line program, written by hundreds of co-workers, dozens of which you need to collaborate with, at unexpected times, for surprising reasons.

June 11, 2009

Early Adopters Wanted!

Filed under: Announcement,iPhone | , , ,
― Vincent Gable on June 11, 2009

I am wrapping up work on Prometheus, an iPhone app that edits the Simple English Wikipedia.

Unfortunately, I am having trouble finding people to take the pre-release version for a spin, and tell me what they think. I want to be sure I’ve fixed any glaring issues before I push my work out to the App Store.

If you are interested in helping, please visit the Prometheus webpage.

Thank you!

June 4, 2009

MicroISV

Filed under: Programming | , , , , , , ,
― Vincent Gable on June 4, 2009

The word microISV is all business, in all the wrong ways.

MicroISV stands for “Micro Independent Software Vendor”, which in plain english means a tiny software company, usually on the order of one or three people.

Probably the best reason to buy software from such a small shop is passion. People who build and sell their own software directly tend to care very deeply about it. Their program is their baby. Nobody in a microISV is just in it for the paycheck. No matter how cool a large corporation is, at the end of the day everyone has to compromise on their dream to work together on it. But a one man shop never has to compromise or design by committee.

“Micro Independent Software Vendor” doesn’t communicate this agile vision. It sounds like the same kind of turgid enterprise think that drove the world’s largest software company to rename Netbooks, “low-cost small notebook PCs”. (You just can’t make this stuff up!)

Three people are never going to out-Big-Business a Big Business. So it just doesn’t make sense to label what they do with a Big Business Word. (And by word, I mean several words, because that’s how Enterprise Speak works.)

The most popular synonym for microISV I see in the Mac software scene is indy developer. I think it’s a fine term — better than microISV by about a factor of IBM’s income. But there are many other excellent alternatives to “indie”, like boutique, nano, one-man, etc. The exact term isn’t important; and it need not be short. If someone wants to open their own “Hand Cyphered Soft-Wares Emporium“, then more power to them! What’s important is that their taxonomy reflect the culture of commitment that goes into their unique software.

EDITED TO ADD: Small Batch Business is another fantastic name.

May 14, 2009

Emergent Libraries

Filed under: Programming,Research | , , , , , ,
― Vincent Gable on May 14, 2009

I have latched onto an idea, but don’t have the resources to follow up on it: could a static-analysis tool identify repeated patterns of code, across many code bases, that should be extracted out as subroutines and higher-level functions? How universal would these “emergent libraries” be?

My inspiration here is Section 4.1 Identifying Common Functions, in the excellent paper Some Thoughts on Security After Ten Years of qmail 1.0 (PDF), by Daniel J. Bernstein,

Most programmers would never bother to create such a small function. But several words of code are saved whenever one occurrence of the dup2()/close() pattern is replaced with one call to fd_move(); replacing a dozen occurrences saves considerably more code than were spent writing the function itself. (The function is also a natural target for tests.) The same benefit scales to larger systems and to a huge variety of functions; fd_move() is just one example. In many cases an automated scan for common operation sequences can suggest helpful new functions, but even without automation I frequently find myself thinking “Haven’t I seen this before?” and extracting a new function out of existing code.

What’s particularly fascinating to me are the new operations we might find.

Before I was exposed to the Haskell prelude I hadn’t known about the fundamentally useful foldl and foldr operations. I had written dozens of programs that used accumulation, but it’s generalization hadn’t occurred to me — and probably never would have. Static analysis can help uncover generalizations that we might have missed, or didn’t think were important, but turn out in practice to be widely used operations.

March 7, 2009

Don’t Work Against Yourself

Filed under: Quotes | , , ,
― Vincent Gable on March 7, 2009

Reaganite conservatism axiomatically disdains government, and that creates a perverse incentive for conservative politicians to run government badly (or at least not to run it well), since the failure of government confirms conservative prejudices and (in theory) provides the movement with additional evidence in favor of its ideology. We just saw a particularly vivid example of this pathologically self-destructive dynamic at work in Bobby Jindal’s otherwise inexplicable attempt to turn the Bush administration’s utter ineptitude after Hurricane Katrina into a GOP talking point.

—Damon Linker

I generally try to keep politics out of my blog, because political discussion on the internet isn’t productive. But I think there is a good lesson in this bit of history, and it’s very applicable to software development.

March 3, 2009

Vincent’s Notes: End To End Arguments in System Design

Filed under: Programming | , , ,
― Vincent Gable on March 3, 2009

At Michael Tsai’s suggestion I listened to the paper End-To-End Arugments in System Design while driving. (Fair warning: Since I was also driving while listening, I didn’t absorb everything as well as I should have.)

The thrust of the paper is that you generally want to make your low level components (aka libraries) simpler then you think. Counter-intuitively, building extra reliability into a low-level component does not (usually) make it easier to build a reliable application that uses the component. That’s because the application has to work around all sorts of other errors from different components. So it must have error handling code. Making one low level component “smarter” does not change this. But it does make the component more complex. And some of that complexity is duplicate code that does just what the application’s error handling code does.

The “End to End” in the title of the paper is from a file transfer application having to do an “end to end” check to make sure that the files at both end of the transmission are the same.

Conclusions

End-to-end arguments are a kind of “Occam’s razor” when it comes to
choosing the functions to be provided in a communication subsystem.
Because the communication subsystem is frequently specified before
applications that use the subsystem are known, the designer may be
tempted to “help” the users by taking on more function than necessary.
Awareness of end-to-end arguments can help to reduce such temptations….

February 20, 2009

Bad Apples

Filed under: Quotes,Research | ,
― Vincent Gable on February 20, 2009

What they found, in short, is that the worst team member is the best predictor of how any team performs. It doesn’t seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.

—Jeff Atwood

February 18, 2009

Competing Software Engineering Approaches

Filed under: Cocoa,Programming,Quotes,UNIX | , , , , ,
― Vincent Gable on February 18, 2009

Tim Bray,

…Palm’s approach is
radically different from both Android’s and Apple’s. Since they’re all here
at more or less the same time, running the
same Web browser on roughly
equivalent hardware, this represents an unprecedented experiment in
competitive software-engineering approaches.

Language Framework Notes
Apple Objective-C Cocoa Old-school object-oriented language compiled to the metal; general-purpose UI
framework with roots reaching back to NeXT.
Android Java Android Java language, custom VM, built-from-scratch UI
framework aimed at small-form-factor devices, fairly abstraction-free, based
on “Actions” and “Intents”.
web OS JavaScript “Mojo” All Web technology all the time. Innovative and visually-impressive
“card”-based UI.

(I think it’s interesting to see Windows Mobile on the list:

Windows Mobile C/C++ Windows CE/.NET Micro Philosophically tries to bring Windows to the phone. When I did WinCE development it felt like doing C++ for a Windows OS from the past.

)

I see way too many other factors to attribute success/failure of the devices to the language. So I wouldn’t call this an experiment.

But it is interesting how much development for each platform diverges at a fundamental level!

Historically most operating systems —
UNIX, OS/2, Linux, Windows, Solaris, Mac (Classic and OS X) — were predominantly, written in C/C++. While each platform has it’s own frameworks, they all have strong support for C++ development. (Although Mac OS X has is slowly dropping support for it’s C/C++ “Carbon” API, and Windows wants to be moving to C# .NET)

It’s really cool to see mobile platforms doing something radically different from each other. There are good arguments for each approach — may the best one win.

Older Posts »

Powered by WordPress