"Smalltalk failed so we can't have nice things"

[Jake Brownson]

Every time I talk about the sort of ideas that we talk about here in a more general programming forum I get this argument from people in one form or another. It's not always Smalltalk, but somebody will chime in and suggest that you're wasting your time since it's been tried before and didn't hit mainstream. Do you guys hear this argument? What is your response to it? I'm always tempted to put together a list of significant innovators and those that failed before them, but then I realize I'd be comparing myself to these great men and I don't think that's a good way to respond to it. I wind up just ignoring them as inevitably responding results in a useless flame war with them citing obscure and impenetrable academic papers. I find that the argument is generally proffered by people with big grey beards that haven't built anything interesting.

What about this:

The guys who were working on those things in the [insert decade the guy went to college in]'s weren't any less smart than we are today, and they were standing on the shoulders of some pretty great giants, but we're standing on the shoulders of the giants who were standing on their shoulders. (or something to that effect)

[Boaz Rosenan]

I totally agree.  I get this feedback often in my work.  When I try talking about projectional editing, I constantly get the feedback that it is just like structured editing, which was tried in the 70's and 80's, and did not work properly, and therefore was abandoned.  I sometimes try explaining that the world has advanced quite a bit since then, and WYSIWYG a long way since those days.  We have the Web at our side, with many emerging technologies and standards, and brand new concepts of user experience.  Our machines are faster and more responsive, our screens are bigger and more colorful, and users are getting used to new things every day.

Besides, the fact smalltalk has not gone mainstream does not mean Alan Kay and his colleagues were wrong in any way.  Same goes to LISP, Prolog, Haskell, or any other language that thinks differently than everyday's imperative OO languages.  These languages stayed in the shadows, but survived there for quite a while (LISP did that for over 50 years, and counting...), while the mainstream languages of their time (e.g., COBOL and Fortran) are (almost) unheard of these days.

