3 ms·

What's missing in today's software is described by the field of End User Development, the ability for normal people to craft new software artifacts without the

What's missing in today's software is described by the field of End User Development, the ability for normal people to craft new software artifacts without the need to learn a formal programming language. For most people, using computers means being force-feed a selection of existing applications; and most applications are pro- consumption, which is favoured by the media companies. App stores (and the Linux repositories that preceded them) were a significant advance for the public, as they allowed common people top be able to find tools to cover their needs; previous to that, only power users were able to tune the computer to their needs. However, non-developers still depend on the capabilities put in there by the developers, and can't fine-tune their behaviour.

fauigerzigerk 9y ago
>the ability for normal people to craft new software artifacts without the need to learn a formal programming language. The problem with that is that normal people often have formal requirements that software has to meet in order to be useful. Therefore I think the secret to end-user programming is not to be less formal. It's to be less complete or less general - DSLs. But at that point you could legitimately ask whether it's programming at all or just configuration and what was actually achieved compared to the status quo.
- TuringTest 9y ago
  You're right about DSLs; they're the greatest tool for tasks that require a formal spec. The thing is, not all tasks that users engage with need a formal sspecification. For those, the ability to iterate and refine quickly is more valuable than having a precise description of every machine behaviour; I'm thing of things like page structure on Wikipedia (optional, and done with simple text markup); or the structure of documents in outlets like OneNote or Evernote, or attributes in Excel tables, which are all easy to re-arrange on the fly without needing a data schema. All my examples refer to data structure. What's missing is that kind of lightweight, optional structure for behaviour. All current software, except debuggers and unit tests, expect a fully defined program to be defined before execution. Power users need a top level loop that could execute partially specified functions over any DSL, prompting user input for the parts of the procedure not yet specified, and the capability to expand the DSLs themselves. There's nothing in the status quo like that, although environments like Hypertalk, Squeak and Excel are close, yet limited to a single DSL each.
