Dubroy.com/blog

I spent the long weekend at my uncle’s cottage in Quebec, meaning the last three days have been filled with sun, beer, and poutine. It was already destined to be a low-productivity day, but the final nail in the coffin was the announcement of Google Chrome.

There’s already been lots of talk (and speculation) about the performance aspects of Chrome, and about Google’s strategic motives in releasing it. But of course, I’m more interested in the user experience. I’ve been running Chrome for over three hours now, and here are my first impressions of it from a user experience and usability angle. The Google Chrome web site lists the key features here; I’ll address those on a point-by-point basis.

One box for everything

There’s evidence that many people don’t know the difference between the search box and the URL bar (see here). Chrome avoids this problem by getting rid of the separate search bar altogether: URLs and keyword searches are typed into the same text box. They call this box the omnibox, and it works a lot like Firefox 3’s awesomebar.

This is a small feature, but a nice one. I’ve never understood why it was necessary to have a separate search bar and URL bar in Firefox, especially since you can type keywords into the URL bar and it will do a search for those terms. And now that I’m used to the awesomebar, I find myself typing search keywords into the URL bar all the time.

New Tab page

In Firefox and Safari, when you open a new tab, you’re greeted with a blank page. As Aza Raskin recently observed: “while clean, it has a 100% probability of not getting you where what you want to be.” In Chrome, when you open up a new tab, it’s filled with a bunch of handy navigation shortcuts. Again, a small but nice touch. It’s actually remarkably similar to some of the ideas that Aza has been throwing around for future versions of Firefox; check out his post here.

Application shortcuts

Another idea that’s been floating around in various forms for a while now: Chrome lets you create an “application shortcut” from any site that you visit. Basically, it’s a quick and easy way to create site-specific browsers for your favourite web applications. It puts a shortcut on your desktop to launch the site in a separate window, with none of the usual web browser controls. You can get similar functionality in Firefox by installing the Prism extension.

Personally, this is a feature I could take or leave. I’m not yet convinced that site-specific browsers are the way to go. I gave Prism a quick try with my GMail, and I found that I missed having the regular browser features at my fingertips.

Dynamic tabs

This is a feature I love: you can drag tabs out of their window to create a new window, and drag tabs between windows. I know Safari has supports this to some extent (don’t have my Mac handy to check) but I can guarantee it’s not as snappy as it is in Chrome.

Incognito mode

Unless you spend a lot of time…er, buying birthday gifts for your spouse, this is not a big deal. Basically the same as Safari’s “private browsing” feature.

Safe browsing and Instant bookmarks

Again, nothing too exciting here — Firefox 3 has very similar features, which probably greatly influenced Chrome.

Importing settings

Yawn. Next!

Simpler downloads

Another little bit of UI polish that I think Google got right. Last year, I wrote a post about how uploading and downloading are seams in the web experience. With Chome, Google has made a few small tweaks that make things better. Instead of a separate Downloads window (which constantly annoys me in other browsers), downloaded items appear in the tab they were downloaded from. Look in the bottom left corner of this screenshot:

What I really like here is that I can interact with the PDF icon just like I can on my desktop: I can double-click it to open it, or drag-and-drop it to copy it to a new location.

And another cool feature which they don’t advertise is that you can drag-and-drop files from Windows Explorer onto File Chooser controls — another feature I’ve been craving for a while.

Separate process for every tab == “runs today’s complex web applications much better”

This is Chrome’s raison d’être and key differentiating feature. In Chrome, every open tab runs in a separate process, with its own address space. From a usability perspective, this means several important things. First of all, the entire interface is incredibly snappy. In Firefox, there is a single thread that handles updating the UI and executing JavaScript on all open tabs. This means that one piggy site can slow down the entire browser. The Mozilla team did a great job on performance improvements in Firefox 3, but Firefox can still bog down with a lot of tabs open. In Chrome, the worst thing a bloated site can do is slow down its own tab.

Having a process per tab also means that a single buggy site can’t bring down your entire browser. Apparently plugins also run in a separate process, so no more worrying about crappy plugins crashing your browser (Acrobat, I’m looking at you).

In my opinion, the performance and stability gains are big usability wins.

Conclusion

