Congratulations to the Zed team! What a great project.
The newer layout that came along with the parallel agents feature is very nice; even without using parallel agents regularly, this is a breath of fresh air.
I think Decker is just wonderful, but it's retro. That isn't a criticism of it at all, that's what it wants to be and I don't think it should try to be something else.
But it isn't what I meant. A HyperCard reboot would be a modern GUI builder with a deck-of-cards drag-drop metaphor, deployable as desktop, browser, and mobile apps for any platform. Mobile poses some problems, particularly iOS, but I don't think those are unsurmountable.
Decker is a love letter to the HyperCard which was. But if HyperCard had survived as a product, today's version wouldn't look anything like that.
Decker runs natively on a variety of platforms as well as on web browsers, and it fully supports touch devices like tablets. It isn't designed with small cellphones in mind, but I'm told that it's quite usable on phones that include a stylus. Just as touch support has improved over time, I have some ideas for providing a degree of fluid layout in the future without onerous impositions on deck authoring.
Decker is not a carbon-copy of HyperCard frozen in the past; it's a continuously evolving platform with many interesting innovations and experimental ideas. It has a distinct aesthetic, but I see this as a strength rather than a weakness: "modern" just means "in fashion", and fashions are always in flux.
It's great work what you've done, and as I said, I have no criticism of it at all.
But it's more than a distinct aesthetic, it is a distinctly retro aesthetic. Modern means contemporary, more than it means fashionable (sometimes retro aesthetics are in fashion, after all).
But terminological nuance is not very important here. The fact remains that, as wonderful as it is, Decker is not what I meant, and I don't think you're trying to make it into that either. For one thing you'd need a rather large marketing budget.
But to be sure, I wish you all success, whatever that might mean to you. If that includes transforming Decker into something which looks and feels like HyperCard might today, if Jobs hadn't put it out to pasture when he did, then more power to you.
I made a serious effort to integrate Muse into my work starting around late 2021 or early 2022, and in fact bought an iPad Mini and Apple Pencil specifically to use Muse. The work that comes out of Ink & Switch is always interesting, and I was excited to try some of it out in the real world. Over a year or so, I used it to read and review PDFs (mostly journal articles for work), wrote and presented a lunch-and-learn from Muse, dropped PNG plots from Jupyter for scribbling or easy comparison; I even got one of my colleagues interested enough to use the collaboration features semi-regularly.
It hasn’t stuck though, and I’ve stopped using it; subscription will lapse later this year. I’m sad; like others here I really wanted to like this and for it to make sense to keep using.
I don’t a have clear set of reasons for why it didn’t stick. Just thinking out loud. Partially, I was fighting against my organization — my immediate team is science / Apple / Python, but the larger company is Teams / Windows / PowerPoint, and that’s always friction. Partially, it was a workflow thing — most often I wanted to review PDFs, which live in Zotero, and then it’s like, did I copy that one over yet? Where are my notes about that one? Muse’s PDF excerpting feature is really wonderful; the lack of being able to zoom a PDF, or support for table of contents, was a bummer. Large PDFs like textbooks could be problematic. Partially it was that Muse on iPad vs macOS felt like two incomplete halves — can’t type on iPad, can’t ink on macOS. Partially: things I did in Muse, felt stuck in Muse; not literally true, but copy or export out of Obsidian vs Muse feels very different. Partially: always that nagging concern from lack of E2EE sync, and after Apple launched E2EE for iCloud, Obsidian + iCloud offered the sync I wanted with a subscription I already had anyhow. (Collaboration features aren’t as good, though!)
Anyhow. Muse did so many things well and first in this space, it remains impressive. Many iPad apps (in my opinion) are incrementally different versions of Apple Notes; Muse is a standout example that supports Apple Pencil as well as Apple first-party apps but targets a very substantially different use than drawing. Although I’m setting it aside, still optimistic about what this year will bring for Muse, and wishing the best to Adam Wulf!
It's a niche market for sure. Apple released Freeform[0] on MacOS (free) which replicates a lot of Muse's functionality, but I haven't heard of anybody using it. Contrast that to Apple's Notes app, which is universally used if you're a Mac/iOS user.
> For instance, macOS is a Unix™. It passes the tests, and Apple pays for the certification. But it hides most of the real Unix directory tree, its /etc is relatively empty, it doesn't have an X server – it's an optional extra. And most of all, it's not case sensitive.
What does it mean for the operating system to be “case sensitive”? Certainly APFS is case sensitive, so this must refer to something else?
OS X / macOS has always defaulted to using filesystems that are case-preserving but not case-sensitive. You can cd to ~/library and see the contents of ~/Library and trying to mkdir ~/library will fail because ~/Library exists.
What are some of the reasons that teams use conda (and related tools) today? As a machine learning scientist, I used conda exclusively in the mid-2010s because it was the only framework that could reliably manage Python libraries like NumPy, PyTorch, and so on, that have complex binary dependencies. Today, though, pip install works fine for those packages. What am I missing?
For me personally, I prefer conda because it is dependency resolution (mamba), virtual environments, and a package repository (conda-forge) all from one base miniconda installation. And for all of my use cases, all of those just work. Dependency solving used to be painfully slow, mamba solved that. Packages used to be way behind the latest, setting conda-forge as my default solved that.
After fiddling with different solutions for years and having to start fresh with a new Python install, I've been using nothing by miniconda for years and it just works
For me it's the easiest and fastest cross-platform way to consistently install a Python version.
pip and venv work fine, but you have to get them first; and that can be a struggle for unseasoned python devs, especially if you need a version that's not what your distro ships, and even more so on Windows and macOS.
I use micromamba [1] specifically, which is a single binary.
Another reason I used to use conda was for easy native Windows installation. GPU accelerated packages like OpenCV were especially difficult when I used use it 6 years ago. Now there’s Linux subsystem.. has pip support dramatically improved on Windows?
The biggest advantage for poetry I found, working with a lot of non-traditional software people, is that it does a lot of things by default like pin versions and manage virtual envs. Unfortunately, it does complicate some things.
Those are interesting pointers; appreciate it! My own experience over the past three years has been similar. I tried using Pipenv, and then Poetry, for internal projects at my company; in both cases the tool seemed overly complicated for the problem, slow, and I had a hard time getting co-workers on board. About a year and a half ago, I saw [Boring Python: dependency management](https://www.b-list.org/weblog/2022/may/13/boring-python-depe...), which recommends using the third-party `pip-tools` library alongside the standard library’s `pip` and `venv`, and switched to that for the next project. It’s been working great. The project has involved a small team of scientists (four or five, depending) who use a mix of macOS and Windows. We do analysis and development locally and write production-facing algorithms in Python packages tracked in our repository, and publish releases to Gitlab’s PyPI. For our team, the “get up and running” instructions are “clone, create a venv, and pip install -r requirements.txt” and for the software team that manages the production systems, deploying an update just means pip installing a new version of the package. Every team’s got different constraints, of course, but this has been working very smoothly for us for over a year now, and it’s been easy, no pushback, with everyone understanding what’s going on. Really impressed with the progress of the core Python packaging infrastructure over the past several years.
> Today, though, pip install works fine for those packages.
pip install works, but pip's dependency management doesn't seem to (for Pytorch, specifically) which is why projects that have pip + requirements.txt as one of their installation methods will often have separate pytorch installation instructions when using that method, though if the same project supports conda installation it will be a one-stop-shop installation that way.
> pip's dependency management doesn't seem to (for Pytorch, specifically)
That’s interesting — I’ve also had difficulties with PyTorch and dependency resolution, but only on the most recent versions of Python, for some period of time after they’re released. Picking Python 3.9 as a baseline for a project, for example, has been very reliable for PyTorch and all the related tooling.
One reason to choose one over the other is the dependencies they’re bundled with. Take numpy. With PyPI, it’s bundled with OpenBLAS, and with conda, it’s bundled with Intel MKL, which can be faster. See https://numpy.org/install/#
