It’s sometimes easy to forget all of the little things that I do during the week, and how they add up to something of note. In the moment--any moment--most things seem much smaller and much less important than they do with a little bit of perspective and when viewed out of context with coordinating achievements. So here’s the highlights from last week:

I gave up on the “having two sites to maintain thing,” and have merged Critical Futures into the tychoish.com blog/wiki. I really like this, and it gave me some time to get elbows deep into the wiki system, which means things work better, the display is a bit cleaner, my life is easier, and I’m very happy with it. Also, as part of this process I’ve been revising the index page, and I think it is in a state that I’m really pleased with.

Some dancing friends on Facebook said “wouldn’t it be nice if there was a wiki for contra dancers.” Now there is. Contra Dance Wiki is there for you all if you want it. I’ve done some preparatory work on the index page, and I’ll continue to add things as I can.

The work I’ve been doing in the last few weeks with ikiwiki, both for tychoish and now for the CDW means that I’m really close to being able to share all of the assorted templates and configuration files I use to make this work. It’s all in the git repository for tychoish, but I’m going to pull together a more generic version so people can get started easier. It might also make sense to write a deployment script of sorts. We’ll see.

I meant to post this on Friday, but posted my review of maple morris, because I didn’t want that to linger. In any case, I had a brilliant weekend singing (and dancing) in Western Massachusetts. It has however left me a bit under the weather, so I’m spending a day recovering and doing some writing. Good stuff there. I’ll write about WMSHC soon.

A few weekends ago, I went to very weird get together. The week before I went to upstate New York to a festival that drew 5000 attendees. Then, I went to Washington, DC to dance with 24 or 25 other people from across the country and Canada. I think of it as “my generation,” Morris dance gathering.

This May marks my 10th anniversary of being a Morris dancer. I’ve spent most of that time, easily being twenty years away from the next-youngest Morris dancer on my team. Morris isn’t aging quite that fast: but there are a lot of quirky things that happen given the small sample sizes.

I’ve been involved in the folk world for years. Lots of folk dance and traditional music. I’m so accustomed to this, that I’m not really sure what people who aren’t do with their time. When I think about other communities, I always reach back to experiences and phenomena that I’ve seen in the folk world.

While I grew up in the folk dance world, I’m coming to terms with a couple of things: First, folk communities are different in different parts of the country/world, and the community in Boston (or New York, or Philadelphia) is very different from what I grew up with. Second, I’m realizing that while I’m “a young person” who grew up with music and dance, I’m no longer “a folk dance kid,” (and that’s a nifty thing to experience.)

Given this, I’ve had the following Morris related thoughts, that seem worth recording:

• It’s really nice to be part of a single age cohort in this activity, mostly because I’ve not had significant opportunity to dance with people in my general age group.
• I quite enjoy being more than just a familiar face in a contra dance line, or someone that you see across the square when singing sacred harp.
• These weekends always challenge me to be a better dancer, and make me realize that I need to focus and work on certain aspects of my dancing.
• While it’s in-ideal to have gatherings capped at really small numbers, having a small group means a greater strength of connection between everyone, and it means that a few people can do the organizing work without much institutional/organizational overhead. That’s really cool.
• Once again, my motto is “you don’t have to do everything.” Which is particularly difficult around Morris. But I think by avoiding overdoing it I’m able to: avoid injury and have greater successes at the things I do try. Can’t argue with that. I’m young and I hope to dance for many years to come, and there’ll be time enough for Sherborne then.

I went to the Dance Flurry a couple of weeks ago (!) and I wanted to write a few notes here about the experience, and a little bit of reflection. I hope you’ll spare me the indulgence.

A year ago, I was pretty new to the East Coast: I didn’t really know people, and while I’d been dancing for a while and I wasn’t a bad dancer by any means, but I wasn’t quite comfortable in my own skin in big dance events.

This year, many things were different. I’d been to a number of other important regional events: I knew more people, I knew the bands and the callers, I knew the venue, and I knew what to expect.

It was great. I got to dance with friends that I hadn’t seen in months. I got to dance to great bands. The callers were top notch, and there was never a shortage of great ways to spend my time.

My motto for the weekend was “you don’t have to do everything.” Which meant not staying until 1am, just because there was a dance going on; or not showing up at 9am because that’s when things started. Prevailing sanity is an amazing thing.

It meant that I didn’t hurt myself; I didn’t come back from the vacation more tired than I was when I left; and I still had a great time.