Overall, I’m really impressed with the attention to the user experience in Google Chrome. Google doesn’t have a reputation for great UI design, with a few exceptions (GMail, Maps), but I think they’ve hit a winner with Chrome. There are no groundbreaking new features, but a bunch of small, solid improvements that make for an overall great user experience. The biggest thing most people will notice is that almost everything in Chrome is extremely snappy. This might not seem like a big deal, but it really makes the browser a pleasure to use.

Yesterday, after writing my post in reply to Atul, Aza, and co., I was thinking about how much work it is to put together a post like that. You often hear people refer to blogs as a “conversation”, but if that’s true, it’s more work than any type of conversation I’ve ever had.

Compare it to other kinds of group conversation we can have on the internet:

• IM, IRC, etc.
• Twitter and FriendFeed
• wikis (not all wikis are really conversation-friendly, but the original wiki certainly is)
• email, discussion forums, blog comments

Writing a blog entry in response to someone else’s is far more difficult than any of those. Partly, it’s because blogging is often slightly more structured and polished than the other methods; but there’s also a lot of overhead in the actual act of writing a post. For example, here’s what I did to write that post yesterday:

• track down links to all of the relevant posts. Not too difficult, because they link to each other; but for more than a handful of posts, this can be a pain. To make sure you’ve seen all the responses, you need to check Technorati or Google or something.
• for each post, get a permalink (you don’t want to just link to the blog’s front page, even though that’s often the easiest way to find the post)
• for each post, check if there is a special trackback link. Some blogs have these links, and some blogs don’t, often not due to a deliberate choice by the author. It’s really kinda complicated.
• write the actual post, maybe cutting and pasting quotes from the posts you are replying to. Link to the original posts, and make sure to cut and paste the permalink URLs.
• depending on your blogging software, select the category for the posts, and add some tags to the post. This isn’t absolutely necessary, but it helps your readers find your posts more easily
• paste any trackback URLs into the appropriate box in your blogging software

Compare that to how easy it is to reply to a forum post or email. Click one button, type your response, and you’re done.

And what about trying to follow one of these blog “conversations”? You have to keep visiting n different blogs to see if there are any new comments, and watching Technorati or Google to see if there are any new blogs linking into the conversation. Sure, you can automate some of this with RSS feeds, but that’s another complication that you need to manage.

If you’re a blog author, you probably get an email every time someone comments on your post. But when you reply, you can never be sure if the person will ever see your response.

Obviously, I think the good outweighs the bad, because I’ve kept on blogging. But I really wish it were simpler. I’d like to be able to join a blog conversation as easily as I can join an email conversation.

What do you guys think? Any blog authors out there who have found some good tools to make this easier? I know about CoComment for keeping track of the comments I leave, but haven’t tried it out. And I know that Disqus can also help, but that’s only good for blogs that are using the Disqus service.

Many of you probably know that I’m interested in tabbed browsing. For my master’s thesis, I’m conducting a study to examine how people use multiple tabs and multiple windows to organize their web browsing. At the same time, I’ve been thinking a lot about how we could improve the browser interface to address some of the problems that people run into with tabs.

In the past week or so, there’s been a flurry of discussion about how Firefox handles tabs. One of the things that’s being discussed is the Ctrl-Tab feature in Firefox. Ctrl-Tab is a shortcut that moves you the tab immediately to the right of the one you’re on. Ctrl-Shift-Tab does the opposite, and switches to the tab on the left. In Firefox 3.1 branch, this has been changed to act more like Alt-Tab on Windows and Mac OS: it switches to the tab that you were previously looking at, rather than the tab to the right.

Atul Varma mentions some of the problems with this change. The visual representation used by Ctrl-Tab uses a different ordering than the tab bar you see on your screen, which is confusing. Aza Raskin suggested a different approach that might avoid the problem, but I wonder if we are thinking about this the wrong way.

I agree with Atul’s point that showing two different orderings is confusing, but I’m not sure I agree with this:

The last page that the user is on isn’t always their locus of attention. Indeed, unless someone is rapidly switching between two places, most people don’t even remember the last web page they were on; even less relevant is the second-to-last web page they were on, and the ordering of anything older than that looks like randomness.

