Skip to main content

APIs matter

Victor Moholy:

A bad API, like a bad novel, feels like a trick: key information is withheld and simple relationships are hard to deduce.

I had one of those "a-ha" moments reading this. ("A-ha," I thought. "I feel a rant coming on.") This is exactly why, after building probably one of the largest web applications done with OpenACS 3.2, I never managed to like the 4.x (and now 5.x) series of that toolkit.

OpenACS 4.x and later suffer from Second-system syndrome. The effect is rather Zope-like: instead of a learning curve, you have a vertical cliff to scale before you can accomplish anything interesting.

Add in bizarre and arbitrary api changes, it's no wonder nobody except the core team really got on board with the later OpenACS versions. (I suspect that the "everything must be a named parameter" had its genesis in the proliferation of functions taking over a dozen parameters. Deprecating all functions that don't require named parameters is both taking things too far, and fixing entirely the wrong problem!)

Which is a shame. OpenACS solves a much larger problem than most web toolkits attempt, giving you registration support, permissioning, etc. out-of-the-box. The 3.x series may have solved only 90% of the problem, but it did so in a much more approachable way than 4.x. (Or Zope, the only other framework that really tried to tackle this problem in that era. Don't even get me started on J2EE systems.)

Ah, well. RIP, OpenACS. It looks like Django is trying to solve some of these same problems (e.g., its permissioning support and "pluggable applications") while retaining a more lightweight approach. In this respect, Django is much more than a me-too "Rails for Python." Of the would-be Python Rails killers (and Rails itself), Django alone impresses me for attempting more than the same old, same old.

(Which reminds me -- I haven't seen this fellow's django-and-rails comparison linked anywhere, even though it's a month old. Guess I don't follow the right blogs. It's worth reading if you don't know much about one or the other, despite his lamentable lack of taste in prefering Ruby.)

Comments

JacobHarman said…
3dcart improvement stage is a facilitated answer for Web based business administrations to fabricate appealing and proficient shopping basket on in an internet based store. It is not difficult to create and coordinate with your internet based site with next to no need of mastery in web advancement. To utilize the high level elements of the 3dcart Web based business stage, you can employ 3dcart designer effectively in the commercial center at reasonable costs>> ecommerce developer company

Popular posts from this blog

The Missing Piece in AI Coding: Automated Context Discovery

I recently switched tasks from writing the ColBERT Live! library and related benchmarking tools to authoring BM25 search for Cassandra . I was able to implement the former almost entirely with "coding in English" via Aider . That is: I gave the LLM tasks, in English, and it generated diffs for me that Aider applied to my source files. This made me easily 5x more productive vs writing code by hand, even with AI autocomplete like Copilot. It felt amazing! (Take a minute to check out this short thread on a real-life session with Aider , if you've never tried it.) Coming back to Cassandra, by contrast, felt like swimming through molasses. Doing everything by hand is tedious when you know that an LLM could do it faster if you could just structure the problem correctly for it. It felt like writing assembly without a compiler -- a useful skill in narrow situations, but mostly not a good use of human intelligence today. The key difference in these two sce...

A week of Windows Subsystem for Linux

I first experimented with WSL2 as a daily development environment two years ago. Things were still pretty rough around the edges, especially with JetBrains' IDEs, and I ended up buying a dedicated Linux workstation so I wouldn't have to deal with the pain.  Unfortunately, the Linux box developed a heat management problem, and simultaneously I found myself needing a beefier GPU than it had for working on multi-vector encoding , so I decided to give WSL2 another try. Here's some of the highlights and lowlights. TLDR, it's working well enough that I'm probably going to continue using it as my primary development machine going forward. The Good NVIDIA CUDA drivers just work. I was blown away that I ran conda install cuda -c nvidia and it worked the first try. No farting around with Linux kernel header versions or arcane errors from nvidia-smi. It just worked, including with PyTorch. JetBrains products work a lot better now in remote development mod...

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas...