Archive for the ‘Developer Tools’ Category

The next big concurrent language

Wednesday, October 7th, 2009

Tim Bray has been writing his thoughts recently on the topic of the next big language for concurrency.

Let me start by saying I’m completely an arm-chair quarterback here, I’ve never used a functional language for a real project, but I’ve worked in the area of development tools and multi-threaded applications for many years. I’ve watched a lot of language extensions and libraries come and go over the years claiming to “solve” the problems of parallel coding.  I’ve also seen some pretty fancy analysis done by compilers, which seems like it could be better leveraged if the languages had better ways to communicate the intent of the code author.

Do we need a new language for concurrency?

My assumption is that the development of OO programming was the result of increasing software complexity, not a response to a particular change in the capabilities of computer hardware (like multi-core is hitting us today).

Over the last many years, distributed networks of computers have been a very popular platform for writing software.  There are many libraries and frameworks for dealing with distributed systems, but specific languages that address that need (I’m sure there are some) have not become popular in general.  Distributed programs are still written mostly in languages that don’t have any specific features to support distributed programming.

So I don’t think the need for concurrency itself will drive the adoption of a new language.  The compelling argument for me is the possibility that the needs of multi-core (and hence multi-threaded) programming may drive software complexity far enough that we need another big leap in programming technology.  I’m skeptical that’s the case, but it won’t stop me from theorizing about what the next leap in programming technology might be.  🙂

Eventually we’ll need a new language, what will it be like?

Global state makes multi-threaded programs difficult to write and maintain because it requires synchronization.  The problem is not the synchronization, the problem is the global state. That’s a lesson I take from functional languages. Previous attempts to address concurrent programming tended to focus on encapsulating the synchronization, instead of encapsulating (or abstracting away) the global state.  For example, a parallel language extension that allows you to specify a matrix operation without needing to name any iterator variables has abstracted away the global state (in this case, the iterator variable).  A language feature (like OpenMP) that tells the compiler where and how to synchronize, but still requires you to code the iteration yourself, is hiding the synchronization but not the the global state.

It’s tempting to look for a language that emphasizes functional programming in its design, but that’s not necessarily the right approach.  There are many difficult and complex aspects to writing software, and the problem of global state is just one more. The right response is to look for a language that makes it easy to encapsulate global state.  In general, functional languages don’t necessarily make it easy to encapsulate global state. I think the correct response is to look at languages that can abstract away the complexity of MT coding and global state in effective ways.

So here’s an analogy: A long time ago I took a course on the software APIs used to internationalize software.  My main take-away was the the best way to internationalize any sort of library was to remove all the messages from the library, and only return diagnostic codes.  In other words, the best way to internationalize code is not to have to.  Similarly, the best way to synchronize code is not to have to. You want to encapsulate it into a specialized module.

In a layered application that is concurrent, you want to focus on making the lowest layers of software completely reentrant (that is, side-effect free). It’s generally not a big deal if the very top layer has global state, as long as the top layer is sufficiently thin. You want a language that makes it easy to write side-effect free code, but there is still lots of code that needs to have side-effects that can’t be ignored.

So it seems to me that the key feature we should be looking for is a significantly increased ability to abstract away implementation details.  By the way, any functional language that requires coders to understand how/why/when to write a tail-recursive function loses out big time in the abstraction department.

I was recently inspired by a paper in IEEE Computer that talked about a research language called SequenceL. I discussed it in a previous blog. The benefits of SequenceL are described as the ability to write executable code that maps as directly as possible into a requirements specification in the jargon of the problem domain.  This meshes with the recent discussions of DSLs (domain specific languages) as a good way to encapsulate various concurrent implementations.

Check out my last blog entry about SequenceL, and read the paper, it’s very well written.  If you have a direct link for it, please let me know.

SequenceL : Declarative Language Design

Wednesday, September 16th, 2009

I faithfully scan the tables of contents for IEEE Computer every time it comes out, and every now and then there’s a paper that I find both interesting and well written.  Today I found one called: “Taking Parnas’s Principles to the Next Level: Declarative Language Design” by Daniel E. Cooke and J. Nelson Rushton, at Texas Tech University.  I’d never heard of Parnas, but the paper discusses a programming language called SequenceL, which addresses some of the issue I have with programming language design.  Specifically, both functional and procedural languages make it necessary to “wire down” an implementation too much, and don’t allow enough leeway for an intelligent compiler or an intelligent library to offer a generic software service.  The language discussed in the paper revolves around an increased reliance on declarative syntax to specify a richer set of functionality. You might also describe the approach as heavily polymorphic, but I don’t think that description really captures the elegance apparent in the examples.