I’m not sure this is true. There are many studies¹ that show that the back button is the most frequently used navigation element in the browser, and the back button is a time-based list (well, mostly²). In general, I think it’s a really natural way of accessing recently-view items.

On the other hand, tabbed browsing has completely changed the way many of us use our browsers, and I don’t know of any study that accounts for this. Switching to a different tab could be considered to be a kind of navigation action, similar to following a link or clicking the back button. This is something I’m planning to address in my study. My hunch is that heavy tab users switch tabs much more frequently than they navigate to new pages, and maybe Atul is right that a recency-based mechanism isn’t the best choice.

But is the current ordering any better? By default, Firefox puts tabs in the order in which you opened them up. (You can move them around, but I find that I rarely bother.) I agree that it’s bad to have a mismatch between the ordering in the tab bar and the Ctrl-Tab order, but to me, it makes a lot more sense to use the order in which they were last accessed, rather than the order in which they were opened.

A completely different approach that I’ve been thinking about is to get rid of “tabs” altogether in favour of a better browser history. I find that most of the time that I open a new tab, it’s because I don’t want to leave the page that I am on. Sometimes it’s because I don’t want to lose something on that page (e.g. text that I have typed into a form), and sometimes it’s simply because I find it easier to use a tab than to use the back button. If the browser had better mechanisms for returning to recently-used pages, then I might not need to use tabs at all.

Right now my desk is littered with sketches about how this might work. Later this week, I’ll post some of my ideas. In the meantime, if you’re interested in this stuff, you should check out the whole discussion:

• Atul Varma: Tab Navigation: Tradeoffs
• Aza Raskin: Control-Tab Woes
• Jenny Boriss: Tabs Want to be Seen and Tab View vs. Application View
• and Danielle Fong has a monster post about tabs and multitasking, and suggests some ideas that are pretty similar to what I’ve been thinking: Enhancing Multitasking to Enhance Our Minds

1. e.g. Improving Web Page Revisitation: Analysis, Design and Evaluation and Web Page Revisitation Revisited: Implications of a Long-term Click-stream Study of Browser Usage [↩]
2. In fact, it’s not strictly time-based. If you visit pages A -> B -> C, then use the back button to return to page A, then follow a link to page D, then you won’t be able to return to B or C using the back button [↩]

This week, I’m doing all my coding on a borrowed MacBook. It’s the most time I’ve ever spent doing development on a Mac. I’ve done a bit here and there on my Mac Mini, but usually I just use that for web browsing, downloading episodes of Degrassi High, and such.

Of course I needed a text editor, so I figured I’d give TextMate a try since it’s highly recommended by many Mac hackers. My first impression has been good. It’s a got a nice, simple, no-frills interface, some slick built-in themes (Espresso Libre ftw!), and the bundles come in pretty handy.

I’ve found a few small things that have thrown off my rhythm though. The regular find command (⌘-F) doesn’t do an incremental search, and hitting Enter again doesn’t bring up the next match. Yes, I know about Ctrl-S, but geez, I gave up Emacs like eons ago, and I’m just so used to typing Ctrl-F (on Windows) or ⌘-F (on the Mac) to search. And I want it to work that way in every application.

Another thing that I miss is the way the Home and End keys work on Windows: they move the cursor to the beginning and end of the line. On the Mac, they take you to the beginning and end of the file, which you can also do on Windows by hitting Ctrl-Home and Ctrl-End. I really miss the Windows behaviour, because it’s my favourite way to nuke a line or a whole section of code: whack Home, then hold down Shift and use the arrow keys to select the lines you want to kill.

Anyways, the point of this post is not to complain about TextMate, because it is a fine piece of software, and I’m sure it won’t take long for me to adapt. But this experience got me thinking about the whole experience of programming in a text editor, and made me realize that this hasn’t really changed much in 30 years.

Where’s the innovation?

In 2008, on almost every operating system, your choices for a text editor are roughly the same:

• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, for everyone else. Sure, there are plenty of “choices” in this category, but it’s like the choice between Coke, Dr. Pepper, and root beer: they’re still all sugary, caramel-coloured beverages. TextMate, Eclipse, Visual Studio, Notepad, etc. — the actual act of editing text is almost exactly the same in all of them. These guys basically work like your standard WYSIWYG word processor, with a few extra features for coding.

