I think you will open up for a lot of ambiguities. It might be necessary to protect against them by automatic means, like Bison does.

Yeah, I'm taking that as a challenge. If I can find an unambiguous syntax and semantics, the payoff could be huge 🙂. Think about all the fun natural-language tricks you could do when defining functions.

One constraint I'm going to be using is to demand each "function call" be delimited by brackets (...). The contents of every pair of brackets will need to fit a function signature exactly (not a prefix or a subset of it). That means there will be no concept of operator precedence or associativity.

But I may be able to recover associativity by adding a separate feature that captures it.

Multi-word function names look cool, but I'm not sure they are useful. For example, wouldn't your if...then...else function always evaluate all three arguments? Many lisps implement DSLs using macros, including some that appear more like English sentences, e.g. the Common Lisp loop macro (see http://cl-cookbook.sourceforge.net/loop.html)

The syntax concept I’m presenting can be contemplated separately from the operational semantics of the language. So it could be lazy, or strict 🤷‍♀️. I have some ideas about the semantics I want, but that’s for a separate thread 🙂.

Ah, with parenthesis around every call, you might be halfway there. Will you use the & prefix for every argument in function calls also?

Nah, I think the prefix is only necessary to disambiguate the definitions. It shouldn’t be necessary at the call site!

Consider any user defined functions (fun1 &X &Y) and (&X fun2 &Y). What prevents the user from naming variables to make the ambiguous call (fun1 fun2 var3)?

I played a bit with this idea few years ago, to use "symbols with spaces" for JavaScript functions. And I ended using parenthesis I also tried some other weird symbols, just to see if I can find one which is better visually (but failed).

https://stackblitz.com/edit/symbols-with-space

I once thought to use a syntax like the_productof$1by$2 for the name of the function, to tell where exactly you take the parameters.

On this topic, maybe some inspiration can be taken from the text language to specify Scratch Blocks program using text. Which is only used on the Scratch forum. It is interesting that it is not a text language that is designed to be executed directly, only to generate an image of a Scratch Program that might be executed (or not).

https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax

@Axel Svensson

Consider any user defined functions > (fun1 &X &Y)>  and > (&X fun2 &Y)> . What prevents the user from naming variables to make the ambiguous call > (fun1 fun2 var3)> ?

There should be some rules for how and when names/words can be re-used. The simplest is probably that if a word appears in a function name, then it can't also be the full name of a variable (nullary function).

Assuming fun1 and fun2 aren't pre-defined variables, your example doesn't violate the aforementioned rule. However, that call would match nothing, so you'd get a compile time error.

Nicolas Decoster Cool! There are probably a million directions you can go with the idea of space-separated symbols, especially if you start treating them as lists, i.e. data, as Lisp does. I'm being conservative right now though, and just thinking about this as a "generalized function call syntax".

I'm going to check out that Scratch syntax 🙂.

(Regarding brackets: I actually prefer the square bracket syntax partly because it's list-like, but also because you don't have to hold shift to type them 😇).

Check out objective-c’s inline arguments function syntax. https://www.tutorialspoint.com/objective_c/objective_c_functions.htm

(int)max:(int)num1 andNum:(int)num2 {…}

(Regarding brackets: I actually prefer the > square>  bracket syntax partly because it's list-like, but also because you don't have to hold shift to type them > 😇> )

That depends on your keyboard layout. On mine (AZERTY, French), it is the parenthesis that don't need extra key and both curly and square brackets require "Atl-Gr" key. Which is annoying when you code and that's why some French devs prefer using a qwerty keyboard (so without "éàè..." keys).

Ah, I didn’t realise they did that for brackets! I’d love to get some statistics on (for each ASCII symbol) the percentage of people on earth who can type that symbol without any modifier keys 🧐.

It’s really important for a language designer to know 😅

I wanted something like this for my digital scientific notation Leibniz (https://github.com/khinsen/leibniz) and found it very easy to implement since Leibniz is a term rewriting system. There are no function calls, only rewrite rules, so it's no problem to make the equivalent of function-call syntax function-specific.

For the parenthesis issue, I adopted a feature from the Pyret language (https://www.pyret.org/index.html): it requires parenthesis around any operator/function call, the one exception being chained use of the same operator. So you can write 2 + 3 + 4, meaning (2 + 3) + 4, which is the most frequent situation where parenthesis can become visually dominant.

It looks to me as if this approach could be transposed to more standard programming languages, but that's a bit outside of my expertise.

I created a language with similar ideas a while ago, it's almost complete: https://github.com/marianoguerra/interfix

I'm sorry but did you reinvent Agda's Mixfix syntax? 😅

never saw it, so coinvented 😛

interfix doesn't require the underscores

You can call me a convert and subscribe me to your heresy 😛

I've always been convinced of the need to reduce the syntax needed in formal end-user languages, and decoupling parameters from their exact position is a basic tool for that; passing parameters by name instead of position was an improvement in post-C languages, so it's easy to imagine what benefits that style can bring.

I'll go deeper into heresy: in a visual environment (think e.g. a spreadsheet or graphical design tool), you don't even need the function name to be adjacent to the parameters; the environment itself can suggest the list of nearby locally available values that are compatible with the function's input types, and the user chooses which one is appropriate. Applying functions becomes a point&click interaction rather than recalling which syntax I need.

This can even depend on named parameters. Think of an IDE where, when you're passing a parameter to a function, "intellisense" suggests all nearby variables in scope with the right type that could be used for that parameter. Conversely, you could select a value and type a parameter name over it, and it could suggest function names that use that type of the value with that parameter name as a role for the value, so that the user to choose the most adequate suggested function. How many less API reference queries would it take for the user of this system?

In this style of coding, the structure of connections is more important than the concrete syntax of the text you create them with. In my opinion visual languages are the ones that can benefit the most from this separation between structure and placement, as perfect placement of values w.r.t. functions in a graphical environment is more difficult than with raw text.

Vaguely related: https://lobste.rs/s/jol24u/better_operator_precedence

However, that call would match nothing, so you'd get a compile time error.

Nick Smith could you explain how? I imagined it'd match both.

Natural languages split into synthetic (eg Russian, Turkish) and analytic (eg English, Chinese) languages (very roughly). Synthetic languages do a lot of agglunitation and morphology, for example they have cases like accusative or locative and lots of agreement. Analytic languages don't bother much with aggrement and morphology (which is also why NLP on English always starts off so easily). But that comes with a price: English has a relatively fixed word order, whereas in Russian you can basically order the words in your sentence almost any way you like.

So from that we learn that in order to avoid ambiguity, if we could tag the tokens in our programming language with a 'case', we could get away with much more free token order in each statement.

Denny Vrandečić Do you mean we could let the programmer choose the order of tokens for each function call? If so, I'd consider that an anti-feature, because now there are many syntaxes for the same call, and we can no longer exploit our "shape recognition" capabilities to quickly identify a function. There's merit to only allowing the definer of the function to choose the token order. But perhaps I'm missing your point.

Yes, that was my suggestion.

Do you think there are benefits to that level of freedom? Would it help Russians write more readable code?

@Axel Svensson We've probably got different ideas about the underlying semantics. If I had to guess, you're thinking of each symbol in the sequence (a b c) as a value. In contrast, I was thinking of each symbol as a "piece of syntax" that helps identify which function to call.

Under your interpretation, (fun1 fun2 var3) is ambiguous, because it could be interpreted as passing the symbolic value "fun2" to the fun1 function, or as passing the symbolic value "fun1" to the fun2 function.

Under my interpretation, there is no function definition with the signature (fun1 fun2 .), so you get a compile-time error.

But since starting this thread, I've actually been trending towards the first interpretation. It might turn out to be "nicer" in practice, especially as an alternative to passing strings around everywhere. But I think you'd now want/need variable references to be distinguished from symbols, using the & syntax as you mentioned, or even just the parentheses (after all, a variable reference is just a function call with zero arguments). So a function call would look like fun1 (a) (b) or fun1 &a &b. Though I've been thinking about a more lightweight syntax inspired by Rust's lifetime syntax: fun1 'a 'b. It's probably necessary to avoid parentheses/syntax hell.

Since we're all wild heretic here: How about capitalization carrying syntactic significance? Small initial letter means it's part of the invoked function name, e.g. fun1 Fun2 Var3 means invoke fun1 with fun2 and var3 as arguments, while Fun1 fun2 Var3 means to invoke fun2.

So essentially, capital first letter instead of &. The heretical part would be to have the first character (or all characters) in identifiers be case insensitive.

Would that be giving special treatment to Latin-based alphabets though? It would be nice to support arbitrary Unicode. Imagine asking someone writing in Hiragana to start their words with an English letter!

Also, that proposal wouldn't work with symbols like + and *. But I do like the sneakiness of it 😉.

True. "First character in Katakana or upper-case Latin!" :-D

@Diego Moya I think there's a lot of merit to ensuring identical function calls have an identical visual structure. Readability/skimmability is one of my key concerns. I am definitely interested in smart IDEs, but I'm not sure that requiring the use of a smart IDE to specify arguments (rather than having a rigid syntax) is a good thing. If you had this, I'd hope the manipulations would be immediately serialized back into a rigid textual form that is easily skimmable.

Konrad Hinsen To enable the writing of expressions like (2 + 3 + 4), I'm now wondering if I can extend my proposed function call syntax to something based on regexes. For example, to parse the aforementioned expression you might be able to write a function signature like:

&x (+ &y)* = ...

And then &y would be assigned a list of numbers, rather than a single number.

Of course, regular expressions aren't known for being easy to understand. Perhaps I could find a somewhat simpler pattern language that still allows the description of arbitrary-length expressions.

Denny Vrandečić There's Perligata for a transposition of the analytic vs. synthetic concept to programming: https://users.monash.edu/~damian/papers/HTML/Perligata.html

Nick Smith Pattern matching looks like an idea worth exploring. But as you said, it needs to be more human-friendly than regex.

Mariano Guerra Was interfix in any way inspired by Smalltalk? Smalltalk keyword messages feel very similar.

Konrad Hinsen yes, smalltalk and dylan where some of the inspirations

Nick Smith not sure if there's a benefit. In natural language it has the advantage of emphasis. It can give some flexibility w.r.t. visual layout of the code. But in the end, it might make it more complex without a clear win. I am not advocating it, just an idea 😄

Having thought about things further, I think my proposal ends up being about metaprogramming and homoiconic languages pretty quickly. Perhaps I should search for inspiration from those.

I also took a crack at this 2 years ago. We called it "anyfix"/"omnifix". It's fun to see these other implementations with names like Interfix and Mixfix!

The use case for us was talking to medical care providers and discovering that many would invent their own written shorthands (grammars) for jotting down EMR data while working with patients, which would often have out-of-order parameters (20 inches 10lbs or 10lbs 20 inches etc). IIRC ambiguity was the exception rather than the rule. We figured if it's very clear to humans what the intent is the parser should be able to figure it out too.

It was rather easy to implement in Tree Notation, which is a whitespace based syntax where each row is a node split into cells. The line parser first determines what kind of node the line is, and then a cell parser determines what the type of each cell is. A node definition states the cell types expected and whether to use a prefix/postfix/omnifix parser. Simple tests (such as regex) are then used to detect the type of each word in the omnifix case.

In theory this puts the onus of avoiding ambiguity on the language designer, but in practice (IIRC from our small experiments) it was surprisingly easy to avoid. It seemed that usually when you have 2 params with the same type, it was often better to take a list instead.

A really dumb toy demo for our implementation: https://jtree.treenotation.org/designer/#standard%20poop

My language works this way because it's not based on functions as such, but on a lower-level mechanism: rewriting after pattern matching. The "function" symbol is just another pattern element, not distinguished from "data" or "parameters".

Duncan Cragg Yeah, I'm thinking of this in a similar way: a "function signature" is just a pattern, where none of the tokens are special "function name" tokens. Function calling is just pattern matching. However, I'm not thinking about rewriting, since that is conflating operational semantics with the mere syntax presented here. The actual means by which a computer executes a program consisting of these patterns can be considered separately.

I'm aiming for a very non-conventional operational semantics, inspired by relational programming.

Nick Smith I see your point but I think you would probably gain from studying term rewriting systems. A main featured distinguishing term rewriting from traditional function-calling approaches is precisely the separation of syntax and evaluation. Term rewriting systems start from a term algebra, which just says what valid terms look like. The next layer adds patterns and pattern matching, the result of which is a substitution. With patterns you can define rules. Rewriting is yet another layer, in which you have to decide on a strategy to select and apply rules. If you want different operational semantics, you just change the last one or two layers, but you can keep the lower ones.

In contrast, with traditional PL design, there is no useful layer between the AST and the full language, evaluation semantics included.

What if my semantics involves the equivalent of database equi-joins and aggregation? Surely those can’t be described in terms of term rewriting.

i.e. my operational semantics has nothing to do with substitution of terms

I am not a database expert, but my first reaction is that everything can be encoded in terms. Terms are isomorphic to s-expressions, XML trees, etc. You may in the end want specialized hand-written implementations for some of those terms, for performance reasons, but I'd be surprised if your semantic would be impossible to express as terms.

Rewriting is Turing Complete so you can do anything you want. 😃👍

The actual transformation mechanism from before-state to after-state in the rewrite needn't be TC, though, and is probably better off not, so it terminates!

Primitive Recursive perhaps? Need a fixpoint each time: when applying the rewrites has no effect or there are no matching rewrites.

I was searching for the rationale behing the Ribbon UI redesign at microsoft, they should explain pros and cons of each approach somewhere, I found this: https://www.youtube.com/watch?v=Tl9kD693ie4&list=PLjCU_7jji6Ch8l9YAJVBfdOQUk6k_ve5D

https://martincolebourne.com/2014/09/15/whats-wrong-with-the-ribbon/

https://jensenharris.com/home/ribbon

It’s worth watching (or re-watching) Alan Kay’s Doing with Images Makes Symbols https://www.youtube.com/watch?v=p2LZLYcu_JY which gives a lot of insight into how they were thinking about representation, language, etc in the early GUI (and Smalltalk) work

Using text labels with icons is always better and more clear.

It’s hard to say why a specific interface relies on icons exclusively. It may be: lack of usability testing, graphic designers doing interface design, ignorance, lack of time to come up with better solutions, preferring aesthetics over accessibility.

Of course, using only icons can be okay in some cases: The longer one uses a tool and the more familiar one becomes with a tool, it might make sense to hide labels for less noise and more space. macOS toolbars provide users the option to choose between “text and icons”, “icons only”, “text only”.

There have been attempts to design user interfaces that adapt with time and usage: from high information density in the beginning that slowly hide labels the more often you use a feature.

General rule of thumb: except for arrows and handful very common icons, most icons will not be understood by users and text will always work better.

This is the classic, "beginner user vs. professional user" dichotomy. What is good for one is not necessarily good for the other.

Instruments are the classic example. Pianos don't come labeled with the notes on the keys. Though students will often add that kind of thing when learning the instrument, as they become more advanced, they remove those kinds of aids.

All the examples you listed are what I would consider "professional software". They are designed for people that already have a lot of experience in their respective fields. With that extra background context, those icons probably carry much more information.

In fact, for many professional software packages, the users don't use the GUI, often preferring keyboard shortcuts. For the professional, "discoverability" is not a problem, speed and intuitive workflow is.

Here’s the post about “Progressive Reduction” that I had in mind:

https://layervault.tumblr.com/post/42361566927/progressive-reduction

And here’s a detailed article on the topic of icon usability: https://www.nngroup.com/articles/icon-usability/

It all comes down to learned familiarity.

If you think about signs (pictograms) at an airport or train station, they are not only large in size but also represent the real world (planes, food, bath room, people, …) which makes it easier to understand those pictures.

But icons in software often need to represent abstract or novel features that don’t have a real world metaphor. And worse: they are often displayed in small size and too many of them nearby.

Another example that comes to my mind are traffic signs that may not come with labels but which need to be learned in driving school. Traffic signs come with color coding which can certainly help to convey additional meaning.

Adnan Chaumette The toolbar on the right side of Pixelmator shows icons only, but once you hover over an icon, labels for all other icons are shown as well. https://www.pixelmator.com/support/guide/pixelmator-pro/1218

Not a web historian but if I had to guess … in 2001 the web was still reasonably close to the idea of readability (and simplicity) of html - that was mostly what you had to know and understand to make a site. (This doesn’t mean it was a good framework … ).

JS changed that drastically.

I think it's way easier isn't it? Most people use things like Squarespace, Shopify, WordPress etc. Expanding the definition of "website" somewhat, lots of independent small businesses (restaurants etc) use their Facebook page as their primary online presence.

I think what people are nostalgic about is the ability for a lone hacker to max out the possible quality of a website. That is, in 1996 your personal static HTML site had a similar perceived quality to CNN's.

People say similar things about game development. How come it used to be that a single 15yo could write a world class game, now it needs a team of 100 professionals? Well, the definition of "world class game" moved a long way.

Certainly between 1996 and 2021 "make a website" has become something that my parents can do.

I don't know about 1996 exactly, but you can still make websites with very simple tech if you feel like it. I don't know if you can still find reputable shared hosting with SSH, so you might have to admin your own server, but plain HTML still works. Inline JavaScript still works.

I guess I agree with Chris Knott, but would phrase it differently: A lot of the change is that people's expectations have gone up as we've seen what's possible.

Which is not to necessarily say that software doesn't also have some kind of unhealthy relationship with complexity.

“Because our industry has a codependent relationship with complexity.”

[my reaction to the above statement]

Definition of Simplicity

“Lack of Nuance”

Source of Complexity

Problems have a number of degrees of freedom - dimensions.

Our reality appears to have 4 dimensions (4D) - x,y,z,t.

Trying to squeeze more than one dimension into a single notation results in what we perceive as complexity.

Flattening 4D (reality) down to 2D (pen and paper) results in “complexity” - some things become merely harder to express. We need more than one 2D notation to express 4D concepts, each in a seemingly “simple” way.

Complexity Is In The Eye Of The Beholder

Nothing is “complex”.

The use of a mis-fitting notation might make a problem appear more complex, but does not change the underlying nature of the problem.

more at https://guitarvydas.github.io/2021/10/14/Complexity-vs-Simplicity-II.html

No question that some of the complexity is well-justified. It's also equally clear that times of increasing complexity provide lots of cover for capture and rentierism. Such times are when priest classes gain power. If the "complexity inequality" grows too large in society it can become irreversible. The time for an intervention is when the priest class is still small and relatively ineffective. It's questionable if the programmer priest class is small these days, but it seems clear that it's ineffective. Society is constantly reminded these days of its failures. So these debates seem very valuable.

Chris Knott You're right that the space of possible quality has expanded a lot. An additional part of the problem is that the supported part of the space is a tiny fraction of the total space. Someone learning how to build websites today is unlikely to encounter pure-html tutorials anymore (that are not references). There's a pervasive implicit assumption in tutorials that the end point is CNN's website, which requires lots of ongoing maintenance in exchange for its perceived quality. I think it's valuable to expose people early to the idea of wabi-sabi in software.

In 1996, I found it stomach-churningly complex and frustrating to figure out how to even run more than a basic web page from my university network's servers, not to mention running a server myself, especially getting configurations right and the early versions of CGI working – I had years of web ptsd – no warm and fuzzy feelings here

Yes, html was easy, at least that

the dream of the 90's is alive at https://neocities.org/

https://glitch.com/ is also pretty fun. My 90's self would approve.

The question posed initially requires some context: Is making a Web site harder today than in 1996 - FOR WHO?

For someone familiar with Web technology, the answer is no, as others have pointed out: if you want a plain HTML site, you can still make one with exactly the same effort as in 1996.

For someone familiar with just browsing the Web, who then wants to move on to creating a Web site, the answer is yes: it's much harder to get started because of the enormous labyrinth of paths you need to evaluate to make a good choice. Most of them end in some non-obvious trap such as a walled garden.

In 1996, you could walk into a book store, buy "Web sites for Dummies", and get going. Maybe some other book would give slightly better advice, but you couldn't make a serious mistake following any book's advice. Today, there is no obvious place to look for guidance, and most advertised solutions can be a serious mistake, depending on your requirements.

So Konrad you would see it as a "Paradox of choice" issue?

Yes, that's the main issue. With evaluating the options being the most difficult task, in a context where advertising abounds, educational resources are rare, and the market changes so fast that evaluations become rapidly obsolete.

Is it possible for a one or two person dev team to build an open source photo management app? Ars Technica thinks not, it's just too complicated:

Our perhaps unsatisfying conclusion to this seven-app showdown exposes an important truth: the photo management software world is too complex for a one- or two-person dev team to properly handle.

https://arstechnica.com/gadgets/2021/06/the-big-alternatives-to-google-photos-showdown/

Certainly if you want to have lots of users, grow like a weed. But I'd argue most teams with more than one or two people fail at that as well. So, just don't try that maybe?

https://www.robinsloan.com/notes/home-cooked-app

100 people building for 100M people: very hard. Doesn't matter what you build.

2 people building for 10: very doable. Doesn't matter what you build.

Thanks for sharing this great article , Kartik! Some quotes:

In a better world, I would have built this in a day using some kind of modern, flexible HyperCard for iOS, exporting a sturdy, standalone app that did exactly what I wanted and nothing else.

In our actual world, I built it in about a week [...]. I waved some incense and threw some stones and the gods of Xcode allowed me to pass.

And:

This messaging app I built for, and with, my family, it won’t change unless we want it to change. There will be no sudden redesign, no flood of ads, no pivot to chase a userbase inscrutable to us. It might go away at some point, but that will be our decision, too. What > is>  this feeling? Independence? Security? Sovereignty?

Is it simply… the feeling of being home?

I really like this idea of home-cooking app (or computing to be more general). I also find the parallel with cooking very nice and expressive.

I remember the article that Kartik Agaram shared from a while ago. Back then, it got me thinking. I have a few ideas for similar few-people situated apps that I could use. But there's still a huge learning curve for mobile platform development, plus the eternal risk that whatever development tool you choose will not be supported under future versions of Android and/or iOS. In other words, in my mind mobile platforms are inherently unstable, much like Web platforms that go beyond plain HTML. Am I wrong there? What's the track record for the longevity of mobile apps?

I think you're exactly right. What my efforts to be more radical have taught me is that it's really difficult right now to avoid these issues. So I have even more appreciation now for people making these difficult trade-offs as best they can with the knowledge and skills they have at hand.

I've been spending some time in the Collapse and Permacomputing communities lately. And noticing that even if they turn out to be too pessimistic about our future, the approach they take helps us today. We don't have the capacity to perfectly reshape our computers, so we're forced to accept them as they are and adapt them to our needs as best we can.

Extremist approaches often end up useful in more moderate settings. I had seen permacomputing before, but not CollapseOS. Reminds me of the computer I used in the 1980s (a Colour Genie to which I had ported Forth myself). I knew every byte in the ROM of that machine.

I think this is the implicit motivation for a lot of research and tech choices. Languages trying to be predictable (Go) are focused on maintenance. Rhetoric about readability, how programs are read a lot more than modified, Literate Programming and how programs should be written for people to read. Automated testing and version control are arguably the biggest recent advances.

In spite of all the research it remains a problem. I think it'll never be completely solved because better tools just cause people to take on more complex projects, the way building more roads never seems to eliminate traffic jams. And those local complexifying choices pollute our shared commons.

Dijkstra said his brain is very small and can only handle small programs. Dennis Ritchie said if you write programs using all of your brain you won't be smart enough to debug them. Illich warned us of the consequences of adopting tools too quickly. Unfortunately the world doesn't listen to any of these prophets. After 10k years the prisoner's dilemma continues to reign supreme.

s/Dennis Ritchie/Brian Kerighan/ 🙂

I am not aware of anything like that that has actually been tried on a large enough scale. The closest I have seen proposed recently is https://playb.it/. I suspect that in today's economic environment, it is not obvious how to develop such a platform commercially, nor as an Open Source commons, but I'd love to be proven wrong.

My view of Glamorous Toolkit in this context is as a tool for developers and power users, not as the framework you describe. Technically it would be one app among others.

Another interesting question: how far are the JVM and .NET ecosystems from the view you describe? After all, they were designed as frameworks that share some of the listed goals.

a web browser? 🙃

an android emulator 😄

https://www.lexaloffle.com/pico-8.php

T2 Tile talked about packaging all in a single file recently https://www.youtube.com/watch?v=kXrD-mrQ4QA

don’t have a video off hand but I believe Jonathan Blow has talked about this as well. The pitfalls of universally reference-able packages & package versions in an OS environment, vs each one just bringing their requirements with them

The idea of packaging apps with all their dependencies has been proposed and implemented many times. What's new in Kartik Agaram proposal is "long with all the tools needed to edit, build and run them". That implies full transparency, which is very far from how we use containers nowadays.

PICO-8 is a great point. It has editing tools and everything right within the same 128x128px screen.

The Android development environment is a thought-provoking answer as well. .apk is a single file. Can you run it just by passing it to the Android environment? Even if it opens in the IDE, hitting one keystroke to get to the simulator doesn't seem such a big deal. Seems akin to the Borland tools from the '90s which were pretty nice.

Which has me wondering what other requirements I need to add 😛 I think a key piece is: the only way to run the app is from within the development framework. It's impossible to run in isolation.

Zooming out to a whole computer is a way to trivially satisfy these criteria. Hence my attempt to start out focused on a single app that the end-user is using.

Ever since I learned programming I wanted to build polished apps like the ones I used to learn programming. For example, I was never satisfied with the programs I built on my BASIC interpreter because it forced me to hit Enter after pressing a key, where I could see the professional apps respond instantly to any key. I think this instinct is widespread and has basically been leading us all astray. If we just commit to never bundling apps without their development environment, never completely hiding the development environment, I think that one constraint, that commitment to a little less polish and a little more overhead, might have cascading benefits.

We'll have to fake it till we make it for a while, because clearly there's no market pressure to do this today. "Forgive them God, for they know not what they do."

I've read something similar about scratch, students don't like to learn with a toy environment since they know professionals don't use that. They want to learn "the real stuff"

I know the feeling. When I learnt to program the most important thing was that my program had a custom icon and appeared under Programs on the Start menu - like Real Software. What it actually did not so important.

Not sure how to reconcile that with something like TikTok where people don't mind about not using Real video editing software.

I think one aspect might be that they are seen as "a TikTok" rather than "an edited video". In this paradigm it might be seen as inauthentic to edit it outside the app on a Hollywood editing desk, then somehow upload it. Kind of like writing a compiler that targeted minified PICO-8 - it would be seen as dishonest.

Probably it's comes from the privilege of not having a real need.

If you actually just want to plan reservations at your restaurant, organising training sessions for your cricket club, budget your wedding etc (i.e. what people use Excel for atm) then you don't care what it looks like, only what it does

I think DOS-like (https://github.com/mattiasgustavsson/dos-like) fits into this also. It comes with a C compiler (tcc)