It’s amazing.

With the new laptop, I once again have more than one computer, and with it a need to synchronize the current state of my work. This is a crucial function, and pretty difficult to do right: I’ve had multiple systems before and condensed everything into one laptop because I didn’t want to deal with the headache of sitting down in front of a computer and cursing the fact that the one thing that I needed to work on was stuck somewhere that I couldn’t get to.

I store most of my files and projects in git version control repositories for a number of reasons, though the fact that this enables a pretty natural backup and synchronization system, was a significant inspiration for working this way. But capability is more than a stones throw from working implementation. The last time I tried to manage using more than one computer on a regular basis, I thought “oh, it’s all in git, I’ll just push and pull those repositories around and it’ll be dandy.” It wasn’t. The problem is, if you keep different projects in different repositories (as you should, when using git,) remembering to commit and push all repositories before moving between computers is a headache.

In the end synchronization is a rote task, and it seems like the kind of thing that was worth automating. There are a number of different approaches to this and what I’ve done is some very basic bash/zsh script¹ that takes care of all of this syncing process. I call it “git sync,” you may use all or some of this as you see fit.

git sync lib

The first piece of the puzzle is a few variables and functions. I decided to store this in multiple files for two reasons: First, I wanted access to the plain functions in the shell. Second, I wanted the ability to roll per-machine configurations using the components described within. Consider the source.

The only really complex assumption here is that, given a number git repositories, there are: some that you want to commit and publish changes too regularly and automatically, some that you want to fetch new updates for regularly but don’t want to commit, and a bunch that you want to monitor but probably want to interact with manually. In my case: I want to monitor a large list of repositories, automatically fetch changes from a subset of those repositories, and automatically publish changes changes to a subset of the previous set.

Insert the following line into your .zshrc:

source /path/to/git-sync-lib

