Wouter van Oortmerssen's abstractionless programming

[Kragen Sitaker]

He's working on something that sounds identical to Bicicleta or Subtext:

>From http://strlen.com/proglang/index.html
	Horse  (apr 2005)
		generalizes the concept of a spreadsheet to aritrary
		tree structured data, but keeps the grid based view.
		Also allows more complicated computations/functions to
		be specified using the existing visual representation,
		making it into a beginner friendly graphical programming
		language.

	KNOFLOOK (oct 2004)
		A tree based graphical programming language/environment
		whose primary aim is to do away with explicit
		abstractions completely. The environment allows
		programming by cut&paste, keeping code factored
		automatically, with no need to create "functions"
		explicitly. Paper "Abstraction Considered Harmful"
		forthcoming.. :)

On 2004-06-22, he elaborated more in the Lambda the Ultimate forum, in
http://lambda-the-ultimate.org/node/17 "Abstractionless programming":

	Since this shiny new forum is rather empty, let me get the ball
	rolling...

	I have been thinking lately about ways to do programming without
	abstraction. Before you start yelling at me that this is not
	possible, don't take it too seriously, treat this as a thought
	exercise.

	My motivation is twofold:

	    - non-programmers and beginners can't deal with
	      abstractions, it is their biggest hurdle, they would
	      rather just work with concrete stuff
	    - programmers (even good ones) aren't really any good at
	      abstraction either. Being rather fanatic about abstracting
	      driven by refactoring to get the best designs myself, it
	      has become obvious to me that abstractions are a rather
	      volatile and floating target. Programmers that think they
	      create great abstractions ahead of time instead tend to
	      produce stuff that just becomes a source of problems. 

	So the idea is to have a language where it is impossible to
	create abstractions, but rather the programming environment
	continuously refactors for you as you edit (yes this is a tall
	order, bear with me). This requires a visual editing environment
	rather than a tradition source + compiler environment.

	My design sofar has you editing a tree based view of the actual
	unabstracted code. As you drag subtrees around, the environment
	marks things as shared/unshared (using a different background
	colour). This way, even functional abstraction can be created
	without the user even knowing what it is (creating a local
	change in a shared subtree is like having an argument to a
	function).

	There are a lot of mucky details, but I believe it may be
	possible to have a system that always refactors for you to have
	the optimal sharing (thus abstraction) in the background, with
	the user needing to know next to nothing. Maybe a dream, but a
	fun experiment.

	Most importantly: is there anything remotely similar to this out
	there? google wasn't particularly helpful sofar. 

(and in the comments)

Ok...

	I guess I wasn't clear about abstractions. What I was referring
	to is the predominant way of creating abstractions in most
	languages, which is creating a function (or method, predicate,
	rule, ...). Yes my designs naturally also deals with removing
	the need for temporary variables, but as Frank indicated, this
	has been done before and not that hard, given a visual
	environment. Data structure abstractions (classes, ADTs,..) are
	going to be MUCH harder to automatically refactor, I am ignoring
	them on purpose.

	Andris: I have heard of intentional programming before (on LtU
	actually, if I remember correctly :) and again it is not solving
	the problem of reducing the need for explicit abstractions.
	Really, if this:
	http://www.program-transformation.org/Transform/IntentionalProgramming
	is anything to go by, then its more like a very evolved macro
	system.

	Ehud: I disagree that abstraction is about meaning. It is
	exactly this direction in programming which I want to get rid of
	(the OOA/OOD idea of starting out with real world concepts that
	are present in your requirements, that leads to useless
	abstractions). By letting abstractions "emerge" you get much
	more meaningfull abstraction boundaries (the fact that something
	is used multiple times may actually be very meaningful). I will
	concur that it is useful to have "names" attached to large
	chunks of code, which is potentially something you'd miss out
	on.

	Frank: I am very familiar with linear logic... it is related in
	a sense: what linear logic does for runtime data structures, I
	want to do for code :) Just runtime data only deals with
	sharing, it doesn't even have constructs as "complex" as
	functional abstraction.

	Andrei: its not the same as sharing, though obviously strongly
	related.  I was merely showing increasingly complex editing
	operations that deal with shared subtrees equate to what would
	be certain forms of abstractions (functions) in normal
	languages. Working with concrete stuff means working with code
	that doesn't define abstractions, i.e.  operations on only
	concrete values... not referring to the real world here :)

	Lu Tze: that sounds really cool, I'd love to hear more... just a
	design doc or something will do, no code required. From your
	description it sounds similar to what I start with, though it
	may be that your "code" was so much a DSL that it didn't really
	require abstractions in the first place (does it create any kind
	of abstractions for the user on the fly? does it refactor them
	automatically?). My intentions are to be as close to a general
	purpose language as I can manage.

	Yes it is clear this needs another name. But I was so much
	looking forward to be able to write "Abstraction considered
	harmfull" at the top of some paper ;)

And then later:

	Yes, it is very strongly related to DRY. Trying to find the
	optimal factoring automatically makes code adhere to DRY.

	Abstractions will not be stable, but you should care less: as
	you don't have to maintain them, just be able to read them. They
	are probably more stable than you think, as the idea is not to
	"compress" the code from scratch all the time, but let user
	actions (dragging & dropping of code) be a major factor in what
	is shared and what not. It would be too messy otherwise.

	Yes, I presume FFI would be treated much like builtin functions.
	You have to start somewhere. I'd be more than happy if this idea
	work in a relative simple, protected environment, and worry
	about inter-language operability later :)

And still later:

	Darius & Frank, the idea is not find the perfect sharing in all
	cases (perfect compression), as that would indeed be difficult,
	and also probably unwanted (not all 2 copies of anything need to
	be shared, and its sometimes hard to draw the line).

	The user's editing actions (user intent) form the primary
	boundaries for the algorithm to work with. Dragging a subtree
	creates sharing. If the user however insists on creating a
	subtree from scratch that is identical to one that already
	exists, it may not be desirable to have the system make this
	shared.

	The idea is here that a completely inexperienced user can create
	code and sharing/abstractions will be created for him
	automatically, resulting in maintainable code. Learning what
	sharing means will come intuitively, and when the user becomes
	more advanced, can make use of it more explicitly. At no point
	will the factoring of the program be surprising / changing
	radically.

	The prime goal is to be able to functional abstraction
	("parametrized sharing") automatically.

This also has a link to "Managing Duplicated Code with Linked Editing",
now linked from
http://clevercs.org/index.php?module=articles&func=display&ptid=1&aid=369
to
http://www.cs.berkeley.edu/Research/Projects/harmonia/papers/toomim-linked-editing.pdf
--- abstract:

"We present Linked Editing, a novel, lightweight editor based technique
for managing duplicated source code. Linked Editing is implemented in a
prototype editor called Codelink. We argue that the use of programming
abstractions like functions and macros -- the traditional solution to
duplicated code -- has inherent cognitive costs, leading programmers to
chronically copy and paste code instead. Our user study compares
functional abstraction with Linked Editing and shows that Linked Editing
can give the benefits of abstraction with orders of magnitude decrease
in programming time."