Now let’s go back 30 years, to 1978. I wasn’t breathing 30 years ago, let alone coding, so I had to go to Google for a little history lesson. But as I understand it, here were your choices in 1978:

• a line editor like ed, which I’ve been told was roughly like trying to write with a pen tied to the end of a metre stick
• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, if you were lucky enough to be working at Xerox PARC

So where’s the innovation?

At this point, you might be thinking, who cares? Emacs/vi/TextMate is good enough. The thing is, the text editor is still the primary user interface for coding. That’s why some people get so religious about their preference. It just seems weird to me that there have been so few attempts to try something truly new. And I find it hard to believe we reached the pinnacle of programming UIs in 1978.

A few ideas

Most editors are just as good for writing a blog post or screenplay as they are for writing code. But the structure of code is completely different. You rarely open up a source file and read it from beginning to end. But most programming environments seemed to be designed for that kind of workflow.

In the end, I think that’s the real kicker: most programming languages are file-based. For some reason, we seem to be so attached to coding in plain text with 80-character lines. If you drop this assumption, things start to get a bit more interesting. But that only takes us to where Smalltalk IDEs were at in the 80s.

Anyways, most of the dynamic languages aren’t inherently file-based. By that I mean that it’s not too difficult to interface with the interpreter without using text files. So that’s not a good excuse.

Here are a few things I’d love to experiment with in a programming environment:

• Better support for random access. The structure of code is more like hypertext than it is like a book.

• Richer annotations. Comments take up valuable screen space. It would be nice to be able to have more unobtrusive comments in the code. This would also allow you to do things like have a discussion thread about a section of code, link to other relevant methods, etc. Even something as simple as comments that auto-wrap to the width of the window would be a nice touch.

• Better support for looking at several sections of code at the same time. Some editors (including Emacs) allow you to split the window into several viewports. That’s a start, but it could be improved upon I think. That reminds me, I’ve been meaning to try Acme for a while.

• Tighter integration between the editor and the runtime. One example is having your editor be able to tell you “every time you’ve run this method, this variable has been of type X”. Another example is if your editor visualized code paths — maybe you could overlay a heat map on top of the source code for profiling purposes

• Explicit support for exploratory programming. When I code in Python, I like to keep an interactive console open, where I can try out little snippets of code. With a bit of tweaking (e.g., not tossing out my entire method when I make a syntax error on the last line), I could see this becoming a primary way to write code.

What do you guys think? What are your favourite programming editors/environments, and why? Any other ideas about how programming UIs could be shaken up?

For my master’s thesis, I’m looking at how people use multiple windows and tabs to organize their web browsing. I’m especially interested in tabs. I’m a pretty heavy tab user myself, and I while I can’t live without tabs (in today’s browsers), I also think that tabs introduce some problems of their own.

In my research, there are two main questions that I’d like to answer. First, what are the problems that people encounter with tabbed browsing? And second, how exactly do people use tabbed browsing? What strategies do they use, and why? The answers to these questions could guide the future design of web browsers.

Great minds think alike

It just so happens that I’m not the only person interested in this. Mike Beltzner put me in touch with a bunch of people at Mozilla who have been thinking along similar lines, and I thought I’d point you guys to some of the interesting things they’ve been posting.

The closest thing to the work I’m doing is Bryan Clark’s post about how and why people use tabs. Bryan is working on the UI for Thunderbird, the Mozilla mail client. They’re interested in understanding the use cases for tabs, in order to support similar use cases in Thunderbird. He’s collecting his data informally; I’m hoping to get similar data, but in a more formal way.

Big changes…

On the Humanized blog more than a year ago, Aza Raskin wrote about the problem with tab scrolling, and challenged his readers to come up with a better solution. Lots of interesting thoughts in the comments, especially the idea of implimenting “tabs” as a single, infinitely long document (perhaps inspired by Aza’s father Jef’s ideas).

That was last summer; more recently, since he’s joined Mozilla, Aza’s been looking at interfaces for mobile browsers. To check out some of the ideas he’s playing with, check out his post on Firefox mobile concepts. I really like the idea of implementing tabs in a zooming UI — it’s something I’ve been thinking about for a while.

