E.g., https://news.ycombinator.com/item?id=39652860 (no specific comment, just the variety of opinions)
Here's a good specific example https://news.ycombinator.com/item?id=26928696
5,878 karma · joined November 14, 2010
Here's a good specific example https://news.ycombinator.com/item?id=26928696
The problem with this perspective is that anyone who works on more niche programming areas knows the vast majority of programming discussion online aren't relevant to them. E.g., I've done macOS/iOS programming most of my career, and I now do work that's an order of magnitude more niche than that, and I commonly see programmers saying thing like "you shouldn't use a debugger", which is a statement that I can't imagine a macOS or iOS programmer saying (don't get me wrong they're probably out there, I've just never met or encountered one). So you just become use to most programming conversations being irrelevant to your work.
So of course the majority of AI conversations aren't relevant to your work either, because that's the expectation.
I think a lot of these conversations are two people with wildly different contexts trying to communicate, which is just pointless. Really we just shouldn't be trying to participate in these conversations (the more niche programmers that is), because there's just not enough shared context to make communication effective.
We just all happen to fall under this same umbrella of "programming", which gives the illusion of a shared context. It's true there's some things that are relevant across the field (it's all just variables, loops, and conditionals), but many of the other details aren't universal, so it's silly to talk about them without first understanding the full context around the other persons work.
1. Any app can be sandboxed, not just Mac App Store apps (the only link is that Mac App Store apps require sandboxing).
2. Enforcing sandboxing on macOS would hinder industries Mac users value, per my comment here https://news.ycombinator.com/item?id=44952088 Apple would love to enforce sandboxing by default, because it would serve their long-term strategic goals (moving computing towards devices that benefit from integrated software/hardware), but it hurts their short-term goals (maintaining Apple's [somewhat tenuous these days] penetration across a variety of particularly creative industries) too much to do so.
(Also, Apple's sandboxing supports access to a single files, reference https://developer.apple.com/documentation/security/accessing... so not sure if any of this is important anyway.)
> But once an app has free reign to read and write anywhere on a shared folder, it defeats the purpose as opposed to being able to read and write to the apps own folder and the user can choose a file from another folder explicitly.
Not sure I'm following this statement, isn't just being able to read/write to a shared folder a large improvement over an app being able to write to the entire file system (user-permissions allowing, granted)? I.e., "it defeats the purpose" seems like an odd phrase to use there? (For the record, I wish all this sandboxing/entitlement-based security stuff didn't exist on desktop computers [my priorities are clearer from my linked to comment], so I'm probably wrong person to ask anyway, but I was missing what you meant there.)
But something like the After Effects plugin ecosystem I don't think could ever be sandboxed. So it makes sense to have sandboxing conditional based on certain criteria, e.g., the Mac App Store. But even there I'm not sure it makes sense, I suspect we'll never see a Mac-first tier 1 new creative application like Sketch (https://en.m.wikipedia.org/wiki/Sketch_(software)), purely because it's to detrimental to the priorities of that kind of app.
E.g., this one https://www.provideocoalition.com/after-effects-performance-...
Also replying to this re Sketch, especially it being a business choice for them, Sketch is a Mac app through-and-through. That entire application would never in a million years have existed were it not for being Mac only. Sketch leveraged the Mac specific APIs created by Apple in the 2000s (e.g., Core Image and Core Graphics), this is exactly why Sketch was able to innovate on the UI-side (whereas Figma pretty much took Sketch's UI innovations wholesale, as pointed out several times in this comments section), because they didn't need the technical depth that Figma had, which had to re-implement all the low-level graphics APIs themselves in order to be cross-platform (Figma is not exactly a web-only app, it runs on at least Mac native as well, I don't have a source for this but I've heard it a few times [and I don't mean the separate app download Figma makes available, which is just a web wrapper, but there's a real Mac-native internal-only version of Sketch that's used for development]).
This is why for example Sketch was able to launch a compelling product with, I think two full-time employees(?) when it initially launched, that was competitive with Adobe products. This purely a product of the Apple ecosystem and specifically the climate in the 2000s when Apple was still pushing desktop-first technologies like high-quality image and vector libraries. Note also that Sketch didn't take funding until 2019 (and only then because Figma forced their hand), whereas Figma were VC-funded from effectively day one (Field was a Thiel fellow in 2012, first funding round in 2013).
There's two patterns here that were happening during the 2000s, one is bootstrapped Mac-first applications were often quite successful. Two, applications were using the AppKit to quickly iterate on interesting UI innovations, the fuzzy finder (LaunchBar, https://en.wikipedia.org/wiki/LaunchBar), the entire native-app-with-an-API-backend (Watson, https://en.wikipedia.org/wiki/Karelia_Watson), the extension-based editor (TextMate, https://en.wikipedia.org/wiki/TextMate), are some other examples of this.
E.g., you couldn't do this with the type of design I was doing in the 2000s, because the assets we were making didn't scale and recontexualize as easily as flat design elements. I.e., I think flat design not only paved the way for Figma, but also design systems in general.
> They're composing already defined "atoms" into the "molecules" of components and pages.
In this case, `asm.js`, which was the original the core technology that made any of this possible, was released in 2013, which is ancient in this day and age.
It's normally very fast from technology to creation of the initial product to wide-spread adoption (typically about five years from release of the first version, per my blog post). So more likely if this does happen, it will require another core technology breakthrough, e.g., `asm.js` (now WebAssembly) isn't enough to facilitate it on its own.
The key difference in the specific context of Figma is that a layman without any technical skills can give pretty good feedback on a design system, but say, wouldn't be able to give good feedback on how a 3D modeling material is constructed.
> which apparently using the gradient setting in photoshop is a Big Scary Skill™ that flat design solved
This isn't what I mean, I meant combining layers to create 3D effects like this https://www.reddit.com/r/coolguides/comments/kj9yut/guide_to... i.e., creating the gradient itself isn't complicated, it's composing layers to achieve a specific effect that's complicated (and "technical").
Also remote solutions like Jump Desktop (https://jumpdesktop.com) are pretty popular in the media editing world, so folks are choosing to edit remotely, they just aren't using web apps to do so.
So I still think the unique combination that Figma has is that unskilled folks are viewing, commenting, and editing on the document along with designers themselves, using the same tool. And that's facilitated by the tool itself being relatively simple. It's a common workflow that we see with the office suite software that I mentioned.
E.g., take Blender, Adobe Premiere, Ableton Live, Photoshop, Illustrator, in all of those cases, what you export is the actual real asset (it's the movie, the drawing, the song, etc...).
It's not like that with design and it ends up pushing design apps away from native apps and towards web apps, because at some point someone, usually an engineer has to get in there and figure out all the details of how this actually needs to get built. So if the app only runs on a Mac that's annoying. But that's not an issue with say, Final Cut Pro, where the person editing the movie can just export the movie themselves, they don't need to involve someone that's maybe using a platform that Final Cut Pro doesn't run on.
> …and everyone is learning Figma, that’s a viral adoption mechanism that is not possible with Adobe products.
This wasn't possible before flat design, design was a hard technical skill requiring use of light sources, noise for texture, and carefully constructed gradients and shadows. Flat design is mainly just text on large swaths of color, which makes it much easier for someone to just jump in and edit a Figma file (e.g., this was not possible with the much more complicated Photoshop setups folks were using before to create designs like this https://www.anandtech.com/Show/Index/4485?cPage=3&all=False&...)
(Note on a long-enough timeline, it's not clear how this is all going to end up. E.g., if something like Apple's Liquid Design catches up that'll move the needle back in the other direction towards more complicated software to create complex lighting and refraction effects. Note that the problem with Figma isn't that it can't add these features, it's that adding them will make the software more complicated, which will reduce the value-add of it being a web app, because the more complicated the software is, the more difficult it is to use collaboratively. Simplicity is really what facilitates collaborative editing.)
Everything is recognized with the meta, because meta just sends an escape sequence followed by the key code for the other characters.
With all that said, there are thousands of reasons it could be working for you "it's just software" so anything can be programmed, but I'm not aware of say a terminal spec that supports more control codes. Usually when this works it's because the user has implemented one of the many workarounds available online (e.g., change the terminal emulator to send a different key code, and change Emacs to use that key code for the command). It's also possible the terminal emulator you're using has custom support built-in specially for Emacs.
I could fix this myself if I wanted to, but I've just found it's better for my sanity to work with terminal emulators as a clear spec (which includes only the limited set of control character codes) rather than work against that. For an example of how much work this can be to maintain, this is fixing all the discrepancies I've found in Alacritty where it doesn't send the correct key code by default https://github.com/robenkleene/Dotfiles/blob/4d06e9855465c00... I mainly did that to make terminal Emacs usable in Alacritty.
With all that said, if you have another terminal emulator handy, I'd be super curious if it works with that one as well.
(xterm-mouse-mode 1)
A few notes:
- VS Code at #1 (of course) with 75%, Visual Studio at #2 with 29%
- Vim at 24% and Neovim at 14%, which seems pretty whopping to me (I wonder how much overlap is there, the survey is clearly "click all that apply")
- Cursor is 17.9%, wild
- Nano is 12.5%, lol
- Sublime Text is 10.5%, impressive given how much the IDE market has changed
- Zed is 7.3% I wonder if that's enough to be Ramen profitable for a small team? (Not familiar with what Zed is charging for these days)
There are many areas where custom hardware interfaces are popular used in conjunction with software:
- MIDI controllers (note both for the piano keys, and for the knobs/sliders, and even foot pedals)
- Jog wheels for NLEs
- Time-coded vinyl https://en.wikipedia.org/wiki/Vinyl_emulation
- WACOM Tablets
All of these custom hardware interfaces accomplish the same thing: They make using the software more tactile and less abstract. Meaning you replace abstract-symbol lookup (e.g., remembering a shortcut or menu item) with muscle memory (e.g., playing a chord on a piano).
So TLDR, the reason that we don't have what you're looking for is that we don't have a good way to simulate clay and wood as hardware that interfaces nicely with software.
Note there's a larger point here, which I think is more what you were getting at. I think people sometimes expect (and I expected this when I was younger), that computers could invent new better interfaces to tasks (e.g., freed from the confinements of physics). Now I think this is totally the opposite, that the interfaces are usually better from the physical world (which makes sense if you think about it, often what were talking about are things that human beings have refined over thousands of years), and that enforcing the laws of physics usually actually makes things easier (e.g., we've been dealing with them since the moment we were born, we have a lot of practice).
Finally also note that custom hardware interfaces only tend to help across one axes (e.g., a MIDI controller only helps enter notes/control data). The software still ends up being complex because people also want all the things computers are good at that real world materials aren't, like redo/undo, combining back together things that have been broken apart, zooming in/out, seeing the same thing from several perspectives at once, etc...
PS I don't even know if the Holodeck or mind-link up would really help here, it's possible, but it's also possible it just difficult for our brains to describe what we want in a lot of cases. E.g., take just adjusting the exposure, you can turn it down, oh but wait I lost the violet highlight that I liked, how can I light this scene and keep that highlight and make it look natural. I don't know maybe this stuff does map to Holodeck/mind-link, but it's also possible that just having tons of options for every light really is the best solution to that.
I'm not sure exactly what that means, intuitively I agree with your comment, but I guess the ZBrush port acts as a data point that's at least a partial counterargument (only partial because, e.g., Maxon hasn't ported Cinema 4D, which is more directly analogous to Blender).
I'm really curious about the ZBrush port, e.g., is that really because customers were asking for it (or usage data from Maxon's own iPad-only [acquired] app Forger indicated there was interest)? Or is it a defensive move trying prevent an Innovator's Dilemma-style disruption from the bottom from an app like Nomad Sculpt https://nomadsculpt.com?
For my part, I think this is because to do good creative work you need minute control, and minute control essentially just means adding lots of controls to software. Sure you can mediate this with AI, the learning curve especially, but that only really helps unskilled workers and hinders skilled workers (e.g., a slider is a more efficient way for a skilled user to get an exact exposure, rather than trying to communicate that with an AI). And I don't really think there's a need for software where unskilled users have a high-degree of control (i.e., skill and control are practically synonyms).
- Test subjects consistently report that keyboarding is faster than mousing.
- The stopwatch consistently proves mousing is faster than keyboarding.
> In the section on Photoshop to Sketch, we discussed an underappreciated factor in Sketch’s, and by extension, Figma’s, success: That flat design shifted the category of design software from professional creative software to something more akin to an office suite app (presentation software, like Google Slides, being the closest sibling). By the time work was starting on Figma in 2012, office suite software had already been long available and popular on the web, Google Docs was first released in 2006. This explains why no other application has been able to follow in Figma’s footsteps by bringing creative software to the web: Figma didn’t blaze a trail for other professional creative software to move to the web, instead Sketch blazed a trail for design software to become office suite software, a category that was already successful on the web.
It's still difficult for me to wrap my head around that this has actually happened, because it's unheard of in other media editing industries for software to go backwards in capabilities. I always compare it to if movies suddenly stopped needing special effects, then of course the entire existing movie-making pipeline would be re-evaluated.