Inkling beat me to it, but after my recent revelations about Python, I’ve also decided to move all new development to Arc. Even better, it looks like someone has done an Arc implementation for .NET/Mono called SteelArc, which will suit our embedded apps nicely. I think the name is a take-off on IronPython.
Paul Bissex just posted a simple three-step procedure for how one might become acquainted with the changes coming in Python 3 (née Python 3000). The mere mention of Python 3 prompted me to start writing a comment for Paul’s post, but it went on long enough that I figured it wiser to post here.
In understanding Python 3, I think it’s equally important (especially for those of us who might not walk on the beaten path with regard to domains, types of apps, etc) to review PEP 3099, which outlines what won’t be included in Python 3.
Personally, reading PEPs 3099 and 3100 (which Paul references in his post) is depressing. I’ll explain why by example and contrast. Consider this post from GvR from about a year ago. Quote:
But please save your breath. Programmable syntax is not in Python’s future — or at least it’s not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other’s code any more.
This is predictable, especially given GvR’s prior comments on various topics surrounding more “esoteric” features like multiline anonymous functions, operator overloading, etc., etc., etc. However, compare and contrast that to this slideshow from Ruby’s Matz from about two years ago. I don’t have a money quote, but the difference in attitude and approach is staggering. There’s a line in Annie Hall (I think, or some other Woody Allen movie) where Woody’s character says that relationships are like sharks: they must continue to move forward in order to survive.
Now, I’m not saying that Python is dying somehow — far from it. However, I think it’s safe to say that it has stopped growing (and hasn’t grown significantly since v2.2 with the great class/type unification). Meanwhile, Ruby is “a white-hot nexus of innovation”, according to Tim Bray, anyway; and really, anyone who knows and cares about what Python is lacking in terms of expressiveness and capability would agree.
At this point, you might fairly assume that I’m some kind of Ruby booster, but in fact, about 90% of the coding I do these days is in Python, and that has been the case for almost 3 years. And as much as I enjoy working in Python, it has not (and looks like it will not) grow along with the problems that I need to solve.
I’d like to introduce jsdifflib, an in-browser visual diff tool and library:
In the process of building a new web-based document-centric service, it became clear that I needed a good in-browser visual diff tool. I’ve become friends with a number of desktop “thick client” diff tools over the years, but the interface to this new service is 100% through the browser, and all those old friends aren’t amenable to diffing web-based resources.
Some web searches didn’t turn up anything particularly promising. I was looking for an in-browser diff tool, preferably in Javascript (but I suppose Flash would have done the trick, too). I found a few not-so-great Java applets that would do the bare minimum, but nothing ideal. There were a few javascript diff algorithm implementations (like this), but nothing that could be considered a complete solution.
So, I built jsdifflib over a weekend in February of 2007.
I hope you find jsdifflib useful. On its page, you’ll find some more background information, implementation details, examples, a live demo, and free downloads (with a BSD license).
This morning, we put some limited-time-only discounts into place for PDFTextStream to celebrate the new year. You can now purchase PDFTextStream server deployment licenses for as little as $999 USD (optionally with Premium Support). These licenses carry no CPU restriction, so you can use them on your 1CPU development box or your 64-CPU Superdome. And, as always, you can use the same license under Java, Python, or .NET. This sale starts today, and ends on January 31, 2007. You can place your order here (with payments handled by Google Checkout).
This is quite a deal — these unlimited-CPU server licenses usually cost $13,750 USD. That’s quite an insane discount, but I thought it was worth the chance. Theoretically, this will create a little buzz, increase our customer list by quite a bit, and maybe expose a different class of users to PDFTextStream that might have previously written it off because of its admittedly high (normal) price tag.
This is also a decent pricing experiment. We’ve never done much experimentation in the area of pricing, so we’ll now have one more data point on our demand curve (as described brilliantly by Joel). I don’t think that this particular experiment will have any lasting effect on our pricing for PDFTextStream, but it will be an interesting exercise nonetheless.