I linked to it in another comment, but is a perfect example. Then I tried this and it didn't work." followed by someone else responding "Have you tried this?" and then yet another person saying "No, that doesn't work either." It's absolutely awful, and I hate myself every time I land on the Lua-users site. It makes me sad that Lua's refusal to standardize good ways to do things led to the language's primary resource being a community message board filled with back-and-forth postcard essays saying "I tried this and it didn't work. > as usual, Lua-users provides some incite into. Which almost worked too… but that’s another story. † After which I realized it’d be far easier just to port the useful bits of AppleScript to Python instead. A platform is only as robust and dependable as its weakest component, and for as long as a buggy or withdrawn left-pad function can tip the whole stack over then it’s not robust at all.īut this is as much a sociological challenge as a technical one, and not one I’ve got answers to yet. Zero success†.Īnd now I’m trying to devise a “stealth Lisp” successor to them all ( ), I realise cracking the greater library problem is what will make the next generation of languages. Many years ago I cut my teeth on AppleScript, which makes the stdlib-starved Lua look like fat Python 2, and tried to bootstrap a library ecosystem for it more than once. This is not merely idle speculation on my part. Preferably without destroying that enthusiasm in the process, since there’s no point having a wonderfully polished platform without bums on seats as well-a perennial Lisp failing, it should be noted.
#HAMMERSPOON RAPID FIRE HOW TO#
Of course, this still leaves the other (larger) problem of how to sort out current trash houses like PyPI, NPM, LuaRocks, et al, where contributors’ enthusiasm is not necessarily matched by their knowledge, competence, and ability to savagely critique their own work before inflicting it on the world (you know, the “Science” bit in “Computer Science”).
In essence, automated refactoring by “recipes”, where these recipes are as common and easy-to-use as the libraries themselves. Thus, rather than bake in all the libraries, keep the libraries external and build in a standard mechanism for migrating codebases written for one onto another. Having seen the decade-long logistical horror of Python’s relatively minor 2-to-3 upgrade, Xcode’s ability to auto-update projects written for one Swift version to another has let them evolve the language with minimal pain.Īnd while I’m not a fan of Lisp itself (a decent first attempt that should’ve been vastly bettered by now), I think its metaprogramming model an obvious foundation for such an automated migration system. I have many gripes about Apple’s #SwiftLang, but seriously appreciate that this is one requirement they’ve given some thought to.
#HAMMERSPOON RAPID FIRE CODE#
Which suggests there’s a more general meta-problem waiting to be solved here: how to mass-migrate code written against interface A when a superior successor B comes along. (I think there’s four or five different built-in ways to do those now.) Python’s “batteries included” may have helped it to win vital audience early on, but it’s also locked in a ton of deadweight that’s seriously slowed down its own evolution since, while bloating its feature complexity to such a level I could not recommend Python as a good language for beginners now.
“it's really helpful to have one obvious way”Ĭounterpoint: Python format strings.