4 ms·

This is called 'End User Development' or 'End user Programming'. There is a book called 'A Small Matter of Programming' by Bonnie Nardi on this, which is worth

by brodo 6y ago

This is called 'End User Development' or 'End user Programming'. There is a book called 'A Small Matter of Programming' by Bonnie Nardi on this, which is worth a read. My point of view is that everyone who wants to do something like this needs to be able of computational thinking and willing to use these tools. Most people are neither. Moreover, most complexity in software engineering today is due to market forces and legacy systems. Think about why we have Javascript. Think about COBOL systems running half of the banking world. I don't see these going away any time soon.

goatlover 6y ago
Cobol was designed so that business people could program it. Then there was Basic, Smalltalk, spreadsheets, office suites, Lotus Notes, Hypercard, Visual Basic, Flash and the web used to be something simple enough anyone could whip a simple page or website together. But now we have Wordpress and Wix. It doesn't seem like any of that has diminished the demand for software professionals.
lioeters 6y ago
Thanks for the book recommendation. I've found related info, it's on my reading list now. https://mitpress.mit.edu/books/small-matter-programming https://mitpress.mit.edu/books/small-matter-programming https://en.wikipedia.org/wiki/Small_matter_of_programming https://en.wikipedia.org/wiki/Small_matter_of_programming I've long been a fan of end-user programming, and have promoted it in the form of domain-specific languages and visual building of logic. I love that it gives "non-programmer" users the power to (try to) build what they imagine, and have seen it lead to valuable prototypes and successful tools/products/services. On the other hand, I've come to learn that this is still a form of programming, however higher a layer of abstraction. Users who attempt a complex problem space will sooner or later run into what experienced programmers deal with every day, the challenge of organizing thought and software. What typically happens is, as the "non-program" grows larger and more complex, eventually it starts pushing the limits of the abstraction, either of the user's capacity or the system's. That's when they call in a "real" programmer, to get in there and patch up the leaky abstraction, or convert the prototype into actual software in a better-suited language. I still think low- or no-code programming environments have a lot of potential to change what software means to people, particularly by blurring the boundary between software development as we know it, and forms of "intuitive computing" like putting together mental Lego blocks.

by brodo 6y ago

goatlover 6y ago

Cobol was designed so that business people could program it. Then there was Basic, Smalltalk, spreadsheets, office suites, Lotus Notes, Hypercard, Visual Basic, Flash and the web used to be something simple enough anyone could whip a simple page or website together. But now we have Wordpress and Wix. It doesn't seem like any of that has diminished the demand for software professionals.

lioeters 6y ago

Thanks for the book recommendation. I've found related info, it's on my reading list now. https://mitpress.mit.edu/books/small-matter-programming https://mitpress.mit.edu/books/small-matter-programming https://en.wikipedia.org/wiki/Small_matter_of_programming https://en.wikipedia.org/wiki/Small_matter_of_programming I've long been a fan of end-user programming, and have promoted it in the form of domain-specific languages and visual building of logic. I love that it gives "non-programmer" users the power to (try to) build what they imagine, and have seen it lead to valuable prototypes and successful tools/products/services. On the other hand, I've come to learn that this is still a form of programming, however higher a layer of abstraction. Users who attempt a complex problem space will sooner or later run into what experienced programmers deal with every day, the challenge of organizing thought and software. What typically happens is, as the "non-program" grows larger and more complex, eventually it starts pushing the limits of the abstraction, either of the user's capacity or the system's. That's when they call in a "real" programmer, to get in there and patch up the leaky abstraction, or convert the prototype into actual software in a better-suited language. I still think low- or no-code programming environments have a lot of potential to change what software means to people, particularly by blurring the boundary between software development as we know it, and forms of "intuitive computing" like putting together mental Lego blocks.