Everything is public

Steve Yegge started blogging again recently and his second post back (which is almost a month old by now) is essentially a parody of Java’s access specifier system and the prevalence of the “private” attribute. The debate over public vs private comes up every now now and then in object-oriented programming and has its fair share of people on either side of the line. So when Steve suggested that private just go away (or seemed to suggest that anyway) he of course got attacked with counter-examples and all sorts of cases where private is helpful.

Saying that everything should be public is certainly an idea that takes getting used to. It’s like saying that you should publish the details of your drunken escapades on your blog. It’s unsettling, but then again, the pictures are probably already on Facebook anyway. I think there are two issues here — one is for fields, and the other is for methods.

Though Steve seems to say that fields should be public (or have getters and setters on them), I personally tend to go the other way: fields should be private by default and only accessible through getters and setters. I like the way Ruby does it — everything is private by default but the accessors are generated by metaprogramming, so you don’t have the junk lines of getWhatever and setWhatever that you do with Java. Direct field accesses like Java and C++ allow are just bad ideas.

For methods things are the other way around. Firstly, I don’t like the idea of invoking methods on an object. I far prefer the Smalltalk notion of sending messages to objects and having them respond. I think it’s a far better conceptual model than methods and the private/public debate goes away in that model. If your object responds to methods, then being able to use private and public means that the object knows of and cares about where about the message is coming from. However, this breaks encapsulation. Ideally an object should respond to a particular message the same way irrespective of where the message comes from.

But, you say, what of the real world where ideals don’t necessarily hold? Hmm… let’s see what happens to software development under the assumption that all your methods and functions are callable from outside. To start off, you have to be careful about what parameters your methods take. You can’t assume that they’ve been pre-sanitized which means that either you’ll have to check them yourself or fail cleanly (and maybe send a stern warning up the chain). This may be a bit annoying, but I’d say it’s on the same level as dynamic typing — you’re never 100% sure of what type the arguments are so you take appropriate measures.

Now let’s talk about safety. One of the arguments in favor of private is that you don’t want methods to be abused and put the object in an unusable state. Again, I don’t think this is as big of a problem as it’s made up to be. It just involves rearranging where checking occurs. Presumably, if you have a private method that makes delicate changes to your object, you have a public method somewhere else that approves the changes and then calls said private method. Why not put the approval inside the private method and dispense with the public method entirely? If you want to make a change to an object, call a method to do it. If it works, fine. If not you get an error back.

I should make it clear at this point, that I don’t have any real world example to back up my claim (at least no examples that aren’t hopelessly contrived). What I’m talking is refactoring to meet a design constraint — that of total publicness. People will kick and scream and say that it breaks their careful separation of functionality into methods, but I think it’s just a design pattern, like dependency injection for example. And the trade-off to that is probably more flexible, more powerful software systems.

If everything is public (and designed from the ground up to be public) you start writing code that’s meant to be used by other code. Which in turn makes it easier to use and extend your code. I think you’ll eventually end up with something like Emacs — lots of public functions that do useful things to an object (the text in the editor) and an awesome array of functionality made possible by using these public functions. There is a fundamental change in programming and building ideology that needs to take place. With full publicness you can’t have a nicely¬†bureaucratic language like Java. You’re going to end up with something that’s far more open and flexible like Ruby, Python or *shudder* Lisp.

I think that a lot of the heightened discussion surrounding Steve’s suggestion stems from the nature of the Java language. It’s certainly meant to be used by large corporate teams and is designed to stop programmers from hurting themselves (or stepping onto someone else’s turf). “Bureaucratic” is perhaps the best way to describe the language. If you take out private from a language like that, you lose most of its raison d’etre. So is private a good thing? Probably not. Does it need to stay in Java? Probably.

I’d like to reiterate that I think that message-passing is a superior way to think about object-orientation and it makes the public/private debate unnecessary. That’s why the language I’m building for my thesis will have message-passing. I’m also stealing Ruby’s private-by-default and metaprogramming for accessors.

Sunday Selection 2010-08-22


The James Franco Project This has nothing to do with computers, technology or programming. James Franco is an actor who is leading a very full life — he’s acting full time (on multiple projects) while working on multiple graduate degrees at different places around the country. Certainly not something that’s recommended for everyone, but it goes to show just how much one man can do if he puts his mind to it.


