I'm very good at hand-crafting Mac apps among a very few other things. Check out my website, https://sephware.com/ or say hi at contact@sephware.com :)
I'm surprised Lua isn't in this list. It is excessively tiny both in its implementation and its runtime, and I have used it in multiple projects often just by throwing its whole source code right in. It's also very minimalist in spirit, allowing you to turn off every single built-in function, so that you can use it as a sort of turing-complete alternative to JSON as a configuration language. Very cool little language.
Generated documentation can be really really useful, but in my experience and opinion it needs to be a custom documentation generator. That's the approach I used with Autumn, where the generated HTML on the website is the same as in the app, so you can get a feel for it without trying the app out. The docs are concise, clear, good looking, organized in an easily navigable and understandable hierarchy, and with clickable references. I think what I came up with beats out commented code by far, although I did start to wonder if I should render the English portion of each node in my doc tree to be styled as a code-comment, just to draw more attention to the actual code signature itself.
> We both love our work so quitting isn't exactly helpful.
This sticks out to me, as it seems to be a false dilemma. Maybe you can work it out without either quitting, but having one of you quit is a real solution that you shouldn't throw out the window. After all, I'm sure you both love each other more than your work. Big life changes can be hard. (We got rid of our home internet, despite the fact that my whole employment relies on the internet.) But they're doable and shouldn't be dismissed so quickly.
Sometimes all that's needed is a little pressure and motivation mixed with morale from strong leadership to encourage people to spent a day or so upgrading and testing. Maybe not in this case though. That might not have been enough here, who knows.
Scratch is pretty great, and at least 3 of my kids constantly ask if they can play Scratch. Unfortunately, for 2 of them it usually means just putting characters on a stage and adding code to change their costumes when you click the green button.
But if you have kids who want to step up their game from Scratch, check out PICO-8 (submitted it earlier today, check my history). It's genuinely amazing, and my oldest absolutely loves using it. He's made some awesome 2d games so far over winter break and he's using legitimate programming concepts and techniques like they're nothing, it's really amazing to watch.
We bought this and have been having non-stop fun with it for months. It's an incredible piece of software that I only wish I knew about sooner. It gives a retro 70s-80s feel to making video games that gives kids today a hint of what it was like to learn how to program back then, without being overwhelmingly difficult or giving up modern conveniences (built-in spite and code editors, lexical scoping, first-class functions and hash-maps, etc).
Ruby was one of many languages to spike in popularity due to being a novel way to approach programming, and everyone I know has moved on from it. But I find it very valuable for one-off scripts that are too complex to write in Bash. I actually used Ruby to compile my app's documentation from sources into a JSON file, and it was easy to update the Ruby code every time I added more features or needed to change how the documentation was generated. It let me write it in a mostly functional way without being too confusing, and it was already installed on my system. But for web apps, no way am I choosing Ruby. I've moved on to Node.js from Ruby years ago, and haven't looked back. Modern JavaScript is much more "clean" than Ruby to me.
That does sound very useful, yeah. I'll look into whether it can be done, but my gut feeling is that it can't. Typically apps can only respond to their own generated Apple notifications, not those generated from other apps.
I think one reason to limit to base 10 is because we don't have an arbitrary number of digits, we only have maybe 36 if we use the full alphabet. And it will be difficult for people to follow along with if it's something they aren't used to calculating in. But I'm also guessing the results will become a lot less "rare" which is part of the cool factor here.
This is an interesting concept but for some reason I expected it to be a curated list and not a list of unvetted user submissions. Still interesting though, just different than my expectations.
This sounds incredibly useful and is something I am going to strongly look into and consider as a future (separate) project. Thanks for sharing these thoughts!
Forum for discussion is actually one of my highest priorities for this month! I'm not settled on whether to use something like Discourse, phpBB, a subreddit, a mailing list, a custom forum, or a GitHub repo with Issues enabled. This requires more thought, and maybe more discussion, but it was on the todo list since day one of writing Autumn.
I will look into reacting to Mac notifications, that sounds like it could be useful but I'm not sure I understand what it means. Could you elaborate?
Yes, Hammerspoon goes in many different directions with its API, providing not only the kitchen sink but the house and the neighbors' houses, but lacking the paintings and many walls. That inspired a lot of decisions in how I designed Autumn's API, because I wanted the user experience to be buttery smooth from start to finish, and I wanted the API to be both useful and comprehensive without being overwhelming or spartan.
That's why it's paid: I've tediously worked out all the kinks over months and months of work. Obviously no software can be guaranteed to be bug-free, but I'm the #1 user of Autumn and I have gotten rid of every single bug I could find and polished every single corner-case and sped up every operation. I generally avoid making bold claims, but I'm confident this is the smoothest, fastest, and most fun window manager for macOS as of 2019.
> Uncommonly downloaded is applied to any download that is new or has been modified/updated until Google has a chance to examine the download using multiple data centers. Once the download has been examined enough times, the warning will be removed.
So apparently we just have to wait until Google's servers decide my app isn't dangerous. Ironic considering I paid the $100 for Apple to notarize the app through Developer ID to remove that same warning from macOS when you first launch the app!
Regarding ESM (ECMAScript modules), I did implement require() and module.exports to the best of my ability, so it should be pretty easy to modularize your scripts. But it doesn't have a Node.js runtime so I didn't focus too much on node_modules support, although in theory many packages should work fine.
Regarding online documentation, good idea, thanks! I'll try to add that this week. Although, the app is so much more than its API, which is what makes it so unique, and I think if people just look at the API itself, they don't quite get to feel the experience of using Autumn to create their own automation workflows, which is what I'm most proud of about Autumn.
Patreon's model relies on monthly fees, which is something that philosophically I am against with software like Autumn, because it's not a continual service but a product that took a finite time to complete, so it should have a finite price. I also took counsel of someone who makes over $10k / month in monthly donations for open source work, who strongly recommends against it for personal products but encourages it for products that can benefit organizations.
That is a great list! Autumn's API was inspired by a lot of these, so you may find some similarities, although I redesigned Autumn's API from the ground-up to be intuitive, simple and predictable, and so that it would lend a lot more easily to the built-in documentation viewer. Searching through online documentation was always one of my most sore points when using other programmable window managers, so that was one of my biggest focuses in Autumn, and one of the aspects of it I'm most happy with how it turned out. That, the developer console, and the integrated IDE (Monaco editor), are some ways that I felt I could take the next step up from earlier window managers.
Slate is great, it was one of the first window managers I ever tried. In fact Slate inspired a good portion of the early versions of Autumn. You can almost think of Autumn as Slate with an embedded IDE, built-in documentation, developer console, and an API designed with TypeScript in mind.
Whoa I got that too! I usually use Safari or Firefox (Google creeps me out) but I have tested the whole site in all three browsers, except this one button in Chrome I guess :D I'll check it out, thank you!
Also, sorry for the terrible website. Web design is not my forte, I'm an app guy, and this was the quickest thing I could hack together in a couple days. Also I'm aware of the issues with the video demo, I'm uploading the file to YouTube so it should be fixed soon!
I've been writing Autumn on and off for a few months, because there's something really satisfying and rewarding about automating something you do often, and then using that to automate more, and building upward in a cycle.
That, plus I wanted to see how close to building a "legit IDE" I could get while completely faking it with WKWebViews. So Autumn kind of grew from those two principles and I'm really happy with how it turned out.
I'd be glad to answer any questions, I'll be here for a few more hours. (I don't have internet at home so I use the library's wifi for stuff like this, and it closes early today.)
I actually like how it compiles down. In a native macOS app I just released this morning, I wrote originally in Preact, converting JSX to function calls to avoid a build phase, and eventually replaced the Preact function with a custom function that creates DOM elements directly. Not only was it a fun learning experience, but it took a relatively tiny amount of time to do, precisely because translating JSX to equivalent DOM node creation code is so predictable and transparent.
This is why I always liked Cocoa (macOS native UI toolkit) and still prefer it over web UI when writing native apps. It separates out the concepts of layout, appearance, and behavior, and lets you customize any one of them without needing to readjust the others. I just released an app this morning here that uses a non-trivial amount of Cocoa, and it would be full Cocoa if there was a Cocoa-version of the excellent Monaco editor. I feel like there should be a web version of this sort of "old-fashioned" toolkit that has a timeless ease of use once you get over the learning curve.