The emphasis in the paper seems to be on the ability to create an algorithm implementation that is very close to a natural language specification of the requirements.  In fields where that’s an issue (space shuttle software, in the article) that seems like a good measure of success. But I think the increased level of data hiding and abstraction also lends itself to supporting much more freedom in the compiler, libraries and runtime system to choose implementation details that are best suited to executing the program on particular hardware or in a particular operating environment. Unsurprisingly, when I googled for SequenceL I also found papers with names like: “Automatic parallel control structures in SequenceL” and “Automatic Concurrency in SequenceL”.

Anyway, it was a very stimulating paper. Unfortunately, it’s a restricted download on the IEEE site. If you’re a Sun employee, you can access the IEEE site without a special login, the instructions are available on the Sun internal network at the Sun Learning Services web site. I assume you can also purchase it online from the IEEE site, but I didn’t verify that.

Update: Very interesting.  Two days after I read this paper, I scanned through some slides being presented at Sun by Kunle Stanford Pervasive Parallelism Laboratory.  He discussed the future of highly parallel app development, and his vision includes more emphasis on Domain Specific Languages, using Scala as a base platform for the DSLs.  More support for the idea that current programming languages require you to put too much implementation knowledge into the application level. You can find a set of slides very similar to what he presented on the Scala web site.

Visualizing dynamic library dependencies

Friday, May 22nd, 2009

Darryl Gove has been working on graphical display of shared library dependencies. It seems useful for performance analysis and debugging of dynamically linked applications.

He did one for StarOffice and for Firfox and Thunderbird.

Thursday, May 14th, 2009

OpenSolaris tips

(Direct document link)

Reboot to a specific boot environment:

    # bootadm list-menu
    the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
    default 0
    timeout 10
    0 zfsbe1
    1 zfsbe1 Solaris xVM
    2 zfsbe1 failsafe
    3 zfsbe2
    4 zfsbe2 Solaris xVM
    5 zfsbe2 failsafe

    # reboot 3

Can one programming language work for everything?

Tuesday, April 7th, 2009

There are all kinds of programming languages, and they all have their strengths and weaknesses. Sometimes you want fast prototyping, sometimes you want massive scalability, sometimes you want easy availability of a large library of preexisting code, or access to a specific framework.  Strong typing is useful, duck typing is useful, running on a virtual machine platform is useful, avoiding memory compaction is useful.  Can we get all that stuff in one language?

Given what we know now about language design, is it possible to design a language from scratch, that would work in all those contexts?  In practical terms it’s not very interesting to consider a language without also considering it’s implementation, (virtual machine, compiler, optimizer, etc) so we’re really talking about a software design for an implementation and talking about a language design at the same time.  Maybe it should be called a “programming system”.

Strong typing

One idea I think would be interesting to explore would be whether you can get the benefits of strong typing in a language where types were optional.  There’s a common rhetorical trap here that goes something like this: You have to force everyone to use strong typing, otherwise people won’t do it, and you won’t get the benefits.  I’ll call that the “paternalistic fallacy”.

You want the ability to say that a  module should abide by specific typing policy, and have the system enforce that. That makes it easy to use the system in different ways depending on the needs of your situation.  If you just want to conjure up a quick prototype, you shouldn’t need to define lots of extra typing goop. When you want to export that code and let other people use it, and test the heck out of it, you want to change the typing regime.

Essentially all types can be thought of as an assertion that could be applied at runtime instead of compile time.  Types allow the compiler to optimize in very important ways, like not doing a dynamic lookup for all methods calls. Types allow you to verify the correctness of your code, like trying to assign a floating point constant to an integer variable.  In my mind, these factors boil down to optimization and assertion checking. These features are crucial to have when you need them, but they’re not always appropriate.

Debugger Design

Friday, March 20th, 2009

I’ve spent a number of years in the dbx group at Sun, and over time you collect a lot of coulda-woulda-shoulda stories.  You know what I mean, “This code should really have been designed to do XYZ.”  Or “This module shouldn’t have to talk to that module.”  I figured I’d try to record some of the interesting bits for posterity, so I wrote an essay that I vaingloriously call a whitepaper.  So without further ado:

Goodbye Solaris 9 (for Sun Studio)

Wednesday, August 20th, 2008

