:: Constraints thrice ::
This is a bit old, but there was a confluence of constraint talk, some moons ago. Like Todd, I want to see it in everyday tools.
- Laszlo/LXZ is an interesting XML for building interfaces and clients tools, compiling out to Flash. (LL2 webcast -- skip to 3:06:45)
- Todd Proebsting discusses practical features he'd like to see in languages, in a talk he's been traveling, and again gave at LL2. (LL2 webcast)
- Guy Steele's thesis, The Definition and Implementation of a Computer Programming Language Based on Constraints. You will weep at the clarity of the man and his large language, and his little language. (via Lambda)
:: XPlanner ::
XPlanner is a servlet-based tracking tool for extreme programming projects. And I'm glad it's around. Open source has been missing XP process management systems, especially ones that assist remote collaboration.
As it gets tough beyond four people to intuitively calibrate the point system (for each two week cycle) betwixt the propeller heads and pencil necks, XPlanner incorporates scheduling feedback loops (well explained in Joel Spolsky's Painless Software Schedules.) Managers can't schedule effectively unless each of their people can schedule themselves. Programmers are irrepressively optimistic; aggressive feedback is the only way to ween them of this. (I say this as a person who's missed more deadlines than I will admit.)
XPlanner needs some maturing and portability beyond Tomcat (cringe). Go give some feedback.
:: Java on the Desktop ::
Microsoft provided tools that developers have ended up being forced to use to build desktop software, he said.
"And, for lots of desktop developers [Windows] was the only market that actually mattered," Gosling said. "That is, I think, deeply tragic."
The above conceit is an appropriate one, as long as it remains consigned to Sun's public marketing. James, being a smart fellow, understands the distinction between a Java desktop application and a usable desktop application. But there's no admitting that on stage.
It amuses me to read articles citing Microsoft's destruction of Java. No doubt they have it in for Sun (and often support dubious technologies), but the early MS JVM was the singular reason I could deliver professional Java applications (1997-98) given Sun's original, adolescent runtime and libraries.
Since the appearance of .Net, I've been mourning the loss of Java. It's brilliant for server use, I quite like the language -- and the present broad, industrial-strength API set is an unprecedented joy in the history of code. But if it can't move beyond servers, it will fade to competition. And Sun has been responsible for its failure on both browser and desktop, via petty and (ultimately) self-destructive behavior. Further, Sun has assured the bifurcation of a unifying technology, and rejected technical advances, important enough to real projects, to excite (Mono, dotGNU) the open source crowd.
There is one possibility. IBM wrests away control of Java, open sources their JVM (let the porting begin!) and makes a real push for the efficiencies and rounded APIs required of desktop use. In the same way latest Mozilla might have a fighting chance by virtue of solid implementation of standards, huge platform diversity and malleable component use for other development.
It'll never happen.
:: Further reading on this article ::
:: Mozilla steers clear of interactivity ::
Can it be true that Mozilla inherits Netscape's disability regarding dynamic content?
Now, the word dynamic is a red herring. For the NetMoz camp, it's a marketing term. What they mean is programmatic-properties-on-load. They sometimes mean a few mouse-responsive styles. They sometimes mean updating the contents of form elements and image swap. Big deal -- they really mean, "We have no interest in building interactive pages, without the help of Java or Flash."
What a change with MSIE 4. It began to support real, dynamic evaluation of arbitrary sections of code, styles and script. This is a killer stuff. It means Webmasters can posit apps normally relegated to the desktop (and "programmers"), using uniform HTML, Javascript and a basic server-side scripting component. (Anders has some examples: 1 2) It's the difference between endless page loads and real-time interaction. That is, native app-like abilities by web page.
The other half of this equation is RPC. Here at least, we have cross-platform support (e.g. Brent Ashley's JSRS library -- although MSIE-specific code is achingly simple.) Further, both camps are starting to support browser-side SOAP and other protos.
But what's the point, if you can't update content? At the beginning of the Web, we gave up interactivity and direct manipulation for simplicity and portability. But it's ten years later. Can't we have both feature sets?
Update: Read the comments to see why I'm (happily) wrong.
:: Another EJB Datapoint ::
My perspective on Mike Cannon-Brookes' blog thread Is EJB Always Necessary?.
In mid-1999, Imagine Media was set to introduce a broad basket of internet content vehicles, launched from a traditional magazine company (think original Business 2.0, Daily Radar, Maximum PC). They needed something to manage content. Given the choices consisted of Vignette and Vignette (execs were in heavy buy mode), I pitched a lean setup based on commodity hardware, open source and up-and-coming J2EE.
Performance windows and simplicity
Our goal was to deliver dynamic, Amazon-complexity pages every 50ms, with an asymptote somewhere at 500ms. Freshness was important. Within seconds of editors posting, users interacting or partners pushing, pages should be glistening with dew.
We'd need heavy, multi-layered caching and brutally simple components; the latter to withstand the content swings of our gaming sites -- build and slot boxes in quick response. (We never really got to Amazon-complexity, but the mission set our sights high.)
Not a fit
In the month of our research phase, we met much disappointment. What looked like a good wrapper for (essentially) static content, Entity Beans in this 1.0 spec were barely adequate. We'd have to compromise on locking semantics. There were lots of bugs. Worse, Weblogic, a trusted name we could sell upstairs, displayed terrible EJB performance, and this only if we utilized proprietary extensions. (J2EE got sold, in large part, on portability.) Further, we were getting concerned the caching implementation was fairly dumb. And the O-R mapping: schema evolution was going to be an obstacle, yet flexibility was a market necessity for us.
The solution
We reset our design.
- Simplify: presentation JSPs invoked from servlets, referencing a read-only object cache, per JVM.
- Objects are high-level, mirroring page components.
- We build our own veneer to manipulate these objects and pull them out of the database.
- Lightweight, one-way messages (from staging to production networks) will force invalidation & rebuild.
- Each object exports a parent/child association set, allowing invalidation to cascade in the graph.
- Caches, on miss, can peek into peers.
Dev was six weeks to working code. JVMs of that time fell off a performance cliff over 256meg of cache, but it was Good Enough.
That overall design simplicity saved our backsides routinely.
As an aside, having attenuated our requirements to pure servlet engines, a product like Resin offered us a sharp fellow bent on performance, light-speed support, product code we could patch ourselves and trivial replication across the server farm. Oh, and it was cheap.
Practicum
A year later (2000), my friend made an interesting point. Working for a big five firm, designing Java web applications, he relayed that if you're working for a client who doesn't dally over technology, can purchase big iron to support any infrastructure, and the job market affords you programmers [term used loosely] with 2 years experience, EJBs are a win. At the edges, it's programming by boilerplate.
Nonetheless, for our purposes, we found EJBs an unconvincing model. Trying to do too much, all of it poorly. Latest versions are far more robust, implementations are excellent, but they still seem to tackle a universe of problem domains better handled by specific solutions (ODB, messaging, caching, abstract transactions managers, etc.)
:: Further reading on this article ::
:: Programming Python ::
I finally accepted Python into my brain.
Nothing is going to match the three-line Perl haiku that do scads of work in a Unix environment; however, coming from a CS background where I fell in love with Eiffel (1989) and waited for the world to catch up (never did), Python's clean syntax, programming-in-the-large-friendly features and real object support appeal greatly.
Reasons I held out/finally caved:
- Nobody's going to tell me how to indent! (bad Occam experience)
- The language has matured, my minor nits are gone and it's a joy to behold. (I have trouble finding the edges of dense Python without scoping operators/keywords, but the pattern-matching has to kick-in sometime.)
- There is lineage before us and a clear path to community-based expansion.
- ... and the most important aspect to making such a big switch, the library (both batteries included and third-third-party) is getting to be high, wide and self-perpetuating.
Despite Paul Graham's interesting notion of the language power curve, I'd rather be locked down with a syntactic and grammatical straight-jacket, so I make fewer dumb mistakes and concentrate on logic. I was often hanging in the wind with Perl, giving up on any script larger than a thousand lines. Python makes many seasoned, clever choices along these lines. Further, I had to make the tough decision to program web pages in Java (vs a scripting language) as it alone provided a world of sane exception handling in fast-moving, many-new-hands-in-the-templates web applications. We have a choice, now.
Which brings me to the point of this blurb. I highly recommend Mark Pilgrim's diveintopython. It reminds me of my experience with Perl. In the early 90s, I thought I'd try out this cool consolidation of awk, sed and portable UNIX API, Perl, needing to build a client's web site. I picked up Programming Perl (1st edition), and soon realized it was an exemplar of tutorial for experienced programmers. Fast-paced description married to mind-meld examples. diveintopython has the same feel. Using different tactics and forward a decade of methodology, Mark strikes a perfect density with nimble conceptual positioning, direct links to language/library references and advanced topic examples to keep the hardcore monster fueled.
A lazy weekend of reading, a few nights practice converting a few dozen Perl scripts, and I was up and running. I failed trying to find the perfect Py web application environment, but I'll get to that later.
