I’ve started reading a small matter of programming (http://www.amazon.de/Small-Matter-Programming-Perspectives-Computing-ebook/dp/B00BJGM0NE/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=a+small+matter+of+programming&qid=1569265869&sr=8-1). A compelling thought I found in the book is the idea that the success of end-user programming doesn’t depend on a silver bullet. Many ideas promise to deliver end-user programming like natural language programming, programming by example or visual programming languages, etc. Instead of finding a “magical” solution that solves all problems, the author argues that the main criterion for the success of an end-user programming environment is that users can express their issues with constructs that map well to their knowledge domain.

the basic operations [of the environment] accomplish tasks that users want to do

As an example, the sum-function in a spreadsheet application does something meaningful for a person who wants to calculate a budget. In comparison, a for-loop in a general-purpose language is very generic but it isn’t useful on its own. This to me suggests that there is an inherent conflict between the needs of end-users (solving a problem in a specific domain) and the goal of general purpose programming languages (being applicable to a great variety of different domains). My personal interest is more in the camp of building new end-user environments that solve a specific problem domain. I think other projects here in the slack are more aimed at finding better general purpose languages. Do you agree with this categorization and if so in what category would you put yourself?

I think many people here are looking at better general purpose programming languages, but it’s not obvious that what you wrote means that end user programming can’t involve a general purpose language.

Yes, I know but the sum in a spreadsheet is different because it works in combination with the grid of the spreadsheet. You don't need any additional constructs you can just put down numbers and combine them with the sum function to create quite complex applications. Compared to a general purpose programming language with a sum function where you need to create variables, dealing with reading in the data and putting out the results, maybe you have to put all numbers in a list first. All concepts that have nothing to do with the problem of the user.

That’s true. I suppose it’s not so much about the functions, so much as the input methods, or data models.

Summing a list is declarative, for loops are imperative. It's not about being closer to a domain versus more general purpose, it's about what's easier for humans. I'm working on a general-purpose, end-user programming system, which is declarative because I believe that's what makes everything easier for normal people. And it's a silver bullet. 😄 Maybe you could illustrate the point better with a different example? Which may start to wander into DSL territory.. (But many DSLs are declarative..)

i think airtable is actually a great example of a more general tool that a lot of end users are using in very complex ways

@Duncan Cragg

fold

vs

sum

probably is an adequate example. Heck, Rust has

sum

because one of the core members hates

fold

(and I’m team no-fold too, even though I like FP).

The spectrum between domain-specific and general purpose is a powerful thought technology, and a great way to compare and contrast tools. I'd say a good number of people here are working on something domain-specific. I am, to be sure. Even within general purpose languages, you sometimes see a good acknowledgement that there's an ideal use case bordering on domain-specific. For instance, Racket is a general language specifically for making DSLs. Elixir and Erlang are general languages designed primarily for massively parallel server applications.

i feel like i could interpret that statement three different ways and i like all of them

Don't forget languages like Red and FORTH and LISP, which are general purpose languages, which allow people to construct their own DSL. DSL's however create problems as well as solve them, as now you have invented a new language which has to be learned by someone else....

Paul, I recently read this book and it is totally awesome imho. I agree with your thought and on my opinion we see the trend of more and more tools for power users (the author introduced 3 levels like users, power users/creators, programmers). I envision we will have more such tools in all domains and niches. I also think DSL is close to expert domain vocabulary and is much easier to learn that any general purpose programming language. Why Eve and HyperCard failed (in a way)? They were too general and lacked focus. HyperCard demanded real programming (and Eve as well).

@Duncan Cragg Yes, I think declarative languages are inherently less complex than imperative languages. I think in this case the declarative nature of the sum is not the only reason why it is more approachable say for an accountant as an example. If you contrast the spreadsheet SUM function with a simple map function. Both are declarative but SUM is a concept that’s familiar to the accountant while map is a foreign concept that is unnecessarily generic if all the accountant wants to do is calculating SUMS and a handful of other statistical functions. Edit: saw your second comment fold is probably a better example

Declarative is the future. You tell it what to do it but hopefully less information about how, so as to lessen the burden on the programmer. The issue with declarative is to stay general enough because as HTML has demonstrated, if you don't offer a sensible set of low level primitives, you end up with 1000's of options. Look at the crazy-quit that CSS is. A truly maddening, horrible layout system that is mostly declarative and an obstacle to progress.

@Edward de Jong / Beads Project Yes, and that's the difference between DSLs (still mostly declarative) and what I described in my youth as DTILs - Domain and Target Independent Languages. Which I imagined as declarative simply because it seemed that imperative languages only exist to keep machines happy, not humans.

I think in a well-designed system, there is as little tension as possible between tools that are well-shaped for narrower problems, and the existence of primitives which are general. I am adopting the philosophy in my system (which is for general purpose end user programming) that narrow tools are built out of general primitives. Encapsulation prevents the user from having to worry about the internal details of the constructed narrow tools, but the generality of the elementary primitives avoids the "patchwork quilt" problem that @Edward de Jong / Beads Project nails. I think a lot (really most, probably) end-user systems make the mistake of eschewing simple primitives in favor of a large set of narrow tools. IMO there is so much wrong with that approach it invites an entire essay, but I think some sense of it has been captured here— the user is burdened with having to internalize many more primitives, but is not empowered to make their own (which they can then encapsulate, share, and forget about the internal details). To return to the original example, my system has both

sum

and generic iteration. Sum would look like this:

(Aside) @tbabb — You made that linxtool project? Awesome! I loved the write-ups, and feel like there are some really fresh and exciting UI ideas in here.

thanks! there are many more UI goodies that I plan on hitting which are not yet pictured— spending my time on coding for now, though 🙂

I think I would put myself in the specific domain camp. The problem of finding better general purpose languages just seems impossibly hard and I'm not too deep into coding. But at the same time in a particular domain you need some means to go lower level. My particular domain I'm interested in is math, which already has something like an informal programming language/paradigm with set theory and the axiomatic method. Its pretty great but doesn't have any dynamic capabilities. Also, those capabilities dynamic capabilities you would want wouldn't necessarily be about big computations but as a matter of the interface for math. So it all has to be a part of a medium that extends current practices in math. So for this particular domain the programming language doesn't seem like the major thing to be interested in except in a generalized sense if you regard it as part of a medium and set of practices.

hadn’t seen lynxtool—it looks awesome!

It seems to me that we need both (1) better general-purpose languages, which is the popular thing to think about in here, and (2) a big library of functionality that can do a wide variety of stuff, like Wolfram Alpha but open-source. I have this idea of building a web site for crowdsourcing ideas about API design; the idea is to encourage standardization of APIs in various problem domains, both general and specific... I figure users could both submit API designs and reviews of designs. Rather than voting on APIs as merely "good" or "bad", I think they should be reviewed on several axes like "easy to use?", "flexible?", "enables fast/efficient implementations?", "adapts easily to many potential implementations?"... really good designs are good across many axes.

There is a 3rd alternative that was the original intention of the great John Backus, who invented FP after developing FORTRAN. In his original vision for his next general purpose language, he was seeking to enter into an era of interchangeable parts. In such a world programming is a great deal less troublesome; you just snap together components, and can build elaborate systems out of already-tested parts. At present, the JS world uses npm as their package manager, and you can see the exponential "drag-in" where the dependencies grow exponentially and adding some little thing suddenly pulls an ungodly amount of code into your project. Since things depend on other things, there is always an exponential growth curve to a project as it grows, but what matters is the value of the exponent: if it is n^1.1 versus n^2, going to n=1000 means 2000 vs. 1 million, which is 50 times smaller. In one project i converted a 100k line C program into Modula-2 and it cut the size in half. So much of the differences between languages only show up on larger projects. Just like in the movie Ferrari vs. Ford, in an endurance race of 24 hours the durability of the engine really shows up. It is exceptionally hard for new languages to get an honest evaluation because typically small projects are written in them. In this regard, the Jai project has a big advantage, because it is being tested on a huge game project.