Dieter Rams – More is Less The design of technological objects has always fascinated me and Jonathan Ives might be the design man of the current times, but this video shows off Dieter Rams’ work and some of his key insights and you can see them reflected in the modern gadgets that we consider to be attractive.


Foursquare I’ve just recently started using Foursquare (yes, I know after Facebook announced places) which is an iPhone, Android and Blackberry app that lets you “check-in” to places you visit and gather points for traveling and visiting. It’s a fun little utility and makes for interesting games with friends (and probably helps generated revenue for local businesses). I’m hesitant to say if it’s actually useful, but it’s definitely worth trying out.

Note: I find that I’m starting to explore less and less and am considering retiring the software section in upcoming weeks. Let me know if you have any suggestions.

Sunday Selection 2010-08-15

Firstly, Happy Indian Indepdence Day! Enjoy your freedom, use it well, it was hard-earned. Moving on…


The early history of HTML Have you ever wondered how the great World Wide Web came to be? Apparently it’s a bit of a mystery but this article does a good job of piecing things together and giving some insight into how HTML.

What happened to Yahoo! Even though Yahoo still exists and owns some really great websites (like Delicious and Flickr), it seems to have completely dropped off the map in recent years. Paul Graham (whose startup was bought by Yahoo!) takes a look at why Yahoo! seems to have lost its relevance.


Twilio on NY Tech Meetup It’s not that often you see people writing code live during presentations, so when you do see people whipping up live code to create usable webapps and then opening them up to the public, that’s something really worth watching.


Instapaper aims to bring back the practice of reading long-form pieces of the Internet. It lets you save webpages and also helpfully extracts the text from the page. There are iPhone, iPad and Kindle apps to help you read anywhere and anytime.

I’m making a language

Or as some would say I’m starting a new religion. But no, in all seriousness I am creating a new language as ¬†part of my senior honors thesis. Why am I doing this? Because I need a good topic for my honors thesis and programming languages are what I’m really interested in. I also want to go to grad school next year for programming languages and I think the best way for me to learn about languages is to make one from the bottom up.

This is the first time that I’m making my own language, but I have been studying programming languages for the last 2 to 3 years. And I want to take those lessons learned and apply them. I’m trying to strike a balance between taking the best of what’s out there and putting in original ideas. There are a lot of great ideas out there but they’re spread across lots of different languages. Some languages like Ruby do a great job of pulling together the best of what’s out there. Under normal circumstances I would be perfectly happy with building a language that does nothing new. But this is an academic honors thesis and I would be really really disappointed with myself if I didn’t contribute anything new.

What am I going to do that’s new? I want to solve a problem that is actually being faced by programmers on the front line and though I admire the theory behind languages, I’m more interested in implementation than pure theory. One clear problem in our field is the rise of slower, parallel processors, multicore CPUs in particular. And we have very little idea of how to use all those cores probably. There are certainly solutions that are being proposed — threads, software transactional memory, Actors, so on and so forth. But these tools are generally considered beyond the reach of everyday programmers. What most programmers are acquainted with is object-oriented programming. My idea is to take an object oriented language and make it concurrent from the bottom up. The naive idea (that I have to significantly research and refine) is that each object is its own thread of operation. This is similar to the Actor model and I’ll need to study and think more to see how to differentiate between that and what I want to do.

But as I said there are a lot of good languages out there with great ideas and I’m going to shamelessly take as many of them as I can. Everything will be an object, but it will be prototype-based (a la JavaScript), not class-based. Syntax-wise it will be elegant and homoiconic: that is there will be as few special syntactical constructs as possible and programs will be data structures in the language itself. This is to lay the groundwork for macros, though I probably won’t be getting to that any time soon. However, it will have first class functions from day one and I’m going to try like hell to make everything (or make it possible to make everything) first-class. And this isn’t just for functions, I want to extend it to tests, constructs and even documentation. All of these are good ideas that have been tried and tested before, I’m just combining them in a new (and hopefully better) way.

Technology aside, the language will be completely open source, probably under the GPL v3. As for the name, I’m probably going to call it Parley. I want a name that implies discussion. Plus it opens up a whole world of pirate-related metaphors and names for later use and I love word-play. I don’t plan on really working on it until the end of August, though I will be reading up and throwing ideas around. Code will be on Github as soon as I have something that works.