jcelerier 9y ago
> the ability for normal people to craft new software artifacts without the need to learn a formal programming language. The problem is not programming. It's conceiving. You can get 8 years old kids to do pretty advanced imperative algorithms with scratch. What's hard is to get people to write down in a blank sheet what they actually want to do (mostly because you think you want something and then when you've got this thing you notice you actually wanted something a bit different).
- TuringTest 9y ago
  You'd be surprised the kind of people who's able to create functional applications and complex data models in my office. The point for common users to define software behaviour is doing it iteratively, with every step being based on a previous functional version.
- sbov 9y ago
  You don't need to be able to write down in a blank sheet what you actually want to do if you don't need someone else to do what you want to do. Software developers aren't special in this sense - even when writing our own software we can't do what you want. This is why "scratching your own itch" is so much easier than the alternative. You reduce the "is this what I really want?" loop by an order of magnitude by cutting out most of the people from the process.
  - TuringTest 9y ago
    > You don't need to be able to write down in a blank sheet what you actually want to do if you don't need someone else to do what you want to do. This. Why is it so hard for developers to understand this simple idea? Life in computing would be so much easier if the people building the system understood what part of their job is essential (finding out the best way to arrange hardware and software to satisfy a requirement) and which part is circumstancial, gathering a set of precise requirements to begin with. The last part wouldn't be needed if end users were able to build their own working prototypes to solve their needs, and engineers were simply called to rebuild the prototype with best engineering practices.
thomastjeffery 9y ago
I think the first step we can take toward "software artifacts" is modularization. If each piece of functionality is a discrete module, the entire platform suddenly becomes both malleable and stable. The best way to accomplish modularization is by using a functional design.
- shalabhc 9y ago
  You seem to be describing the ideas underlying smalltalk, which uses the word 'objects' instead of 'discrete modules'. Every piece of functionality is an object - any object can talk to any other objects, etc. If you're proposing something different, can you contrast your ideas with smalltalk style OOP?
  - thomastjeffery 9y ago
    I think that currently the best example of modular code is Haskell. Functions and Functors/Monads can be used to express the most elegant abstraction over data that I am aware of. In Haskell, you can write a program that uses maps/folds/etc, your program is suddenly able to use any kind of Monad-derived data type. Everything is discrete, since everything that isn't purely functional is wrapped in a Monad.
    - shalabhc 9y ago
      > most elegant abstraction over data This may be. We should also step back consider if building functional abstractions over data is a good way for modelling all of computation itself? Or something like 'smaller virtual computers all the way down' (i.e. smalltalk) is a better model? Decomposing a thing into the smaller things of the same kind seems cleaner from a certain perspective, at least. In Haskell, higher level functions can be composed from other functions, which is very clean. But the state isn't inside the function (like it is for a real computer), so it doesn't model a computer completely in my mind - it models one aspect (the transformation). Another perspective is thinking about building large scale systems and coupling of modules (how do you abstract over data from a third party library where you don't have the source code?). I kind of get smalltalk's answer here (an object scales up to become a distributable module), but I don't know if there is a good answer in a full Haskell based world. (BTW, I'm not saying one is better, I'm still thinking these things through.)

fauigerzigerk 9y ago

>the ability for normal people to craft new software artifacts without the need to learn a formal programming language. The problem with that is that normal people often have formal requirements that software has to meet in order to be useful. Therefore I think the secret to end-user programming is not to be less formal. It's to be less complete or less general - DSLs. But at that point you could legitimately ask whether it's programming at all or just configuration and what was actually achieved compared to the status quo.

TuringTest 9y ago
You're right about DSLs; they're the greatest tool for tasks that require a formal spec. The thing is, not all tasks that users engage with need a formal sspecification. For those, the ability to iterate and refine quickly is more valuable than having a precise description of every machine behaviour; I'm thing of things like page structure on Wikipedia (optional, and done with simple text markup); or the structure of documents in outlets like OneNote or Evernote, or attributes in Excel tables, which are all easy to re-arrange on the fly without needing a data schema. All my examples refer to data structure. What's missing is that kind of lightweight, optional structure for behaviour. All current software, except debuggers and unit tests, expect a fully defined program to be defined before execution. Power users need a top level loop that could execute partially specified functions over any DSL, prompting user input for the parts of the procedure not yet specified, and the capability to expand the DSLs themselves. There's nothing in the status quo like that, although environments like Hypertalk, Squeak and Excel are close, yet limited to a single DSL each.

jcelerier 9y ago

> the ability for normal people to craft new software artifacts without the need to learn a formal programming language. The problem is not programming. It's conceiving. You can get 8 years old kids to do pretty advanced imperative algorithms with scratch. What's hard is to get people to write down in a blank sheet what they actually want to do (mostly because you think you want something and then when you've got this thing you notice you actually wanted something a bit different).

TuringTest 9y ago
You'd be surprised the kind of people who's able to create functional applications and complex data models in my office. The point for common users to define software behaviour is doing it iteratively, with every step being based on a previous functional version.
sbov 9y ago
You don't need to be able to write down in a blank sheet what you actually want to do if you don't need someone else to do what you want to do. Software developers aren't special in this sense - even when writing our own software we can't do what you want. This is why "scratching your own itch" is so much easier than the alternative. You reduce the "is this what I really want?" loop by an order of magnitude by cutting out most of the people from the process.
- TuringTest 9y ago
  > You don't need to be able to write down in a blank sheet what you actually want to do if you don't need someone else to do what you want to do. This. Why is it so hard for developers to understand this simple idea? Life in computing would be so much easier if the people building the system understood what part of their job is essential (finding out the best way to arrange hardware and software to satisfy a requirement) and which part is circumstancial, gathering a set of precise requirements to begin with. The last part wouldn't be needed if end users were able to build their own working prototypes to solve their needs, and engineers were simply called to rebuild the prototype with best engineering practices.

thomastjeffery 9y ago

I think the first step we can take toward "software artifacts" is modularization. If each piece of functionality is a discrete module, the entire platform suddenly becomes both malleable and stable. The best way to accomplish modularization is by using a functional design.

shalabhc 9y ago
You seem to be describing the ideas underlying smalltalk, which uses the word 'objects' instead of 'discrete modules'. Every piece of functionality is an object - any object can talk to any other objects, etc. If you're proposing something different, can you contrast your ideas with smalltalk style OOP?
- thomastjeffery 9y ago
  I think that currently the best example of modular code is Haskell. Functions and Functors/Monads can be used to express the most elegant abstraction over data that I am aware of. In Haskell, you can write a program that uses maps/folds/etc, your program is suddenly able to use any kind of Monad-derived data type. Everything is discrete, since everything that isn't purely functional is wrapped in a Monad.
  - shalabhc 9y ago
    > most elegant abstraction over data This may be. We should also step back consider if building functional abstractions over data is a good way for modelling all of computation itself? Or something like 'smaller virtual computers all the way down' (i.e. smalltalk) is a better model? Decomposing a thing into the smaller things of the same kind seems cleaner from a certain perspective, at least. In Haskell, higher level functions can be composed from other functions, which is very clean. But the state isn't inside the function (like it is for a real computer), so it doesn't model a computer completely in my mind - it models one aspect (the transformation). Another perspective is thinking about building large scale systems and coupling of modules (how do you abstract over data from a third party library where you don't have the source code?). I kind of get smalltalk's answer here (an object scales up to become a distributable module), but I don't know if there is a good answer in a full Haskell based world. (BTW, I'm not saying one is better, I'm still thinking these things through.)