On Friday, 13 May 2016 at 22:13:50 UTC, QAston wrote:
Mainstream PL syntax is extremely unintuitive and poorly
designed by known pedagogical, epistemological, and
communicative science standards. The vast majority people who
are introduced to programming do not pursue it (likely true of
many fields, but programming may see a smaller grab than most
– this point requires a lot more context). I'm open to the
possibility that the need to master the bizarre syntax of
incumbent programming languages might serve as a useful filter
for qualities valuable in a programmer, but I'm not sure how
good or precise the filter is.
Your research seems to have a very big ommission: textual
representation is not only representation of programs -
therfore programming doesn't have to have syntax. The first
programming enviroment I was introduced to was an executable
flowchart enviroment.
Quick note: I'm looking at the effects of the syntax and design
of incumbent programming languages on the appeal of programming
to people in general, with some specific questions concerning the
appeal of programming to women (particularly elite women who have
many career options.)
So that research track is bound to the world as I find it, and
the world as I find it is a world where graphical programming
languages and environments are not widely used, and where all the
programming languages in wide use are plain text.
That said, I'm deeply interested in graphical and visual
programming methods. I know quite a bit about them, have studied
lots of historic efforts and even contemporary ones like Snap
(http://snap.berkeley.edu/) and Scratch. Side note: I'm a bit of
a Russophile, and I'm fascinated by the history of Soviet
computing, with innovations like the Elbrus systems with tagged
memory, and the ways they cloned major American computing
platforms. Something I dug into last year is the DRAKON graphical
programming language, which they built as part of the Buran space
shuttle program. Very interesting:
https://en.wikipedia.org/wiki/DRAKON
Programmers tend to be conservative in many respects. There's the
assumption that programming must consist of a programmer typing
plain text into a flat document that contains many levels of
abstraction and many different kinds of concepts. By flat I mean
that it's this continuous blob that takes no account of its
content, of varying levels of abstraction, of the wildly
different kinds of work and reasoning that are expressed in this
run-on text file. Then a compiler takes this text and does its
thing. There's very little visual representation. Type systems
are quite arbitrary and primitive -- we could've moved to
real-world types a long time ago, which would be much safer and a
hell of a lot more productive. Type theory imports the barbarism
of legacy type systems and doesn't question the assumption that
the universe is best carved into ints and floats at the source
code level, instead of prices, km, or seconds. Compilers still
don't know that something called lastName is a string (or better
yet, a *text* type -- strings are for yo-yos), or that salesTax
is a decimal. That's really simple stuff. It's nuts that with
semantic names we still have to assign types, and that those
types are so much coarser than the information already in the
name. Our vaunted notion of type safety is based on an incredibly
coarse split between ints, floats, and maybe strings or arrays. I
think it should confuse every CS student how these distinctions
came to preoccupy us, and why we don't have anything more to say
about types at this point in history.
So graphical programming is a huge change for a very conservative
field, and probably has worse than "script kiddie" connotations
for many professional programmers. And there's no compelling
evidence that graphical is better than text for many use cases.
It might be better for some people, and a one-to-one mapping
between a powerful textual PL and a graphical form would be very
interesting.
