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...

Why PHP sucks

(July 8 2005) Apparently I got linked by some PHP sites, and while there were a few well-reasoned comments here I mostly just got people who only knew PHP reacting like I told them their firstborn was ugly. These people tended to give variants on one or more themes: All environments have warts, so PHP is no worse than anything else in this respect I can work around PHP's problems, ergo they are not really problems You aren't experienced enough in PHP to judge it yet As to the first, it is true that PHP is not alone in having warts. However, the lack of qualitative difference does not mean that the quantitative difference is insignificant. Similarly, problems can be worked around, but languages/environments designed by people with more foresight and, to put it bluntly, clue, simply don't make the kind of really boneheaded architecture mistakes that you can't help but run into on a daily baisis in PHP. Finally, as I noted in my original introduction, with PHP, ...

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...