
Humanize the Craft of Building Interactive Computer Applications [pdf] - adarshaj
http://melconway.com/humanize-the-craft.pdf
======
riskable
I have a new law to go along with Conway's: Organizations or individuals that
produce content... are constrained to distribute said content in formats that
mirror the tools used to create it.

For example, a person using the Pages application on a Mac might be inclined
to distribute their writings via PDF using Mac-typical fonts utilizing Apple-
inspired layout and formatting options. You know, instead of _just making a
web page_ or using a web publishing tool.

Despite the annoying format I did read the PDF and while I like the sentiment
I can't help but think it's a lot of wishful thinking. People have been trying
to make visual programming tools (i.e. tools with real-time positive and
negative brain feedback loops) for a very long time now and they always come
up short.

Viewing the labor of programming in real-time makes sense though and I think
we can get there for a lot of use cases. Taking advantage of the web and
interpreted languages (e.g. Python) or instant-compiling languages (e.g. Go)
is probably how we'll do it.

The _opposite_ of progress in this area would be utilizing extremely verbose
languages like Java or C# or languages that require a lot of preprocessing
and/or compiling and/or complicated build and deployment processes. Java has
got to be the worst here with slow startup times, complicated and (often
extremely time-consuming) deployment processes... And that's just for the IDE!
Haha

------
dexen
I am amazed by how close LISP, or at least some dialects, comes to what the OP
asks for:

* REPL

* code/data duality

* direct manipulation of the program

* program always running and you edit the VM image, instead of editing sources and starting the program again

* ``[t]he application s user interface and a view of the application s structure sit side-by-side in front of the developer/user''

* ``[t]here is only one form of the application and there is no translator.''

~~~
bsenftner
The problem with LISP is the fact that it is only appreciated when a program's
user is both mentally sophisticated in logic in general as well as the
knowledge domain of the application. When "applied to education", many
conversations imply the education of elementary, middle, and high school level
students. The inner logical work of the most basic LISP program is simply
beyond the grasp of 99% of non-college aged students. I fail to see how LISP
can have any meaningful education impact given the student age ranges desired,
and the OP desires.

~~~
lispm
There is quite a bit of (non-university) educational use of Lisp variants in
education. See Logo and Scheme. There are lots of publications about this
topic.

------
treerock
I'd love to see the prototype he mentions. I struggle to even conceive how
something like this could work.

------
n00b101
The basic thesis here is that "an intuitive conceptual model of application
structure and a correspondingly intuitive construction process used together,
will replace conventional programming behaviors by hand-eye-brain tracking."

I think this relates to another critique of conventional programming:
"Programming today involves editing code while simulating how that code will
run in our head to ensure that program goals are met. To augment this mental
simulation, editing is periodically interrupted by bouts of debugging to get
feedback on how code really executes." [1]

I don't think that conventional programming can or should be replaced, but
there are a lot of people who are not professional programmers, but who have
other talents and creative content that they would like to produce and
distribute through computers. New approaches to programming will definitely
emerge in the future as an easier and more productive method of implementing
sophisticated custom software for domain specific tasks.

Human language is a highly effective method of communicating between complex
information between humans, but humans frequently augment natural language
with diagrams, tables plots and mathematical notation in order to communicate
complex ideas. Human languages are especially poor at expressing algorithms,
numbers and mathematical operations, which is why the number system,
mathematical notation and programming languages exist, which are all different
systems of symbols and grammars.

Programming languages are like the blueprints of a complex, abstract machine.
These abstract machines are called applications and they are very much like
physical machines, except that instead of being made using lathes, mills and
metal, they are made using compilers, IDEs, programming languages, memory,
CPUs, GPUs, etc.

No one thinks that it is a good idea to design entire physical machines using
only programming languages, between periodic bouts of running the program to
product the physical machine in order to check if it looks even remotely
correct. No other engineering discipline restricts blueprints and prototypes
to programming languages.

It is also the case that both the abstract machines (applications) and the
tools for creating then (IDEs, compilers, etc) can and do both run
concurrently on the same universal machine that is called a computer. This
means that it is not difficult at all to envision a more advanced abstract
machine building tool that improves the "hand-eye-brain" feedback loop that is
so critical to builders of physical machines. There is a growing and improving
diversity of human-computer interfaces, beyond plain text that will further
enable this possibility.

Just as diagrams and mathematical symbols can never replace human language,
programming languages will always have a ubiquitous role to play in
programming, but they will be augmented with other advanced programming
interfaces. The people who will benefit the most of form this are those who do
not think of themselves as "programmers," and who do not have any great
interest in programming, but they find themselves building, debugging and
understanding custom applications as part of their daily jobs. Those who think
that programming will never evolve beyond its current state are usually
professional programmers, who are so used to "simulating code in their heads"
that they are unaware of the problem that it poses for people in other
professions who also need to create software application in order to analyze
and solve problems in the world beyond the world of IT and programming
professionals.

[1] [http://research.microsoft.com/en-
us/people/smcdirm/liveprogr...](http://research.microsoft.com/en-
us/people/smcdirm/liveprogramming.aspx)