Then configure the beginning of the git-sync-lib file with references to your git repositories. When complete, you will have access to the following functions in your shell: gss (provides a system-wide git status,) autoci (automatically pulls new content and commits local changes to the appropriate repository,) and syncup (pulls new content from the repositories and publishes any committed changes.

syncup and autoci do their work in a pretty straightforward for [...] done loop, which is great, unless you need some repositories to only publish in some situations (i.e. when you’re connected to a specific VPN.) You can modify this section to account for this case, take the following basic form:

syncup(){

   CURRENT=`pwd`

   for repo in $force_sync_repo; do
       cd $repo;

       echo -- syncing $repo
       git pull -q
       git push -q

   done
   cd $CURRENT

}

Simply insert some logic into the `for`` loop, like so:

for repo in $force_sync_repo; do
   cd $repo;
   if [ $repo = ~/work ]; then
      if [ `netcfg current | grep -c "vpn"` = "1" ]; then
          echo -- syncing $repo on work vpn
          git pull -q
          git push -q dev internal
      else
         echo -- $repo skipped because lacking vpn connection
      fi
   elif [ $repo = ~/personal ]; then
       if [ `netcfg current | grep -c "homevpn"` = "1" ]; then
          echo -- syncing $repo with homevpn
          git pull -q
          git push -q
       else
          echo -- $repo skipped because lacking homevpn connection
       fi
   else
      echo -- syncing $repo
      git pull -q
      git push -q
   fi
done

Basically, for two repositories we test to make sure that a particular network profile is connected before operating on those repositories. All other operations are as in the first example. I use the output of “netcfg current”, which is an ArchLinux network configuration tool that I use. You will need to use another test, if you are not using Arch Linux.

git sync

You can use the functions provided by the “library” and skip this part if you don’t need to automate your backup and syncing process. The whole point of this project was specifically to automate this kind of thing, so this--though short--is kind of the cool part. You can download git sync here.

Put this script in your $PATH, (e.g. “/usr/bin” or “/usr/bin/local”; I keep a “~/bin” directory for personal scripts like this in my path, and you might enjoy.) You will then have access to the following commands at any shell prompt:

git-sync backup
git-sync half
git-sync full

Backup calls a function in git-sync to backup some site-specific files to a git repository (e.g. crontabs, etc.) The half sync only downloads new changes, and is meant to run silently on a regular interval: I cron this every five minutes. The full sync runs the backup, commits local changes, downloads new changes, and sends me an xmpp message to log when it finishes successfully: I run this a couple of times an hour. But there’s an exception: if the laptop isn’t connected to a Wifi or ethernet network, then it skips sync options. If you’re offline, you’re not syncing. If you’re connected on 3g tethering, you’re not syncing.

That’s it! Feedback is of course welcome, and if anyone wants these files in their own git repository so they can modify and hack them up, I’m more than willing to provide that, just ask.

Onward and Upward!

Sorry for the lame title. I was thinking the other day, about how awesome SSH is, and how it’s probably one of the most crucial pieces of technology that I use every single day. Here’s a list of 10 things that I think are particularly awesome and perhaps a bit off the beaten path.

Update: (2011-09-19) There are some user-submitted ssh-tricks on the wiki now! Please feel free to add your favorites. Also the hacker news thread might be helpful for some.

SSH Config

I used SSH regularly for years before I learned about the config file, that you can create at ~/.ssh/config to tell how you want ssh to behave.

Consider the following configuration example:

Host example.com *.example.net
User root
Host dev.example.net dev.example.net
User shared
Port 220
Host test.example.com
User root
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
Host t
HostName test.example.org
Host *
Compression yes
CompressionLevel 7
Cipher blowfish
ServerAliveInterval 600
ControlMaster auto
ControlPath /tmp/ssh-%r@%h:%p

I’ll cover some of the settings in the “Host *” block, which apply to all outgoing ssh connections, in other items in this post, but basically you can use this to create shortcuts with the ssh command, to control what username is used to connect to a given host, what port number, if you need to connect to an ssh daemon running on a non-standard port. See “man ssh_config” for more information.

Control Master/Control Path

This is probably the coolest thing that I know about in SSH. Set the “ControlMaster” and “ControlPath” as above in the ssh configuration. Anytime you try to connect to a host that matches that configuration a “master session” is created. Then, subsequent connections to the same host will reuse the same master connection rather than attempt to renegotiate and create a separate connection. The result is greater speed less overhead.

This can cause problems if you’ want to do port forwarding, as this must be configured on the original connection, otherwise it won’t work.

SSH Keys

While ControlMaster/ControlPath is the coolest thing you can do with SSH, key-based authentication is probably my favorite. Basically, rather than force users to authenticate with passwords, you can use a secure cryptographic method to gain (and grant) access to a system. Deposit a public key on servers far and wide, while keeping a “private” key secure on your local machine. And it just works.

You can generate multiple keys, to make it more difficult for an intruder to gain access to multiple machines by breaching a specific key, or machine. You can specify specific keys and key files to be used when connected to specific hosts in the ssh config file (see above.) Keys can also be (optionally) encrypted locally with a pass-code, for additional security. Once I understood how secure the system is (or can be), I found my self thinking “I wish you could use this for more than just SSH.”

SSH Agent

Most people start using SSH keys because they’re easier and it means that you don’t have to enter a password every time that you want to connect to a host. But the truth is that in most cases you want to have unencrypted private keys that have meaningful access to systems because once someone has access to a copy of the private key the have full access to the system. That’s not good.

But the truth is that typing in passwords is a pain, so there’s a solution: the ssh-agent. Basically one authenticates to the ssh-agent locally, which decrypts the key and does some magic, so that then whenever the key is needed for the connecting to a host you don’t have to enter your password. ssh-agent manages the local encryption on your key for the current session.

SSH Reagent

I’m not sure where I found this amazing little function but it’s great. Typically, ssh-agents are attached to the current session, like the window manager, so that when the window manager dies, the ssh-agent loses the decrypted bits from your ssh key. That’s nice, but it also means that if you have some processes that exist outside of your window manager’s session (e.g. Screen sessions) they loose the ssh-agent and get trapped without access to an ssh-agent so you end up having to restart would-be-persistent processes, or you have to run a large number of ssh-agents which is not ideal.

Enter “ssh-reagent.” stick this in your shell configuration (e.g. ~/.bashrc or ~/.zshrc) and run ssh-reagent whenever you have an agent session running and a terminal that can’t see it.

ssh-reagent () {
  for agent in /tmp/ssh-*/agent.*; do
      export SSH_AUTH_SOCK=$agent
      if ssh-add -l 2>&1 > /dev/null; then
         echo Found working SSH Agent:
         ssh-add -l
         return
      fi
  done
  echo Cannot find ssh agent - maybe you should reconnect and forward it?
}

It’s magic.

SSHFS and SFTP

Typically we think of ssh as a way to run a command or get a prompt on a remote machine. But SSH can do a lot more than that, and the OpenSSH package that probably the most popular implementation of SSH these days has a lot of features that go beyond just “shell” access. Here are two cool ones:

SSHFS creates a mountable file system using FUSE of the files located on a remote system over SSH. It’s not always very fast, but it’s simple and works great for quick operations on local systems, where the speed issue is much less relevant.

SFTP, replaces FTP (which is plagued by security problems,) with a similar tool for transferring files between two systems that’s secure (because it works over SSH) and is just as easy to use. In fact most recent OpenSSH daemons provide SFTP access by default.

There’s more, like a full VPN solution in recent versions, secure remote file copy, port forwarding, and the list could go on.

SSH Tunnels

SSH includes the ability to connect a port on your local system to a port on a remote system, so that to applications on your local system the local port looks like a normal local port, but when accessed the service running on the remote machine responds. All traffic is really sent over ssh.

I set up an SSH tunnel for my local system to the outgoing mail server on my server. I tell my mail client to send mail to localhost server (without mail server authentication!), and it magically goes to my personal mail relay encrypted over ssh. The applications of this are nearly endless.

Keep Alive Packets

The problem: unless you’re doing something with SSH it doesn’t send any packets, and as a result the connections can be pretty resilient to network disturbances. That’s not a problem, but it does mean that unless you’re actively using an SSH session, it can go silent causing your local area network’s NAT to eat a connection that it thinks has died, but hasn’t. The solution is to set the “ServerAliveInterval [seconds]” configuration in the SSH configuration so that your ssh client sends a “dummy packet” on a regular interval so that the router thinks that the connection is active even if it’s particularly quiet. It’s good stuff.

/dev/null .known_hosts

A lot of what I do in my day job involves deploying new systems, testing something out and then destroying that installation and starting over in the same virtual machine. So my “test rigs” have a few IP addresses, I can’t readily deploy keys on these hosts, and every time I redeploy SSH’s host-key checking tells me that a different system is responding for the host, which in most cases is the symptom of some sort of security error, and in most cases knowing this is a good thing, but in some cases it can be very annoying.

These configuration values tell your SSH session to save keys to `/dev/null (i.e. drop them on the floor) and to not ask you to verify an unknown host:

UserKnownHostsFile /dev/null
StrictHostKeyChecking no

This probably saves me a little annoyance and minute or two every day or more, but it’s totally worth it. Don’t set these values for hosts that you actually care about.

I’m sure there are other awesome things you can do with ssh, and I’d live to hear more. Onward and Upward!

How’s that for a Malcolm Gladwell-style subtitle title?

Alex Payne posed a piece on why he thought that, basically Hacker News had jumped the shark. He’s right, of course, but I think that his analysis of the root cause of the problem, and therefore the solution he proposes, is a bit too optimistic.

It seems to me that all of these socially edited link-based blogs where lots of people submit links and then the community votes on these stories to generate headlines and a filtered and sorted selection of content based on the appetites of the communities.

Hacker News tried, and succeeded for a time because the contributors (people who voted on, submitted, and commented on items) was small and focused enough that the content managed to coherent overall. There wasn’t enough content to necessarily overwhelm, both the readers and the potential contributors, and most things were interesting to most people. It was a golden age.

I think the problem with this model of generating content is that the golden ages don’t last very long. Sites “jump the shark” as the tightly focused content of the early, gives way to a more loose, less specialized, and more self-interested content submissions and selections. The factors that I think lead to this are:

• There’s too much content. Such sites should be “filters,” and their fundamental service is to take the whole internet and tell readers “you should be reading this because we think it’s interesting/important.” As communities of editors grow, as the marketing power of filter sites increases, and if the “cost” of submitting a link remains constant, then the use of the filter breaks down and everyone gets overwhelmed.
• There’s not enough focus/responsibility on the part of the editors. When you have a few dedicated and professional editors, you begin to see consistency and perspective and approach in the content that is curated. When this function is distributed among a large group of community members: amazing things can happen but that’s not a guarantee.
• Community edited sites tend to become incredibly self interested after a certain point. There’s a certain kind of story either about the community itself or that strikes submitters as being “about the kind of people that participate in the community, or “the kind of thing that people who read the site might like,” rather than things that interest them. Perhaps some of this comes from the game-based dynamic of rating systems and karma, perhaps it’s just a thing that happens.

In many ways, Trivium is probably the best example of a link filter blog. Alex Payne points to MetaFilter as an example of a site which has solved this problem, and although I have had a MeFi account for years, I’ve never been able to really get into it. Long story short, we still need editors and editorial vision, and the issues we’re seeing isn’t about the “focus” of a community, as much as it is a property of communities themselves.

Stan reminded me recently that I have now written two posts about the Java programing and software development. For something that I admittedly don’t particularly care for, and don’t know a great deal about I’ve sure ranted a lot about it. I think I keep returning to think about Java because of how incredibly important Java is to the technology we use and how prevalent Java development remains.

Maybe I’ve read too much by Red Monk folks, but they tend take a very productive approach to these kinds of things. For reference, my posts on the subject are:

• Caring about Java and
• Where is Java Today

Most “end-users” don’t really care much about things like Java except when it doesn’t work, as is the case when some component of the Java platform isn’t present when you want to run a Java program or when you run a “cross platform” java application that doesn’t really work as indented on your platform. For a long time these two issues were prevalent enough that being written in Java was a decernable quality of an application. In most situations, computer programs are just computer programs.

With one exception.

The way software developers use computers and interface with technology leads and constrains the technological reality for the rest of us. For instance, in Google Reader you can scroll up and down using the “j” and “k” keys, which is derived from interaction paradigm of the Vi text editors. It’s great, but was almost certainly put into the software because a developer on the project was a Vi user. While a most features are driven by formal design processes, so much of the way software works is lead by the way developers think about software.

Ultimately Java developers are what make Java is important, not just for me but for everyone.

(Note: I was going through some old files earlier this week and found a couple of old posts that never made it into the live site. This is one of them. I’ve done a little bit of polishing around the edges, but this is as much a post for historical interest as is a reflection of the contemporary state of my thought.)

This post is a follow up to my not much organization post, and as part of my general reorganization, I’ve been toying with anything for emacs which is a tool, or set of tools, which provide search-based interaction with some tasks (opening files, finding files, accessing other information, etc.) in a real-time search-based paradigm. Mmmm buzzwords. Think of it as being like quicksilver or launchy, except for emacs. I’ve come to a conclusion, that I think is generalizable, but made particularly obvious by this particular problem space.

Search, as an interface to a corpus, is only more effective than other organizational methods when you don’t know what the location of what your looking for is, or don’t understand the organizational system that governs the collection where your object is located. When you do know where the needed object is, search may be more cumbersome.

This feels obvious, when put in this way, but is counter to contemporary practice. Take the Google search use case where you find websites that you already know exist. You’d be surprised at how many people find this site by searching for “tychoish” or “tycho garen blog.” These are people who already know that the site exists and are probably people who have visited the site already. Google is forgiving in a way that typing an address into a search bar is not.

This works out alright in the end for websites: there’s no organizing standard for mapping domain names to websites. This is mostly due to the fact that you don’t, in the present practice, use the domain name system in the way that it was originally intended, in that the content of domain names are “brands” rather than a domain of systems and services described by the content of the domain. In the end this is not a huge problem since Google is around to help sort things out.

Similarly “desktop search” tools are helpful when you have a bunch of files scattered throughout file systems, with lots of hierarchy (directories and sub-directories). When you know where files are located, search less helpful. This is not to say that they’re ineffective: you’ll find what you’re looking for, it’ll just take longer.

I think this theory on the diminishing utility of search tool holds up, though I don’t exactly know how to do the research to further the develop the idea in a more concrete direction. Having said that, I think the following questions are important.

• Are there practical ways to organize our files, that don’t require too much over-thinking before a collection grows unmanageable that make “resorting to search” less necessary?
• Is (or might) building search tools for people who work with a given body of data (and therefore are familiar with the data, and are less likely to need search) different from building search for people who aren’t familiar with a given corpus?

Onward and Upward!

I’ve been playing with this idea for a Critical Futures blog post for a few days, so you’ll probably see this again at some point. Still, I wanted to pose a couple of questions that have been nagging at me for a while:

• Does the fact that we think of content as something that is becoming increasingly user generated, or generated outside of traditional professional structures, affect writers’ ability to survive from an economic perspective?
• Does this “crowd sourcing” (if you’ll indulge me,) mean that everyone will think of themselves as writers henceforth? While that’s potentially inspiring from the perspective of democracy, it feels hard to maintain from a literary/textual culture perspective. If everyone is a writer, is there an audience of readers for any kind of writing (fiction, critical, or non-fiction) separate from writers? If not, is there enough audience amongst fellow writers to support the project writing? (Answer: doubtful.)
• I’m totally willing to accept that the publishing industry as we’ve come to know it is (and will continue) to undergo great change. At the same time, “great change,” means (I think) that some practices will need to change in a fundamental sort of way. It is not enough to manipulate the length publishing schedules of periodicals in order to get them to appear profitable for a while, it’s not enough to publish lots of small runs of books tight budgets that break even really fast.

These strategies delay the inevitable, but don’t address several fundamental problems:

• The group of readers (e.g. audience) is significantly smaller than the public at large. If we want to grow audiences for our books, blogs, wikis, and other (hyper?)textual products we need to enlarge the group of people who read.
• Most people who fail read any given text on any given day, fail to do so because they didn’t know it existed, and probably because they felt like they didn’t have time to do so.

Largely I think these issues can be extrapolated to other forms of media, I’m just a writer and think of things in terms of essays, articles, stories, and novels.

In any case, I think the way to save the “media industry” and media creators in particular, is to figure out how to get more people to read and figure out how to improve the discovery process. Hefty challenges, for sure.

Onward and Upward!

I often find it difficult to feign interest the discussion of Java in the post Sun Microsystems era. Don’t get me wrong, I get that there’s a lot of Java out there, I get that there are a number of technological strengths and advantages that Java has in contrast some other programming platforms. Consider my post about worfism and computer programing for some background on my interest in programing languages and their use.

I apologize if this post is more in the vein of “a number of raw thoughts,” rather than an actual organized essay.

In Favor of Java

Java has a lot of things going for it: it’s very fast, it runs code in a VM that lets the code execute in a mostly isolated environment which increases reliability and security of the applications that run on the Java Platform. I think of these as “hard features” or technological realities that are presently implemented and available for users.

There are also a number of “soft features,” that Java has that inspire people to use it: an extensive and reliable standard library, a large expanse of additional library support for most things, a huge developer community, and it has inclusion in computer science curricula so people are familiar with it. While each of these aspects are relatively minor, and could theoretically apply to a number of different languages and development platforms, they represent a major rationale for it’s continued use.

One of the core selling points of Java has long been the fact that because Java runs on a virtual machine that can abstract differences between different operating systems and architectures, it’s possible to write and compile code once and then run that “binary” on a number of different machines. The buzzword/slogan for this is “write once, run anywhere.” This doesn’t fit easily into the hard/soft feature dichotomy I set up above, but it nevertheless and important factor.

Against Java

Teasing out the history of programing language development is probably a better project for another post (or career?), but while Java might have once had a greater set of support for many common programming tasks, I’m not sure that it’s sizable standard library and common tooling continues to overwhelm it’s peers. At best this is a draw with languages like Perl and Python, but more likely the fact that the JDK is so huge and varied increases incompatibility potentials. And needing to download the whole JDK to run even minimalist Java programs. Other languages have addressed the tooling and library support in different way, and I think the real answer to this problem is write with an eye towards minimalism and make sure that there are really good build systems.

Most of the arguments in favor of Java revolve around the strengths of the Java Virtual Machine, which is the substrate where Java programs run. And it is undeniable that the JVM is an incredibly valuable platform, and every report that I’ve seen concludes that the JVM is really fast, and the VM model does provide a number of persuasive features (e.g. sandboxing, increased portability, performance gains.) That’s cool, but I’m not sure that any of these “hard” features matter these days:

Most programing languages use a VM architecture these days. Raw speed, of the sort that Java has, is less useful than powerful concurrent programing abilities and is offset by the fact that computers themselves are absurdly fast. It’s not to say that Java fails because others have been able to replicate the strengths of the Java platform, but it does fail to inspire excitement.

The worth of Java’s “cross platform” capabilities are probably negated by service-based computing (the “cloud,”) and the fact that cross platform applications, GUI or otherwise, are probably an ill gotten dream anyway.

The more I construct these arguments, I keep circling around the idea that while Java pushed a lot of programmers and language designers to think about what kind of features that programing languages needed. The world of computing and programming has changed in a number of significant ways, and we’ve learned a lot about the art of designing programming languages in the mean time. I wonder if my lack of enthusiasm (and yours as well, if I may be so bold) has more to do with a set of assumptions about the way programing languages should be that haven’t aged particularly well. Which isn’t to say that Java isn’t useful, or that it is no longer important, merely that it’s become uninteresting.

Thoughts?