I did like the argument you made, about all great inventors who had predecessors who failed.  It is not necessarily you who will be the great inventor who will succeed (and therefore, don't be afraid to use this analogy).  You may just as well fail, just like those before you. But those guys, they won't even try.  Anything they will ever invent will only be "another brick on the wall", because they are too afraid to take the risk of using something that failed once.  All great inventions were the fruit of repeated attempts.  To invent something really amazing, you need to think out of the box, but not to reinvent the wheel.  Just like Smalltalk, but better.  Just like LISP, but with 21th century technology....

--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/groups/opt_out.

[David Barbour]

Many people believe, fundamentally, that success is determined by merit, e.g. that market success is determined by technical merit. They vastly underestimate the network effects, path dependence, various market concerns. 

Further, most won't understand network effects even if you try to explain it to them. Keep in mind that there is some self-selection bias here: people who say this repeatedly are often exactly sort of people who've heard the explanation repeatedly and intentionally misunderstood or ignored it each time. But just in case you're dealing with people who haven't heard of the concepts, you should mention network effects and path dependence.

Beyond that, you should focus on arguments they're likely to understand. 

First, you can point out that their counter doesn't meet ALL the requirements. For example, with "It's been done in Smalltalk", you can point to problems in Smalltalk that hinder its use for your purposes. For me, those are:

* Smalltalk did code distribution badly, which required shipping the full IDE to ship the app, and nobody was willing to accept that

* Smalltalk did security badly. We can't integrate code from an untrusted source at runtime.

* Smalltalk did runtime update badly. Updates to code can easily break invariants and result in inconsistency. Thus, Smalltalk is unsuitable for eternal systems.

* Smalltalk did concurrency badly. Or, more precisely, Smalltalk just didn't do concurrency. Smalltalk doesn't scale the way I want it to.

* Smalltalk did UI badly. MVC doesn't support composition of heterogeneous models in open systems, and doesn't enable programming by example.

Second, you can point out what you're doing differently. For me, this might be:

* DVCS distribution of library code where that's appropriate; precise tacit concatenative bytecode otherwise

* object capability model security; elimination of ambient authority; design enforces visibility and revocability of granted authority

* externalization of state & reactive models to support update; uniqueness types to exclusively bind state to regain encapsulation

* implicit concurrency via declarative (commutative, idempotent, associative) side-effects, otherwise pure-functional computation

* reactive bi-directional views to compose models; streaming TC code to support user macros, programming-by-example 

Realistically, no number of points will convince them unless they've already explored far enough to understand them. The most frustrating problem of arguing with pretenders is "you can't understand something until you already almost know it". However, if you do this correctly, you might manage to avoid a deep argument on an irrelevant subject like giant shoulders and network effects while simultaneously seeding a few minds with problems to consider and ideas to explore, and advertising your approach. Your goal should be to help curious readers teach themselves.

(I'm really bad at this, btw. I've seen it done well, but I just never consciously think about applying it until after the argument is too far gone.)

Finally, you can point out that a lot of successes historically have been from cloning the work of others and making incremental improvements. That's something even your "but Smalltalk did it" audience can understand. It's probably their day job.

Best,

Dave

--

[Sean McDirmid]

Some guy named Ralph Johnson did this to me a couple times after talks I did in 2006/2007. 

Related work sections exist for a reason, but many people are too busy to read text, so they'll just accuse you preemptively of living under a walk. For the most part, they can be ignored. 

--

[Justin Chase]

I like to drop pithy bombs and say things like "I don't care about the way things are, I only care about the way things aught to be." and "all good ideas are bad ideas for at least 30."

People who think programming will always be done in notepad and from  command lines, simply lack vision. They are boring, don't waste your time debating them.

Sent from Windows Mail

[Sean McDirmid]

Well, Ralph Johnson is one of the core Smalltalk guys, who are the original big believers in augmented programming. The problem is that they are sure that Smalltalk got this right, and everyone else trying to do something different is either (a) not really doing something different, or (b) the different part is wrong/insignificant. Hence why they are convinced that we are all just trying to reinvent smalltalk (or Lisp Machine), and why the refuse to bother with looking at our details, because they are sure it will fall into (a) or (b).

 

Related, I got into a more intelligent discussion with Gilad  Bracha (another big Smalltalk guy) on Google+ (can’t access right now) that can illustrate this point. Live programming in Smalltalk means two things: (1) fix and continue, which is not very responsive if the code you are editing is not continuously re-executing, and (2) the ability to change objects directly while the program is running, but there is no record of those changes outside of your persistent image. My version of live programming is that you edit the code, program execution is repaired retroactively; the code you are then left with is persistent by itself (no need to save an image). Now Gilad’s criticism is insightful and not trollish: he claims that my view of live programming is too idealistic vs. the more pragmatic smalltalk approach; and he might be right, but I’ll try to prove him wrong J.

[Sjoerd de Vries]

On Friday, October 25, 2013, Sean McDirmid <smc...@microsoft.com> wrote:
> Related, I got into a more intelligent discussion with Gilad  Bracha (another big Smalltalk guy) on Google+ (can’t access right now) that can illustrate this point. Live programming in Smalltalk means two things: (1) fix and continue, which is not very responsive if the code you are editing is not continuously re-executing, and (2) the ability to change objects directly while the program is running, but there is no record of those changes outside of your persistent image. My version of live programming is that you edit the code, program execution is repaired retroactively; the code you are then left with is persistent by itself (no need to save an image). Now Gilad’s criticism is insightful and not trollish: he claims that my view of live programming is too idealistic vs. the more pragmatic smalltalk approach; and he might be right, but I’ll try to prove him wrong J.
>

I have had exactly the same discussion with a live programming proponent. It's time travel, that's the problem. 'self.kill_grandfather()', anyone?
I would like a smart IDE that caches so that restarting a program is *fast*. But I wouldn't call that live programming.

Cheers,

Sjoerd

[Sean McDirmid]

If you just have fast restart, you lose all your state. If you record your events and play them back, then better...but eventually you'll have to dip into incremental computation for a decent experience.

Sent from my Windows Phone

---

From: Sjoerd de Vries
Sent: ‎10/‎25/‎2013 14:43

[Sjoerd de Vries]

On Friday, October 25, 2013, Sean McDirmid <smc...@microsoft.com> wrote:
> If you just have fast restart, you lose all your state. If you record your events and play them back, then better...but eventually you'll have to dip into incremental computation for a decent experience.

Indeed, 'smart' as in 'minimizing the amount of recomputation'.
But the problem is, live programmers like to understand the new runtime situation in terms of the old one (plus the change that they just made). With retroactive changes (time travel), a relation between the two is not guaranteed. I am OK with that, but I wouldn't claim it to be 'live programming'.

>
> Sent from my Windows Phone
> ________________________________
> From: Sjoerd de Vries

> Sent: 10/25/2013 14:43

[Sean McDirmid]

We have different ideas about live programming. There is Hancock's and tanimoto's floating around right now. Hancock's doesn't specify tine travel, but requires that feedback be comprehensible (steady frame); abstracting over time as a spatial (or two way) dimension is the way I've decided to achieve this.

Smalltalk provides a bunch of great features for manipulating programs but not concrete usability features, which is probably why it has languished and is under appreciated. Hancock avoids this trap in his dissertation, tanimoto's definition doesn't

Sent from my Windows Phone

---

From: Sjoerd de Vries

Sent: ‎10/‎25/‎2013 15:21

[Sjoerd de Vries]

I stand corrected. 'Live programming' as in 'live code editing' is perfectly possible, and may also regenerate some of the new runtime state, using the techniques you describe (and you have much more expertise on them than I have). I hope that this definition of 'live programming' will prevail, and I fully support it.

I was under the impression that 'live programming' was to be strictly understood in the Smalltalk sense of direct runtime state manipulation, and that the 'idealistic' view consisted of translating these manipulations *also* into live retroactive code edits.

I did some reading based on what you wrote. If I understand correctly (and please correct me if I do not), Tanimoto level 3 is live code editing. The *additional* features of level 4 are Smalltalk live programming. Level 4 as a whole would be the 'idealistic' view that synthesizes both. I don't see how it is possible, though.

On Oct 25, 2013 9:50 AM, "Sean McDirmid" <smc...@microsoft.com> wrote:
>
> We have different ideas about live programming. There is Hancock's and tanimoto's floating around right now. Hancock's doesn't specify tine travel, but requires that feedback be comprehensible (steady frame); abstracting over time as a spatial (or two way) dimension is the way I've decided to achieve this.
>
> Smalltalk provides a bunch of great features for manipulating programs but not concrete usability features, which is probably why it has languished and is under appreciated. Hancock avoids this trap in his dissertation, tanimoto's definition doesn't
>
> Sent from my Windows Phone
> ________________________________
> From: Sjoerd de Vries

> Sent: 10/25/2013 15:21

[Jonathan Edwards]

I get this all the time. Most people only notice what they already understand, so they don't notice new ideas. You have to bang them over the head with what is new. You need a slide saying exactly why this is not the same old thing. Exacerbating this normal tendency is the fact that there are almost never any new ideas in programming. For decades it has been the same old ideas over and over again. So people should be forgiven for assuming there aren't actually any new ideas to be had. The Smalltalkers are the worst because their language actually invented many of the ideas that everyone has been copying for decades.

--

[Jake Brownson]

> I get this all the time. Most people only notice what they already understand, so they don't notice new ideas.

That's very well put.

> So people should be forgiven for assuming there aren't actually any new ideas to be had.

I can forgive people for that assumption, but I don't really
understand the attitude that leads them from "the thing you're doing
isn't new" to "you shouldn't be doing it". Even if they're right that
it isn't new.

If I had invented and built something 20 years ago that had a bunch of
really nifty ideas that were perhaps even ahead of their time and 20
years later I ran into someone who thought the ideas were great and
was still working on something related to them I would be ecstatic and
encourage them to keep pushing. I wouldn't ever use my energy to try
to convince someone to stop working on something. Everyone builds
"Hello World" as their first program. Why don't these guys stand
around and say "You're wasting your time, that was done 100 years
ago". One thing leads to another and maybe we have to start w/ a bit
of the old to get to the new.

[Sean McDirmid]

I don’t find Tanimoto’s level of liveness very useful: they specify some specified technology level without considering the user experience. I much prefer Christopher Hancock’s goal of understanding and manipulating program execution in a steady frame.

 

Live programming is a term the smalltalk community has latched on to describe something quite different (direct manipulation actually); it took me awhile to realize they were referring to that and not fix and continue (hot code replacement). I made this clear from my first live programming paper, but through comparing with Maloney/Smith’s Morphic work (you can modify the morph “live”, but good luck getting that back in code!).

[Sean McDirmid]

The older and more grizzled you get, the more your ideas have been ignored in the past, the less you will believe in new newness. And actually, it's a reasonable filter that is true 80% of the time.

-----Original Message-----
From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of Jake Brownson
Sent: Friday, October 25, 2013 10:59 PM
To: augmented-...@googlegroups.com
Subject: Re: "Smalltalk failed so we can't have nice things"

[Jonathan Edwards]

The jaded old Smalltalkers are not my biggest problem. The big problem is all the hotshot expert programmers and academics that are so satisfied with themselves and the state of the art. At least the Smalltalkers can see what a giant pyramid of shit modern programming has become. It is the experts that have a vested interest in the status quo and will do everything they can to protect it, both consciously and subconsciously. I have come to the conclusion that it is impossible to win the experts over. We can only improve programming by bypassing the experts and appealing directly to beginners and amateurs. I would call this "disrupting programming" except that Silicon Valley has utterly prostituted the disruption idea.

[Sjoerd de Vries]

On Saturday, October 26, 2013, Sean McDirmid wrote:

I don’t find Tanimoto’s level of liveness very useful: they specify some specified technology level without considering the user experience. I much prefer Christopher Hancock’s goal of understanding and manipulating program execution in a steady frame.

 

I have read your discussion with yaxu on Hancock on LtU and it still very much confuses me. As I see it, a feedback loop consists of two parts, one of which is fairly easy (code to runtime), while the other one is hard (runtime to code), leading to round-trip inconsistencies (old runtime => manipulation => new code => new runtime, with no guaranteed relationship between old runtime and new runtime). I can't see what Hancock's realtime programming experience has to do with it, other than the desirability of making the feedback loop fast.

 

Live programming is a term the smalltalk community has latched on to describe something quite different (direct manipulation actually); it took me awhile to realize they were referring to that and not fix and continue (hot code replacement). I made this clear from my first live programming paper, but through comparing with Maloney/Smith’s Morphic work (you can modify the morph “live”, but good luck getting that back in code!).

 

Even the term 'fix and continue' is ambiguous. One can use gdb to fix runtime values non-persistently and continue, but that is not live code editing. Programmers of languages without mutable primitives (e.g. Python) may not even know the term, or auto-assume the gdb meaning. I am not familiar enough with Smalltalk in that regard, but I suspect that this kind of misunderstanding wastes many good discussions. Some kind of terminology dictionary would be very useful.

Cheers

Sjoerd

 

--