…and smaller changes

Since he’s currently focusing on mobile, Aza’s prototypes are a bit more radical than we’ll probably ever see in the desktop version of Firefox. But Jenny Boriss and Madhava Enros are looking at both big and small ways to improve the tabbed browsing experience on the desktop. Boriss starts by listing some of the problems with tabs, and suggests some possible ways to fix the problem: check out her post here.

Inspired by Boriss’ post, Madhava comes at the problem from a different angle, “crushing it, finally, in something we like to call the pincing crab-claw of good design”: see here. Boriss follows up with a great post, incorporating some of Madhava’s ideas, which discusses ways that future versions of Firefox might better support visual navigation. These ideas are a bit more down-to-earth, maybe; it’s easier to see them being added to a future version of Firefox.

Coming Soon?

If you’re interested in how this will all play out in the next version of Firefox, check out this wiki page. Mozilla has assembled a critical mass of talented UI people, and I’m really interested to see what they come up with in future versions of my favourite browser. If you have any thoughts, I know they’d love to get your opinion.

As for me, I’ll be posting some of my own ideas soon, and will hopefully have some empirical data in the next couple of months to back some of these ideas up. Until then, I’ll keep you posted.

A roundup of the latest links from del.icio.us/pdubroy:

• AJAX Libraries API - Google Code

  I was wondering when this was going to happen. Google announces that they are now providing hosting and distributing of popular JavaScript libraries. No longer do you have to include the kitchen sink in your application. Well, as long as you are willing to put your eggs in Google’s basket.

• Proposal for a new ticketing system for DrProject

  An interesting idea for bug tracking. Your bug database starts as a simple to-do list, and then you add fields as you need them. Only one working on a project? Don’t need the “owner” field. Just starting to write the code? Don’t need the “release” field.

• Grape desktop

  Really cool concept for a desktop interface based on zooming and spatial organization.

• Long Methods are Natural - Beautiful Code

  Michael Feathers explains how method length seems to have a power law distribution.

• Stanford Human-Computer Interaction Seminar - Free on videos iTunes

  via UsabilityBlog

• When location is everywhere | FactoryCity

  How will your web app change when (and not if) your users can easily share their location data?

I just got back from meshU, a one-day conference focused on design and development for the web. I went on a bit of a whim; the student tickets were only 30 bucks, and there were lots of interesting speakers. Well, it was a good decision — the three talks I saw were well worth the price.

(As an aside, I see that I’ve been added to Patrick Mueller’s Planet OTI aggregator. OTIers, read on! Today’s post contains at least two OTI connections.)

Avi Bryant: Turning the Tables: Moving Beyond Relational Storage

The first talk I attended was by Avi Bryant of Dabble DB fame. Avi talked about why how not to use a RDBMS. There’s been a lot of interest lately in alternatives to the relational database — CouchDB, Amazon SimpleDB, and Google BigTable being the most famous examples.

Avi mentioned that there are two main cases where it’s advantageous to have something other than a relational database. First, if your dataset is massive, as with Google. In this case, it’s just not feasible to use a RDMS. The second case is if your dataset is really just many small, independent datasets, in which case it might be simpler and more scalable to use an alternative technique.

