No, I mean answer set programming in the sense of stable-model semantics logic programming.

Is that something from languages like Prolog?

Yeah, it is a subtype of logic programming, I would say.

In my worldview, the distinction between creating an app and using an app is artificial.

• When someone uses an Excel spreadsheet, they create programs (formulas) that will be invoked whenever new data is added.
• When someone uses a note-taking app, they create a hierarchy (or a web) of pages which allows them to later navigate between pieces of knowledge. The links between these pages amount to a program: a link is an instruction that says "when someone clicks me, navigate to this page".
• When someone uses a calendar app to send reminders, they are programming the computer to provide them with customized notifications about upcoming events.

Under this lens, everybody wants to be able to create their own programs. The problem with today's world is that we silo programming into two realms: the "end user" realm, where programs are small and easy to create (but are extremely limited), and the "elite coder" realm, where programs are large and are very challenging to make (but are very versatile).

The route to the Future of Coding requires us to stop believing that this dichotomy is "good" or "natural".

Most people don’t /think/ that they want to create their own applications. Yet, a select few went for Hypercard and spreadsheets. Dentist office software began happening only when spreadsheets became available. Spreadsheets were invented for Accountants, but innovators with domain expertise in Dentist Officery picked up on the new paradigm.

This makes me think of Franz, Inc.’s business model (free, but % royalty on all apps).

Nick Smith that's a cool worldview. So, if I understand correctly, you see "end-users" extending apps instead creating them from scratch? *at least, most of them

Paul Tarvydas in that example, were the dentists themselves creating the apps, or was it "programmers" along with dentists and their domain knowledge creating them? if the latter, is the end-user programming effort just lowering the barrier for developers to create apps?

At first, it was the dentists - the domain experts - who began to see that they could make computer software without having to “learn how to program”. The “experts” - programmers - came later to make the apps more robust and scalable. Programmers only have domain expertise in programming, not in running medical offices, nor accountancies, nor ... I use(d) a book-writing tool called “Scrivener”. One of its selling points is that it was not created by programmers. Having experience with software, I see all sorts of warts in Scrivener, but, I wouldn’t have been able to invent Scrivener. Spreadsheets, Hypercard, VB, etc., etc. are like gateway drugs. Non-programmers used these tools to express automated versions of their processes. Later, expert programmers cleaned up the ad-hoc messes. This effect can even be seen in programming itself. The “experts” tell everyone to use FP, recursion, monads, etc., etc., but the majority of “real programmers” prefer HTML, JS, Python, Perl, etc. There /should/ be a huge market for enabling invention, but, it must not appear to be complicated, nor expensive.

Borland targeted developers and disappeared. VisiCalc did not target developers and its ideas morphed into Excel, etc. Did the VisiCalc company have an exit strategy or was it simply overtaken by newer versions of the ideas? (idk).

The inventions came from so-called non-programmers.

Henry Ford (?): “If I had asked people what they wanted, they would have said faster horses.”

@Ricardo Medina I would phrase it as: end users are likely to make simpler programs (like the examples I mentioned), purely because they don't have the time or expertise to make more complex ones.

I wouldn't think about the Future of Coding in terms of "apps". An app is a hard boundary that discourages interoperability and thus inhibits creativity/flexibility in programming. This is by design: companies want to lock you into using and paying for the programs they write and the services they provide. There's no commercial incentive to break down the artificial boundaries.

Apps aren't natural. CPUs don't execute apps — they execute instructions. Apps are a result of companies trying to adapt the notion of a product— something you can put into a box and sell to a customer—into the digital realm. In fact, until the late 2000s, most apps were literally sold in physical boxes with a price tag attached.

The Future of Coding is not about encouraging companies (in vain) to allow their users to make modifications to the apps they sell. At least, not if I have anything to say about it. Software should feel like a continuous fluid, not a collection of impenetrable boxes that have small holes for a user's data to trickle in and out.

The sorts of things it should let you say include:

Jason is a Person

Bob is a Person

Jason is Bob's Friend

Plus partially ground statements:

Everything is Bob's Friend

Bob is Everything's Friend

Plus unground statements:

Everything is a Person

Everything is Everything's Friend

Plus the ability to make any of those statements replacing "is" with "might be".

I am aware of "statement builder" interfaces. I'm looking for something more visual, less linguistic, like nested trees, or graphs.

I doubt someone has made a user interface specifically for the semantics you are describing — it sounds like you're doing something very niche. I'd encourage you to come up with your own design 🙂.

I don't think it's "niche", so much as "novel", but I take your point. Just don't want to duplicate any effort.

Yes, sorry, perhaps I should have used the term novel/unique instead.

One part of what I'm working on is to capture the implementation of "Definitely X, maybe Y, not Z" That is, the code which implements a user application from those facts and constraints.

While we focus on enabling the mapping from user inputs to the code needed for implementation, I've often pondered other ways users might "encode" those facts and constraints. Today, our users write CUE, with plans for web/ui based interfaces. Maybe your language could act as a frontend to our tool: docs.hofstadter.io

What do you think? If your language tools can output a structured format like JSON, I think it could work

I wonder if the field of “fuzzy logic” is somehow related to these concepts. Googling “GUI fuzzy logic” results in hits.

Another concept that fuzzy logic can capture is multimodal probabilities. For example 53% Laurel, 0% maybe, 47% Yanny.

The reason it's not common is because it's slow so only problems that really need it build from scratch.

Another example is Kalman filters where values (like position) are Gaussian distributions and through the combination of different sensors can you constrain the possibilities

It's funny you should mention fuzzy logic. The guys who invented s(CASP) point specifically to systems that used probabilistic logic, and say that if you reduce the options to 25%, 50%, 75%, and 100%, encodings in those systems loose none of their predictive power. They note that if you reduce the options to yes, no, and maybe, that's analogous to 0%, 50%, and 100%, and they predict it will also lose no predictive power, because it is how people think, and it will simplify generating rules and facts. Obviously, doesn't apply to things that are inherently probabilistic, but they were talking about expert systems for recommending antibiotics, e.g.

Paul Tarvydas I will look that up, thanks.

@Tony Worm The interface is entirely for the purpose of generating JSON. I'll share it here, and if it's useful to you, streal it. But be warned you will probably want to tweak the design, and completely replace the code. 😉

You can also look into topos theory for a different view at multiple truth values ;)

or CUE's lattice: cuelang.org/docs/concepts/logic

What are some examples of X, Y, Z here? I'm intrigued by the idea of more humanistic thinking being represented in computational interfaces -- but can't quite wrap my head around why this is a gap in current user interfaces.

Is it, for example, a pesto recipe -- definitely basil and garlic, maybe pinenuts, maybe walnuts, maybe parmesan, not ginger? Is every other option that's not definitely and not definitely-not a possible maybe ? Or is maybe in fact a suggested-maybe and not an unknown-maybe ? i.e. parmesan is a valuable maybe in pesto and worth calling out, while anchovies are not... but they're not a definitely-not !