Our technology - namely programming editors - restrict our thinking in many ways, so pervasive that we don't even notice.
For example, most of our PLs (Programming Languages) are constrained by our 1950's notions of what a programming editor should be.
Currently, our editors treat programs as grids of non-overlapping cells.
We put binary codes into each cell.
We arrange cells in rows and columns.
Cell must not overlap.
We call these cells characters.
Imagine if cells were allowed to overlap.
We might wish to assign an (x,y) point to each cell instead of just a (row,column).
(x,y) would be based on pixels, or vectors.
(row, column) is always based on a fixed grid.
Current programming languages are all based on the pen-and-paper-based concept of functions.
Functions get their input from parameters - all at the same time. Inputs are all delivered synchronously at the time that a function is invoked.
Functions produce all of their outputs at once - as return values. Return values are returned synchronously to the caller.
What happens if we want to return something else? We invent a kludge called exceptions.
What if our function runs forever, like a server on the internet? Uh, we force-fit the concept(s) into a restricted paradigm, using languages that can't express such concepts conveniently.
Imagine if cells were not all the same size.
We might wish to resize cells, making some cells larger than other cells.
We might wish to show the boundaries of cells.
Imagine if our editors implemented smart highlighting and elision.
Using smart highlighting coupled with diff, we could mark regions of code that were the same.
Automatic D.R.Y.[1]
Maybe we would ask our editors to clone lumps of code, making the clones read-only, or, read-write, allowing multiple views on the same piece of mutable code. Maybe we wouldn't need to bake such concepts into our languages (e.g OOP).
Maybe our smart editors would allow us to show languages using more than one syntax for each language. A write-able version, click, a read-able version. Same language. At present, we bake such ideas into the syntax of languages and bend to the whims of language designers. For example, Pascal-like languages favor write-ability, giving us constructs like if …then … else … end if - which allows syntax checkers to go to town on our code, but, we are allowed only that one syntax for the language. As another example, Lisp favors read-ability, but, every construct ends in the same way, using the character ")". This makes the code easier to read (less syntactic sugar, more to see all at once) but thwarts syntax checkers. Syntax checkers are only useful for a short while at the beginning of writing each program. Once the syntax has been checked, we might wish to turn off syntax checking and all of the syntactic sugar that makes it possible, letting us savour more of the essence of the code in one glance.[2]
We keep re-discovering the big win for programming.
Nesting.
Scoping.
Eliding detail.
The scourge of global variables was conquered using nesting, i.e. using scoped local variables.
The scourge of GOTOs was conquered using nesting. Structured Programming taught us to nest programming constructs and to not allow them to interleave.[3]
Diagrams show nesting better than text does.[4]
DaS stands for Diagrams as Syntax.
DaS is not visual programming.
DaS adds only a few extra concepts to our languages - boxes, arrows, ellipses, text.
Visual Programming seems to deal with pixels.
Dealing with pixels is hard. Dealing with only a few more graphical entities is much easier.
DaS is not Unicode. Syntactic atoms of DaS are not always the same size, not arranged on a grid, and can overlap. Unicode works with cells, grids of cells, and imposes a non-overlapping constraint on cells.
[1] DRY means Don't Repeat Yourself. A good idea for code maintenance. A poorer idea for expressing code Architecture.
[2] YMMV. You might disagree with my notion of what is readable and what is writable. That's not the point here.
[3] Structured Programming also professed the use of single-entry single-exit. We broke that rule by introducing exceptions. And, worse, we allow exceptions to be based on a runtime chain of dynamic dependencies (The Stack).
[4] Maybe we would have designed exceptions differently if we looked at diagrams of our code, instead of using grid editors.