At the end of the talk, Avi demoed MagLev, which is a Ruby interpreter built on top of a Smalltalk VM (OTI connection #1). This was really cool, not just because it’s Ruby running on top of Smalltalk. It was cool because MagLev can transparently persist heap objects to disk, and distribute them to other VMs, either locally or running on other machines. For example, you can define a function in one VM, and then call it from another VM. Wow. As far as I know this was the first time MagLev has been shown in public, but there’s going to be a talk at RailsConf 2008.

Daniel Burka: Iterative Design Strategies

The second talk I attended was by Daniel Burka (OTIers probably know Daniel’s brother Peter). Daniel is the lead designer for Digg and a co-founder of Pownce. Daniel gave a great talk on iterative design strategies. You can check out the slides here.

It was really interesting to hear some of Daniel’s stories from Digg. He said that one of the times that they redesigned the comments, they were getting a lot of negative feedback from users. But they also noticed that under the new system, stories were getting more comments than ever before. So although there was a vocal minority who weren’t happy with the design, it was an overall success. The moral of the story is that you need to look at the implicit feedback as much as the explicit feedback.

Another thing I took away from Daniel’s talk was that I should read How Buildings Learn by Stewart Brand. I’ve had this recommended to me enough times that I’ve finally decided to buy it.

John Resig: Building Interactive Prototypes with jQuery

John Resig is the creator of jQuery, “the write less, do more Javascript library”. This talk was pretty timely for me. I just started using jQuery a few weeks ago for a Firefox extension that I’m writing, and I’m pretty much in love with it. So it was practically guaranteed that I would like this talk, since it was further demonstration of all that is awesome about jQuery. I did learn one new thing from the talk — I’d never heard of the jQuery Form Plugin before, and it is really cool as well.

I’m not sure what more I can say about this one. If you’re a web developer, or a designer who codes a little, you should seriously check jQuery out.

So that was my day. $30 well spent at meshU. Thanks to the organizers: Mark, Mathew, Rob, and Stuart.

It’s been an interesting 24 hours for anyone who follows the One Laptop per Child project. Yesterday, OLPC announced that they have teamed up with Microsoft to make Windows XP available on the XO. Then it was announced that Walter Bender, OLPC’s former president of software and content, is forming a new organization called Sugar Labs to spearhead development of the Sugar user interface.

This is an interesting development. I started working on OLPC-related projects a few months ago, doing some work on the user interface for the built-in graphics tablet. Back in January, I wrote about how cool I think the Sugar UI is. I really hope that Sugar can gain some momentum on its own, instead of constantly being overshadowed by the political and ethical issues of the One Laptop per Child project as a whole.

I’ve been thinking about buying myself some kind of ultra-portable laptop, and since I find it almost impossible to type on the XO keyboard, I’m currently eying the Asus Eee PC. I don’t think it makes sense to use a conventional desktop environment on that kind of machine, and I think that the current Sugar UI is a really promising alternative. Now that Sugar is being developed separately from the OLPC project, it will be interesting to see if it can develop into a useful general-purpose desktop shell.

In case you just can’t get enough of me on this blog, I’m pleased to announce the following:

Since all my other plans fell through, I decided to show up to the Twitter party (fashionably late, of course). You can get your Dubroy fix in bite-sized chunks at http://twitter.com/dubroy. Hope to see you there!

And from time to time, I bookmark things that strike my fancy at http://del.icio.us/pdubroy. Most of the links are relevant to this blog, so I try to post a link roundup here every now and then.

Via Raganwald, I saw this post by Andrew Birnstock: Perfecting OO’s Small Classes and Short Methods. The post is a summary of an essay by Jeff Bay called Object Calisthenics, from the new Pragmatic Programmers book The ThoughtWorks Anthology.

“Object Calisthenics” is supposedly an exercise to get you to write better object-oriented code. Reading through the suggestions, I couldn’t decide if the article was serious or not. From Andrew’s summary:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

From what I can tell, this really is serious. These are supposed to be the object-oriented equivalent of chin-ups, designed to whip you into shape to write better OO code.

This strikes me as so bogus, I can’t even begin to describe it.

I’m not against OO: I’m a huge fan of Smalltalk, and I cut my programming teeth at one of the oldest object-oriented development shops. In fact, I keep thinking of something that Steve Northover used to say to me when I was on my first work term at OTI:

“That which obscures my code is bad.”

If you’ve ever seen a large body of code that adheres to The One True OO Style^TM — like say, Smalltalk class libraries — you’ll understand that almost every step you take towards “true OO” is just another way of obscuring the meaning of your code. If you break your code up into 10 different methods, then that’s 10 different places I have to look to figure out what is going on. You’re just writing spaghetti code by a different name. If you’re building a very large library, then maybe, just maybe, the additional flexibility is worth it.

I think Paul Graham sums it up best in his essay Why Arc Isn’t Especially Object-Oriented:

My own feeling is that object-oriented programming is a useful technique in some cases, but it isn’t something that has to pervade every program you write. You should be able to define new types, but you shouldn’t have to express every program as the definition of new types.