
Programming Considered as a Human Activity (1965) - slbenfica
http://fermatslibrary.com/s/programming-considered-as-a-human-activity#email-newsletter
======
Mathnerd314
> In all cases however, the program without the goto statements turned out to
> shorter and more lucid

This was with ALGOL though; Haskell uses lambdas and is shorter still. I feel
like Scheme / callcc might be even shorter. And the difference between callcc
and goto is not at all clear.

To be fair, though, he does mention the human-computer interface.
Unfortunately this has still not really been explored in the context of
programming. There are toy environments like Light Table etc., and the more
developed languages come with IDEs, but nobody seems to use them in practice,
preferring vim or emacs or whatever.

My guess for this is that writing GUIs in an extensible, modular, and
discoverable/usable way is still an open problem. There are style guidelines,
e.g. [https://www.smashingmagazine.com/2016/06/designing-
modular-u...](https://www.smashingmagazine.com/2016/06/designing-modular-ui-
systems-via-style-guide-driven-development/), but those aren't code and don't
fit into an Agile-style incremental development model. The only thing that
seems usable are constraint layouts, e.g.
[http://ieeexplore.ieee.org/document/4483218/](http://ieeexplore.ieee.org/document/4483218/).
But those don't account for all the little UI things, like the efficiency of
the interface or which actions are most commonly used. IMO there needs to be
some library to just take a bunch of actions/verbs (e.g. Copy to clipboard)
and nouns (displayable data stuctures: images, documents, etc.) and turn that
into an optimized user interface design, with keybindings, menus, toolbars,
dialogs, widgets, etc. And then of course there's the issue that picking a GUI
pretty much fixes your choice of programming language, away from any of the
functional PL's.

~~~
Retric
IMO text is actually a great way to interface with computers, because the core
problem is reading code not writing it. Further, people have decades of
practice in reading / interpreting text and writing in a linear format which
lowers the mental overhead.

As to GUI builders their are a lot of them however people tend to design for
the screen they use which creates almost as many problems as it fixes.
Further, that's rarely the 'hard' part of the design even when you have them
using a good text based abstraction is often more productive especially in
terms of diff tools and version control.

~~~
Mathnerd314
> the core problem is reading code

Modern codebases are thousands or millions lines of code. Nobody has the time,
inclination, or ability to read/learn all of it. So a lot of coding ends up
being revisiting old design decisions and searching for the relevant parts of
the code. See e.g. [https://air.mozilla.org/the-joy-of-coding-
episode-93/](https://air.mozilla.org/the-joy-of-coding-episode-93/), he has 10
tabs open and spends a significant fraction of time just switching between
them.

> GUI builders

Pretty much all GUI builders are WYSIWYG or markup languages. As I mentioned,
I want something declarative: define the verbs and the nouns, guesstimate a
usage frequency of the various parts, and generate a UI, without specifying
minor details like combobox vs text field. Something like
[https://blog.mozilla.org/ux/2013/04/firefox-next-evolving-
th...](https://blog.mozilla.org/ux/2013/04/firefox-next-evolving-the-user-
interface-using-genetic-algorithms/) (Note April 1 date)

