Open Source Talks at Google, and VIM creator

Google has an interesting talk about “How Open Source Projects Survive Poisonous People” at Google Video.

On February 13, they’re going to have the creator of VIM, Bram Moolenaar, giving a talk on VIM7.  What’s funny is that Bram, who has been working full-time on VIM for the past few years (living entirely on donations and money votes for VIM features) has now been hired by Google.  Smart move.

Spirited Discussion with Miguel de Icaza on Mono and Microsoft

I got fired up by the evidence coming out of Microsoft from yesterday, and decided to write a post to Miguel de Icaza’s blog.

Here’s what I wrote:

Hi Miguel,

It looks like a new set of “Halloween Documents” have come out, thanks to a case in Iowa, Comes et. al. v. Microsoft (http://iowaconsumercase.org/index.html). I’m wondering if you have any comments on this document in particular, which suggests that Microsoft management knew full well they were “stealing Java” to intentionally marginalize the cross-platform language issue.

A select quote from the document, “Screw Sun, cross-platform will never work. Let’s move on and steal the Java language.”
Here’s the e-mail archives, which was submitted into evidence:

Click to access PX_2768.pdf

I’m wondering, given these thoughts from within Microsoft management, and given the recent news of Sun open sourcing the Java language under GPL terms, how is it that you can still push for the Mono project on Linux? Aren’t we always going to be fighting an uphill battle against a monopoly company protecting its biggest cash cow: the Windows platform?

Although my question was more “devil’s advocate” and meant to rile him up, Miguel provided some of the strongest and most cogent arguments for Mono that I’ve seen on record.

I just want to say great work to Miguel and the Mono team, and that if you ever doubted your raison d’etre, all it would take is reading this thread to be convinced! You’ve certainly convinced me!

Update: it’s really this kind of dependency on Windows I’m worried about in .NET. I think it’s just that the culture of the Java runtime is one of platform independence, whereas .NET from Microsoft is one of “platform dominance,” and Mono is some sort of stepping stone between Microsoft’s single-platform vision and those of us who want to write cross-platform apps using .NET.

It’s Official Now: Microsoft Stole Java to Minimize Cross-Platform Languages

Well, I’ve always suspected that C# was nothing but a Java rip without cross-platform support, meant to marginalize Java so that cross-platform languages don’t become as pervasive as Microsoft’s single-platform, Windows-only languages. Now, evidence has come out of Microsoft e-mail archives that proves not only that they just “stole Java” in those pivotal years, but that managers knew full well they would never make an effort to keep the language cross-platform.  A classic “embrace and extend” situation.
A select quote from the document, “Screw Sun, cross-platform will never work. Let’s move on and steal the Java language.”

You can read the entire thing in a scanned copy from the Iowa case Comes et. al. v. Microsoft Corp.

Update: my discussion with Miguel de Icaza makes this seem “less official,” but I still think the mentality from this document also pervaded the mentality of .NET development, specifically that cross-platform would never be a goal of Microsoft .NET.

Software Engineering Management, In a Nutshell

Just saw this on Salon.com, in a letter to the editor about Scott Rosenberg’s new book, “Dreaming in Code”:

There are three options you have when developing software:

1. Quality

2. Lots of features.

3. Low cost

Pick any two.

When you actually go through the combinations, it’s quite funny, and poignant.

Also, check out this excerpt from Rosenberg’s book, called “Words fail us.”  I’m currently working on a software project and we’re doing lots of new and innovative stuff, and I can’t even express how much I connect with this article.  Choosing the right vocabulary may be the single toughest thing in working on software team projects today.

Common Criticisms of Linux, parsed and analyzed

The following post has been sitting in my “drafts” section of WordPress for a good while. I don’t know why I never posted it — it’s been there for more than a year. I think I just thought the article deserved such careful attention that I never sat down to really edit it and prepare it for publication.

The topic is on the common criticisms of Linux, and I think it’s time for me to finally post my thoughts, given the upcoming release of Windows Vista and related products.

Awhile back, /. posted an article entitled “Is It Wrong to Love Microsoft?” The article is horribly written, but does have one point to make: why is it that on /. and other technology news sites like OSNews and Kuro5hin, everyone loves Linux almost unconditionally, and hates Windows unequivocally? I personally am unfond of blind faith as much as I am offended by blind hatred. I’ve thought long and hard about the pros and cons of Linux and Windows, and think I can come up with a pretty balanced evaluation of the two.

Oftentimes the criticisms thrown at Linux are hard to parse, mainly because the authors of these criticisms don’t know much about system design themselves. Having studied it at University, and having been a 10-year user of Windows and Linux (and a 6-year user of Mac OS since version 9), I figured I should chime in.

First, as often happens when evaluating arguments of any kind, one needs to identify the different kinds of critique, and break them down into the smallest possible groups so that they can be evaluated fairly. Broad statements like “Linux is broken” or “Linux is impossible to use” do not identify specific problems, but merely express sentiments, probably acquired through firsthand experience with a particular set of conditions.

Futhermore, attacks mounted at Linux aren’t mounted at Linux “the kernel” but at the whole set of Free (and sometimes, commercial) Software that runs on Linux, which is quite broad and diverse (and not accountable to any one development team, not even distributors). As a result of this, the attacks often seem focused on the whole system, when in fact concern only a small part of the system, and quite often that small part is already in the process of being “fixed”. So, in order to evaluate these arguments, I will begin by pointing out the general complaint lunged at Linux, and then break it down into the proper categories and evaluate each of those in turn, placing whatever context I can to help understand the situation better.

Continue reading Common Criticisms of Linux, parsed and analyzed

Solving “accidents” and “essences” of programming with better languages

Note: this post was written in January 2007, but it has stood the test of time.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination.

Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

… The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.

Frederick Brooks, author of the The Mythical Man-Month, distinguished between two problems in software development: the accidental problems and the essential ones. You can read Brooks’ watershed article on this topic, “No Silver Bullet”, freely available online in HTML or PDF, or as part of his book.

Those in the industry like to argue that we have made huge leaps in terms of the “accidental” problems in recent years. Programmer productivity is better with the help of better software revision systems, but more importantly there are RAD tools, like user interface builders and powerful IDEs, like Eclipse and Visual Studio. Do I think we’re headed in the right direction?

In a sense. I think those tools are useful, but only because I think all we can do is shrink the accidental problem as small as possible, and then do our best to tackle the essential. The major win in terms of the accidental and even the essential is high-level programming, and I mean really high level, like Python.

Why is this important? Well, Brooks once talked about how PL/I was a great software engineering language because the statements written to the compiler are “pretty close” to the “thought stuff” the programmer is working with in his head. But PL/I is nowhere near there (neither is C++, or even Java or C#). However, Python heads in that direction.

In my head, unless I really am immersed in C code all the time, I don’t think of things like types, memory management, or, God, pointer arithmetic. When we solve problems, we solve it in something computer scientists have used for years: pseudocode. Pseudocode is nothing more than code that expresses an algorithm or approach without worrying about the gory details of the underlying hardware.

Python isn’t quite pseudocode, but it’s closer than anything else I’ve seen. And that’s a huge help to productivity not just from the point of view of the single developer, but, I’d argue, also from the point of view of a team of developers. Code readability is hugely important in team environments. C and Perl can be very unreadable, which makes them ill-suited to team development. Java and C++ are better, but even they suffer from some readability problems, where the actual solutions can be masked by “best practices” and strange ways of exploiting constructs of the language. Python can be hacked too, but it tends not to be, and it tends to have very high readability.

But what about the tools mentioned above (Eclipse & Visual Studio)? I often wondered about all the *nix programmers (including many of my past Computer Science professors) who still load up terminal with vim or emacs for their programming needs. Wouldn’t they benefit from the latest and greatest in IntelliSense, Refactoring, CallTips, SaneOnlineDocumentation, and any other CamelCase ideas I can think of for a development environment?

Well, most *nix users would say that stuff is unnecessary–and in many senses, they are right. The essential problem remains, no matter how fancy your IDE.

A lot of *nix developers shrink their accidental problem on a “as-needed” basis, by coding scripts or plugins or configurations for their highly-extensible text editors. Or incorporating tooling that is freely available online in the wider F/OSS community.

But nowadays, productivity is starting to be a concern even in the F/OSS world, where users have traditionally stuck with the old “mortar and pestle,” or, should I say, “gcc and gdb”.

But Python offers a nice, alternative path, I think. The accidental problem is worth shrinking. But I think it can be done simply by one major refocus:

(1) make the language usable, not the tool. IMO, this is already done with a high-level language like Python.

…and…

(2) create source code analyzing tools that integrate with development environments to make the language-bearer more productive.

You can see enormous success in (2) with the Eclipse IDE project for Java programmers. My main problem: Eclipse’s focus is on a language that isn’t very usable, that is, Java. Java is certainly better than C, but still, it has significant problems that stop it from connecting me (the programmer) with my problem-solving ideas — that is, the “thought-stuff” of programming, as Brooks called it, above.

At my new job, I work with Java eight hours a day, but my code just doesn’t read and work like my Python code, which is much closer to the underlying algorithms and approaches. Java certainly pushed forward OOP on the masses of computer programmers, but it did so without incorporating other non-OOP concepts, whether from the dynamic language, scripting language, or functional language traditions. One simple example: having Lists and Hashes as built-in types, with tons of syntactic sugar, for crying out loud! Most problems break down to List and Hash problems, after all.

What’s more, programmers have learned that OOP, per se, is no panacea. I’ve seen many convoluted OOP designs that I wish were written functionally, or even just procedurally, and which might have been more performant (and more comprehensible) if they had been written in a non-OOP style.

As the Python community says, “Practicality beats purity”. The “legacy” OOP software engineering community thinks that there will be a silver bullet (OOP! AOP! XP! MDE!). But: I think just getting programmers closer to the “thought-stuff” — via high-level languages like Python, and lightweight tooling around the editor and the command line — will be an effort with better rewards.


Update from the future in June 2020, 13 years later: I was right. I’ve incorporated all my years of experience writing professional Python into The Elements of Python Style, which you can read online. If you’re still stuck in a programming language like Java, C#, or C++ which is far away from the “essential”, you’re well advised to check out my Idiomatic Python Resources compendium. I personally can’t believe just how successful Python has become in the intervening 13 years. Its massive success surprised all of us, the early champions and fans, included. And I don’t personally miss my RAD tools one bit. I only ever open an IDE when working with Java code, specifically, IntelliJ. But for every other language, vim and the “UNIX IDE” suffices. Plus, with projects like VS Code, Onivim 2, Language Server Protocol (aka langserver, LSP), and Jupyter, you can “have your cake and eat it, too”. Also: Brooks was right. Despite the tooling improvements (most notably, cloud computing), the essential problem of programming remains.

Free and DRM-Free E-Books

I got a Nokia 770 for Christmas, to replace my aging and dying Palm V. I’ll probably write more about the 770 and the Palm V later, but suffice it to say that I got the Palm V when it came out, approximately 10 years ago, and have used it ever since. My main uses for it were AvantGo and Vindigo, although in the past I did get other uses out of it as well. I plan to keep the Palm around mainly for the Vindigo features, which I haven’t seen done better anywhere else. (No book on the planet has as much information about NYC as my 8MB Palm V with Vindigo loaded on it.)

I basically got the 770 because of all the great stuff I heard on Teleread and other sites about its use as a portable e-book reader. Indeed, that has been the most pleasant experience on the device. With the Evince PDF viewer and with FBReader (an Open Source ebook reader for a lot of different formats, including HTML, Plucker, and zTxt), I am able to read a ton of stuff while I’m in my commute, and all on a beautiful 800×480 screen that fits in the palm of my hand. (Yes, finally I get to read with serif, anti-aliased fonts!)

I have been overwhelmed with how many free e-books you can find online, thanks in part to efforts by groups like Creative Commons. Here are some good ones:

Feel free to post more in comments!

The Three-Way Division of Web Development Labor

There is a great article posted by a developer of the open source FreeMarker project on a proposed “third” role for web development teams — something between a backend application developer and a frontend web designer.

Check it out.

I have to say, so much of this article rang true for me. I just finished a web application in which we had four developers but two main rules: backend developer and frontend designer/developer. Due to the type of project it was (and the skillsets of the people involved), backend work was done by 3 of the 4 team members, and frontend work was done by a sole designer.

The issues we had were that:

  • The backend developers could only make guarantees about what kind of object to pass to the view. But often, in order to get access to other “global” objects, the frontend designer would have to hack controller code as well. (Luckily, data services were tiered off out of the controllers, so at least the designer didn’t have to muck about with SQL.)
  • The designer hated the idea of pushing some logic “back” into application code. So, though we as backend developers proposed a layer for configuring things like which menus to display on each page, etc., the frontend designer preferred to engage in the copy-paste-modify antipattern instead, so that it could just “get done.” I can see why: it’s a pain to context switch from JSPs, HTML and CSS to Java POJOs that then will have to be checked using JSTL anyway!

If, early on, we had decided to use FreeMarker instead of JSTL, perhaps the frontend designer could have had access to more powerful macros, and wouldn’t have done the copy/pasting. But I think overall, the two tiers are too few; I agree that you need someone to sit in between and think about how to cleanly integrate backend logic and frontend design.

Linux Desktop Talk at NYU

I gave another talk for CANYU and the emerging open source clubs at NYU about Linux on the desktop. Here is the synopsis:

LINUX AND FREE/OPEN SOURCE SOFTWARE

The State of the F/OSS World Update
with talk/demo by Andrew Montalenti

December 5, 2006 @ 7pm
Room 813, Warren Weaver Hall

Open source software is now mainstream. Whether it’s the nearly ubiquitous Mozilla Firefox browser, the Azureus peer-to-peer client, the Eclipse IDE, or the Linux kernel, almost everything in the computer world has been touched by free / open source software developers collaborating across the globe.

Judging by the state of the community, this movement doesn’t seem to be losing steam. With Microsoft Windows Vista around the corner offering a potentially bloated and hardware-requirements-heavy experience, desktop Linux operating systems are taking aim at the big giant, with big support around Ubuntu, Fedora (Redhat), and SuSE (Novell), among others.

So, what’s next for the free / open source world? That’s what this talk is meant to help you find out. After explaining a bit of the history of free and open source software, and the history of recent community and corporate efforts to make it widely available, this talk will show off some of the new, cool technologies coming out of the open source community, such as 3D desktop effects, productivity tools, enhanced multimedia support, better support for laptops, and a full suite of industry-grade development tools. The talk will also discuss some of the legal and intellectual property issues facing the open source community, with a particular focus on the recent news coming from the Novell / Microsoft deal and Sun’s decision to open source Java.

Who is this talk meant for? Anyone who hasn’t tried out Linux on their desktop, or anyone who is at least mildly interested in the current and future state of the computer industry. Free / Open Source software has completely rocked the industry, changing every aspect of it from top to bottom, and this wave is only growing bigger every day. NYU students interested in copyright issues surrounding open source may also find this talk valuable.

In any event, this won’t be a boring lecture — it’s meant to be interactive and fun!

The speaker will be bringing free CDs of Ubuntu Linux, a community-driven desktop Linux operating system which you can install on almost any home PC! Come for the free CDs, stay for the revolution.

It went very well, with about 10 people in the audience. You can download the slides in OpenOffice or PDF. Admittedly, the slides aren’t as cool without the live demo of Beryl I did at the talk itself. Yay 3D desktop effects.