We’re making the internal transition to building Sun Studio on Solaris 10 (instead of Solaris 9). This is a big deal because the product bits immediately become useless on any Solaris 9 system. There’s a new libm.so.2 library that became available on Solaris 10, and if you depend on it, you can’t run on Solaris 9. It’s a challenge making sure our vast ocean of loosely maintained lab machines is ready for the change. The good news is we get to use newer, faster hardware. 🙂

I’ll make this post short because I’m using ScribeFire for the first time in forever, and I don’t trust it. I can’t believe blogging is still this hard. 🙁

Introduction to Functional Programming Concepts

Tuesday, January 2nd, 2007

I was reading the RSS feed for dzone and saw this well written introduction to Functional Programming. Since people have been discussing adding closures to Java, I started reading more about functional programming languages.  After spending many years watching people struggle with multi-threaded programs, I’m beginning to think function programming languages might be ready to make a come back.  Such languages encourage you to design data structures and algorithms that are independent of global (or shared) variables.

malloc interposition can’t possibly work reliably

Thursday, October 5th, 2006

In Solaris, many of the routines called from libc are “direct bound” so that references from inside libc will always find the function implementations that are inside libc. This approach prevents outside libraries from interposing (substituting) different implmentations of common functions. The largest exception to this is the malloc family of routines. The malloc routines (when called by libc, for example from strdup) MUST call an externally supplied malloc routine, if one is supplied via LD_PRELOAD or library link ordering.

There is a huge gotcha related to malloc interposing. If you get a pointer from malloc, you have to free it using the free routine in the same library that allocated it. But how do you guarantee that? If every program has libc, then every program will have at least one allocator in it. Any program that uses libumem will have at least two (one from libumu and one from libc). If the user wants to LD_PRELOAD their own memory checker library, it just gets worse.

It gets even worse because malloc libraries implement many additional routines to allocate memory. Let’s say my app calls valloc in libc. Let’s say I want to interpose libmymalloc because it has a spiffy new memory checker that I want to use. Now let’s say libmymalloc doesn’t include a definition for valloc. My app will crash, because valloc gets memory from the libc pool, and free will free it to the libmymalloc pool.

At this point there are people who will say: “Easy, just make sure they all implement the same set of functions.” Well yes, that would solve the problem, if there were a way to do this. But there is no standard for what this list of routines is. Memory allocation libraries are useful because they offer additional functionality beyond the plain malloc and free in libc. So they will always be adding functions that are not in anyone else’s implementation. If I write my app to use libmalloc_alpha.so, and someone interposes libmalloc_beta.so, then all the custom functions in libmalloc_alpha.so that I was calling will still go to libmalloc_alpha.so, but all the customary ones will go to libmalloc_beta.so. The result is undefined.

Unfortunately the idea that you can replace a memory allocator library by just interposing a different one is a widely known “fact”. You can read about how this bit the Solaris libraries in bugid 4846556. The problem came up in comp.unix.solaris recently as well.

Enterprise versus The Developer

Monday, September 18th, 2006

Note: I’m just an engineer at Sun.  What follows is my own personal perspective, and not to be taken as Sun’s official opinion in any way.  To the best of my knowledge I’m not giving away any trade secrets, but I am speaking frankly about Sun’s business model.

I attended an all-hands meeting with Rich Green (Sun’s head of software) today, and there was some discussion at the end about Sun’s approach to the desktop market.  During the discussion I got bitten by a sudden perspective. That happens to me a lot, but I don’t often take the time to write up my perspective or try to communicate it to people.  This time I figured I’d share my ideas.

I guess you could summarize the whole rest of this essay by saying that I believe in the long run  the hearts and minds of the software developer community at large will be won or lost on the basis of the desktop. To understand what I mean by this, read on.

I use Windows at home.

As a Sun employee, I’ve had the usual dilemma for many years now. Should I run Solaris at home? I have a computer, I know how to do my own administration. I could run anything I wanted to. Solaris, Linux, Apple, Windows, whatever.  Today I’m running Windows at home because I don’t have the time or energy to maintain more than one computer, or to maintain more than one operating system.  And windows runs the software I want to run. Games, Productivity software, random internet crap. (No snide comments about viruses please)  I have the same problems as 100 million other people, and when I have a problem, I just google “<my problem>” and up pops the answer.

So how does this relate to Sun and Sun’s business?  Well, I’m getting to that.  During this discussion today about the future of Sun in the desktop market, I was listening at home on my Windows box.  But I’d spent the entire day earlier developing Solaris software.  With my Windows box.  I count myself as an engineer.  Most days, I spend most of time concerned with code.  But the vast majority of tasks I do can be done natively on Windows.  I read and write email. I update internal and external wiki sites. I browse Sun’s internal web. I update bugs using a Java bugster client. I read PDF specs. I use term windows to log into Solaris machines to build things and reproduce bugs, and do other tasks.

