Yep. Typical landscape crew rolls with $50k in equipment (maybe more). People push back on tooling pricing in other industries (especially when the tooling is "soft') but have no clue what that the cost of doing biz is huge for others.
You're pretty lucky if the specialised tools for your profession cost <$2,000/y to replace and maintain. Sometimes tools last many years but cost an order of magnitude more anyways. Sometimes tools require expensive maintenance after purchase. Sometimes they are obsolete in a short number of years. Sometimes they were out quickly with use. Sometimes (often) a mix of the above.
Regardless the reasons, any tooling in the ~$5,000/~3 year ballpark is not at all a high or unique number for a profession.
What benefit do you hope to realize from distributing via the App Store? They aren't going to handle payments for you. They won't market your app for you.
The biggest benefit I'm looking for is one-click install for non-technical users who (as I understand) would otherwise be faced with the "unknown developer" warning and would need to be directed to these steps -
https://support.apple.com/en-ca/guide/mac-help/mh40616/mac
I should really emphasize that the target market for this app (eventually) isn't developers or hackers, it's artists, musicians, and event hosts who want something much simpler than the existing paid options.
You can still sign and notarize your .dmg without distributing it via the app store. Users who download from your website won't see the "unknown developer" warning as long as you do that.
Your second point about your target market is much more salient. Tough call.
I don't expect you'd see a difference. For the simple case of iterating on a diagram you describe to ChatGPT, 4o is perfectly fine as-is. I can't see how you'd meaningfully improve on it.
However, for the advanced case of generating a diagram from a repo, AI isn't even close. You'd need practically unthinkable improvement for it to be useable.
The consequence, unfortunately, is incremental gains won't help in either case.
Yeah, just about every diagram you see online commits these sins. Probably because companies that create detailed diagrams don't make them public. What's left is mostly diagrams by tech companies (e.g. cloud providers) created specifically to promote the technologies themselves.
What are the alternatives for diagrams? Would an ascii diagram be better? I'm not sure if screen readers would ignore all of the random characters or not.
I'm assuming just a text description would be better, but I don't know what other options are available.
Apple has gotten really good at text selection in images. I can take a screenshot of a webpage and then select the text in the screenshot, or I could take a photo of a sign and select the text in the sign.
Do you know if there is anything similar for screen readers?
For screen reader accessibility, isn’t text a better option? If I were working with an engineer who uses a screen reader, I’d document heavily in text. Good practice anyway, since diagrams aren’t great at depth.
I'm biased, but I think it's a bad decision. Programming languages are for writing, well, programs. Programs execute, accept input, have state, and all manner of other things that just don't apply to diagrams. Diagramming in a programming language is just weird.
This is a program that executes and produces an output. It also has state - every step of executing that DSL is creating and manipulating a piece of state that builds up a declarative description of what the final output should look like.
The other thing you list, input, is optional. I write programs that don't take any input all the time. Monte Carlo simulation, for example. The entire demoscene is largely devoted to creating incredibly sophisticated programs that don't take any input. Postscript is a full, Turing-complete language whose primary purpose is to create programs that generally don't take any input
Programs that produce diagrams should be (and are) written in a programming language. They accept input, execute, and produce output. Diagrams themselves do not execute and have state (unless they are interactive[0]). There's a difference.
Be aware the poster has a history of being very active on posts related to diagramming tools to discourage his competitors' solutions and/or promote his own tool without disclosing affiliation.
Recipes absolutely should be written in code. If I could view source, copy the recipe yaml, and paste into my personal recipe manager app, it would be much more convenient.
Screenplays... are already written in code, partly. If they weren't, they'd include quotation marks and "she said" after every line.
I think the counter-point to that would be that if you're writing infrastructure as code, and your architects are using a specific language anyways (Python in this case), it makes more sense for data governance and editing reasons to just keep things in the existent ecosystem and not worry about having to procure another license.
Vs. Cooking or Writing which aren't coding practices unto themselves.
You can do it, certainly, but it is overkill. It also limits your potential editors to people who know Python and are willing to install it on their machine. In contrast to Python (or other programming languages), a language like YAML or JSON can be learned in minutes by just about anyone.