Of course, for more intense code hacking, I need XEmacs with local NFS access to my sources, so there are some things I can’t do from home. But I could do them just fine from a Windows machine at work, if I bothered to take my laptop to work.  I was operating today in what I call “hybrid developer” mode. Using one desktop OS to develop software for another OS.

Sun does Enterprise.

Sun has enterprise class hardware, lots of big iron.  Sun has an enterprise class OS, Solaris.  Sun has an enterprise class software stack with open standards based servers.  Sun’s business seems to be totally oriented towards feeding large IT departments, telcos, banks, etc what they need.  Big iron.  But what about Sun’s smaller rack-mount systems, you ask? And what about Sun’s desktop machines? In my opinion, Sun’s smaller hardware boxes are essentially spin-offs to capitalize on technology that we developed for enterprise-class machines and software.  Inside Sun we’re focussed on the customers who buy our stuff.  (As a stock holder, I’m very pleased to see this!) But it represents a bias in our thinking, and a bias in Sun’s internal engineering culture.

I love Solaris, but I’m not an admin.

So here my deal. I’m a Solaris developer. Wait, let me be more clear. I’m a developer of software that RUNS on Solaris.  I am NOT a developer OF Solaris. I’m not in the kernel group. I’m not in the desktop group.  My job doesn’t require me to run BFU to install the latest nightly build of Solaris.  I can do Solaris system administration if I need to, but I don’t do it for fun, and it’s not part of my job.  I love using Solaris, but I don’t love administering it. Solaris is pretty damn painful to administer compared to a desktop OS.  But that’s not a fair comparison because Solaris is totally geared towards enterprise users, and not towards desktop users.

Software Updaters.

One area of functionality I wanted to talk about is web-based software installers and updaters. There are two groups of people I want to talk about here. Each group sees a problem, and is trying to solve it. And each group thinks the other group’s problem is the same as theirs. (Actually, these groups are imaginary groups, because I’m really talking about perspectives and not individual people.  The perspective differences in Sun cause language problems, communication breakdown and lack of synergy between groups.)

One group has the enterprise perspective.  It’s focused on things like smpatch and updatemanager for delivering Solaris patches. One group has the desktop perspective.  It’s focused on things like blastwave.org and pkg-get for delivering things like Ruby compiled for Solaris x86. The desktop perspective says: Linux uses apt-get (or red carpet or whatever) to update application software and OS packages both, why can’t Solaris just convert to using some better than patchadd and pkgadd? The enterprise perspective says: Well, once we get updatemanager up and running a little better, we can eventually start to include unbundled applications in our centrally controlled server-based software distribution model.  Both perspectives make perfect sense, but only if you’re looking in one specific direction.

How to get Developers.

Sun has several approaches that it could use to getting Solaris developers. I’ll list them in order of the impact they would have on developers: 1) Get Solaris on lots of desktops so that it will be a natural and easy starting point for new software development. 2) Embrace more fully the “hybrid” nature of much of today’s Solaris development. 3) Do whatever we can to encourage multi-platform projects to support and distribute software for as many flavors of Solaris as possible.

Option 1 puts the user dead center inside a rich environment of wonderful Sun technology like dtrace, ZFS, zones, Xen support. etc, etc. This will be contagious.  If you’re familiar with the Sun desktop, and you’re familiar with the Sun administration commands, your software will end up working better on Solaris, and you’ll be more likely to stick with Solaris. That’s good for Sun. Option 2 is one step removed. Hybrid development is what I do at home.  Use a Windows, or Linux, or OS X desktop, but develop software for Solaris. If you’re doing primary development on Solaris, your software will be more likely to run best on Solaris.  I might still be using Solaris as my primary development platform for the software that I build, but my daily interaction will be with a different OS. The one that runs on my desktop. Option 3 is another step removed.  Sun will benefit if more open source software is compiled and distributed for Solaris.  If Sun can make it easier to port software to Solaris, that’s a step forward, too.  And there’s plenty we could do to help that. All of these options are opportunities for Sun to focus on, if we really want to get more Solaris developers. Development tools support and basic OS support could be tuned towards supporting those kinds of users.

But it’s a slippery slope.

Having your OS be on the developer’s desktop is the core of getting a really healthy developer community. As the user gets more and more removed from Solaris, they start to see it as just another platform that they might or might not port to.