Bret Victor - Inventing on Principle
Damien Lepage
Cedric Greevey
> Hi Everyone,
>
> You may have seen this already, if not I believe it's worth investing 1h of
> your life:
> http://vimeo.com/36579366
>
> That's already a good candidate for the technical talk of the year, if not
> the decade IMO.
What is it with people these days and using videos for stuff that
could be far better posted as text?
A "talk" can inherently be presented as text, perhaps HTML with a few
inline images if there are slides.
And text (or HTML) has some HUGE advantages:
* Download size is kilobytes, not gigabytes
* Can be viewed on dialup, mobile, etc. without stuttering, not
working at all, costing an arm and a leg, or etc.
* Google can find it by the full content of the talk, not just what
few keywords someone slaps onto the video's youtube page plus the
inanities added by the inevitable swarm of troll commenters.
* You can search in it yourself with ctrl-F in your browser.
* You can skim it.
* If you're a fast reader, you can probably read it and comprehend
it all in less than an hour.
* You can navigate in it very easily, using normal scrolling, search,
and other browser tools, and see where you're going while you
scroll, rather than having to drag a tiny little thingy across a
tiny little seek bar blind, drop it, and then wait 40 seconds while
a little wheel spins for the Flash player to *maybe* jump to the
spot in the video, whereupon you will repeat the process a few
times with ever finer adjustments; but the player might hang
or snap back to where it was or crash instead.
* You can keep a copy for offline viewing without needing:
a) hacking tools to bypass the attempts by the popular video
sites to be streaming-only,
b) one or another big bloated piece of media player software that
will steal file associations at inconvenient and random times,
and
c) a shitload of disk space.
* No extra plugins etc. needed to view it that guzzle CPU and
memory, crash at inconvenient times, and the like. You can view
it in Lynx (minus the slides, if any) if you want to. You can
view it on a 286 with no graphics card (not no 3D card, no
graphics, period, just 80x24 text mode). You can view it on your
old Commodore 64 with 300 baud modem if you want to and it won't
take sixty thousand years to download on that either.
* You can copy and paste bits of it into a snippets file or
whatever, if there's bits you want to refer back to later that
gave you technical ideas. Or print it out and apply hiliter to
key passages. Or etc.
* If you're blind you can still get screen-reader software to
read it for you. If you're deaf, on the other hand, a video is
quite likely to be completely useless, since streaming framerates
and lip-reading don't tend to mix and none of these things seem
to be closed-captioned.
* Text is easy and cheap to mirror widely around the net and
relatively easy to translate to other languages. Video can be
hosted free at only a handful of sites and is more work to
translate.
What does video get you that text or HTML+images couldn't get you?
* You can hear what the guy's voice actually sounds like.
* You get to see a talking head bobbing around and lips moving in
a jerky, stuttery sort of way.
* You get the pronunciation, but not the spelling, of the obscure
technical/latin words that get used, instead of the other way
'round.
* There can be full-motion video demonstrations of things.
Not worth what you lose, IMO, even if you aren't deaf, and especially
if you are. Full-motion video demonstrations can be separate short
videos embedded in a text+images web page.
Oh, and by the way, your post doesn't even bother to actually say
what, exactly, the talk is about. It implies strongly that it has
something to do with interactive development tools, and it's clear
that something in it wowed you, but that's it, and the URL itself is
completely opaque. Apparently the only way to find out in more detail
what the talk's topic is is to click the link, at minimum, and maybe
you even have to play the video part-way.
gaz jones
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Cedric Greevey
> Are you Ken Wesson with a new account?
Who?
Wait. Surely you don't think that it's not possible for more than one
person to prefer text to video as a way of disseminating verbal
information over the internet, given all of text's advantages in such
areas as bandwidth, cost, and tool support?
Marco Abis
watching the video would answer the question and would have probably
taken you less time than writing this email...
> Not worth what you lose, IMO
how can you know if you haven't watched the video?
--
Marco Abis
Cedric Greevey
>> What does video get you that text or HTML+images couldn't get you?
>
> watching the video would answer the question and would have probably
> taken you less time than writing this email...
Actually, it would have taken an hour, and writing the email took much less.
>> Not worth what you lose, IMO
>
> how can you know if you haven't watched the video?
Because it was described as "a talk". That means the bulk of the
actually meaningful content in it comes from someone's lips flapping.
That can be rendered as text, easily. If there are slides, ... but
I've already been over all of that.
gaz jones
seen type an essay about it on this forum in reply to someone posting
a link to a video. also, he posts and yours are very similar and he
disappeared shortly before you arrived. AND YOU WOULD HAVE GOT AWAY
WITH IT IF IT WASNT FOR THOSE MEDDLING KIDS!!
Marco Abis
> Actually, it would have taken an hour, and writing the email took much less.
...
> Because it was described as "a talk". That means the bulk of the
> actually meaningful content in it comes from someone's lips flapping.
> That can be rendered as text, easily. If there are slides, ... but
> I've already been over all of that.
you are wrong, watch the video first
--
Marco Abis
Cedric Greevey
> First: sorry, my reply was meant to be sent to you only, not the list
>> actually meaningful content in it comes from someone's lips flapping.
>> That can be rendered as text, easily. If there are slides, ... but
>> I've already been over all of that.
>
> you are wrong,
No, I am *not* wrong. A talk can be translated into text+embeds with
very little or nothing being lost, almost by definition.
It might be the case that the OP was wrong when he described the video
in question as "a talk", but that's a completely different matter.
Regardless, I highly doubt that there's anywhere close to 60 minutes
of video in there that couldn't be better presented in some other way.
Most likely, it would be better as text and a few short video
segments, the latter adding up to much less than 60 minutes in
duration.
> watch the video
No. A full hour is way, way too long for something analogous to a blog
post or a mailing list message, and I have lots of other demands on my
time.
(As for gaz's conspiracy theory, I won't even dignify that with a
separate response.)
Jay Fields
Surely it's possible that you've never heard of Ken Wesson, he
disappeared right before you joined, you respond to emails in the same
manner, you share the same opinions. Seems legit, Ken.
Mark Rathwell
If it is you, Ken, welcome back ;) I'm no doubt in the minority, but
I've actually kind of missed your postings.
Cedric Greevey
OK. I googled the group archives. Seems there was a Ken Wesson active
on the list for a while, but he disappeared a couple of months before
I joined. I'm not sure why people think I might be him.
Devin Walters
'(Devin Walters)
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com (mailto:clo...@googlegroups.com)
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com (mailto:clojure+u...@googlegroups.com)
Daniel E. Renfer
Ken Wesson was noted for having strong opinions as was a noted hater of
videos where text will do.
https://groups.google.com/d/msg/clojure/0kCwGrFU5zs/NGclkY46fvEJ
Timothy Baldridge
it. This guy has some pretty mind-blowing demos. I highly recommend
this, I'm going to have to sit down soon and code up a clone of his
"binary search tree" demo.
Timothy
Cedric Greevey
Most of us on this list probably have strong opinions -- it tends to
go with the territory of being smarter than the average bear. As for
hating videos where text will do, need I repeat my list of bullet
points again? It's quite *obvious*. It's no more surprising for
multiple techies to find videos-where-text-will-do to be a troubling
trend than for techies to find that Lisps and even Algols are nicer
languages to program large systems in than Visual Basic. :) Especially
since we techies are very used to using search tools and other things
specifically geared around finding *text*, and often have multiple
devices including mobile where bandwidth costs can quickly become
exorbitant.
Andy Fingerhut
I've done that for one of Rich's earlier talks posted as video. It takes time, and I'm not volunteering for this one.
Andy
Softaddicts
BTWY, what was the initial subject of this thread ?
I'm half-joking here, welcome back Mr Wesson.
:))))
Mr Smith
--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail!
Damien Lepage
Michael Gardner
> Ken Wesson was noted for having strong opinions as was a noted hater of
> videos where text will do.
He was also the only guy who would post replies with just "you're welcome" as the body. Until Cedric, that is...
Laurent PETIT
Envoyé de mon iPhone
Hi Everyone,You may have seen this already, if not I believe it's worth investing 1h of your life:That's already a good candidate for the technical talk of the year, if not the decade IMO.Ok, I'm getting a bit too enthusiastic here but this is so inspiring.After watching it, you can't help thinking that we have a whole new world to invent.As a side note, you may start thinking that a REPL is not good enough.- Personal message to Laurent Petit: please watch and start thinking about CCW 1.0 ;o) -
It also feels like ClojureScript is on the right path.But, most importantly, beyond any technical consideration, the last part is a great life lesson.
Stuart Halloway
Raju Bitter
and the stuff he has been doing for some time.
Bret has built some very impressive UIs using OpenLaszlo, and he is a
fan of the technology and the expressiveness of the LZX language for
building UIs. OpenLaszlo was created by bunch of smart folks and
Lispers, including Oliver Steele (worked for Apple on Dylan), Max
Carlson, Tucker Withington (worked for Symbolics and Harlequin,
implemented the GC for Dylan when Apple hired Harlequin to work on the
language), and Henry Minsky (Marvin Minsky's son).
http://osteele.com/
http://pt.withy.org/
Here's an old gestural zoom/pan demo Bret built with OpenLaszlo:
http://worrydream.com/GesturalZoomAndPan/
OpenLaszlo's LZX language uses a declarative approach to building UIs
and highly interactive applications (check this video of the Laszlo
Dashboard, which was created in 2002/2003 http://vimeo.com/14206607).
LZX is a mixture of XML tags + JavaScript, which initially was
compiled into SWF bytecode. In 2007 Laszlo added cross-compilation to
JavaScript (DHTML runtime) to the platform, and in 2009
cross-compilation to ActionScript 3 (which is then compiled into SWF
using the Flex SDK).
Here's a video of the LzPix application, the first OpenLaszlo app to
cross-compile to JavaScript
http://vimeo.com/32853986
My technology dream-team for client development would be ClojureScript
combined with OpenLaszlo (has a powerful view kernel with interesting
stuff like constraints, datapath mapping using xpath, simple yet
powerful animation APIs). Instead of using XML + JavaScript, I'd
prefer to use a more Clojure/Lisp like syntax to build UIs with
OpenLaszlo in combination with ClojureScript. There's a slight chance
that we can get the OpenLaszlo Lisp folks interested in integrating
OpenLaszlo with ClojureScript (they are all working at Nest Labs now),
and I'm sure that Bret Victor would love the combination as a tool for
building some awesome prototypes.
- Raju
David Nolen
kovas boguta
an immediate connection to their creation.
I realized this has also been my side project for the last few months,
though mostly in "hammock phase".
I think the foundational technology we need, as a community, is an
"html5 repl". You type code into the browser, and can create output
that takes advantage of the host's capabilities - graphics, video, UI
etc.
The problem is a bit more multifaceted then just html though, as it
also involves UI state, persisting the sessions, how to share/reuse
the creations, and the general problem of UI description in the
context of clojurescript.
But where this gets you is this: a clojure interaction environment
based on web standards, rather than narrow dialects like elisp and
swing. So the lines between programming clojure, extending the clojure
programming environment, and deploying webapps goes away. It's
possible to see a line between this category of tool, and the demos in
the presentation.
If the game is tightly coupling data, code, and complex visual
representation, we have the building blocks to bust that game wide
open. It makes no sense to build on a platform other than the web, and
IMHO the big step there is to program clojure from the web, to produce
fully-active web content.
Another aspect of immediate connection, and one not mentioned in the
talk, is the social aspect. You make things, and show them to people,
get feedback, see things others have made. Now imagine if the clojure
community was creating in a system that is inherently web based. Many
interesting things could be built on that.
On Fri, Feb 24, 2012 at 4:27 PM, Raju Bitter <rajub...@googlemail.com> wrote:
Stefan Kamphausen
this video showed up on my G+ stream about a week ago and it was /fun/ to watch.
I think most of the people around here will be more intrigued by the first half, which has a focus on programming.
Side-note: this is one of the (few) video presentations that just can't be translated to text. Wait for the slider in the browser game...
However, I digress...
Am Freitag, 24. Februar 2012 21:34:54 UTC+1 schrieb lpetit:
Hello Damien, I had already watched the first half of the talk.I found the live demonstrations rather impressive, indeed. I've since wondered how this could be generalized,
I may be wrong, but I as far as I understand the message of the video it is explicitly not about generalization. It's more about finding a niche of programming where you can make the experience of the person doing things more direct. Thus, I'd rather consider the particular situation of a person doing UI-stuff with seesaw or doing web-stuff with ring and friends or whatever, the direct thing. I think Overtone does a lot right from this point of view.
But then again, the niche may be programmers writing pure functions and the example of the video may apply.
After all this has been said, of course I may have misunderstood your remark about generalization, Laurent.
Kind regards,
Stefan
Chas Emerick
Anyway, nREPL has developed to the point where middlewares can be written to easily offer richer representations of data within the REPL. An example of my earliest (primitive!) experiments around this are available here[2]. Images and other data flowing through a REPL isn't a _huge_ deal, except that:
* nREPL is tool-agnostic; reply (and therefore Leiningen v2) or vimclojure or jark or textmate or sublime text can elect to receive those other representations, and present them to the user however is appropriate
* nREPL is transport-agnostic; the default socket transport (bencode[3] with some particular semantics) is very lightweight, and can receive or transmit binary data efficiently (a distinct advantage compared to shipping textual encodings of such data in e.g. s-expressions).
A proof of concept of a tty transport is included in nREPL (so you could connect to an nREPL backend using something as meager as telnet), and I have a sketch of an nREPL ring handler that I'll get out on github soon. This should allow you to easily drop an nREPL endpoint into any ring app, connect to it with any HTTP or nREPL client, and do anything you'd like to do in a REPL without tunneling, mucking around with ssh tunnels, and taking advantage of all existing webapp security regime you have in place. And, if you have the right middlewares in place and a suitably-capable client, rich representations of REPL data and rich interactions with the same should be within arm's reach.
I have less of a vision for the HTML5 side of things. I'm certain a killer in-browser nREPL client could be put together to take advantage of all of the above, whether it's connecting to an HTTP nREPL endpoint or a (web)socket transport using nREPL's wire protocol, but I'm personally more interested on "thick clients" (perhaps embedding webviews as necessary!) for various reasons.
FYI, for anyone working on tooling to help support things like this, I'd invite you to join the clojure-tools group I created recently:
http://groups.google.com/group/clojure-tools/browse_thread/thread/48ff47ab5d7ca2c?hl=en
Cheers,
- Chas
[1] http://github.com/clojure/tools.nrepl
[2] http://cemerick.com/2011/10/26/enabling-richer-interactions-in-the-clojure-repl/
[3] It turns out that bencode and the way nREPL uses it seems similar to but much simpler than Google's SPDY protocol.
Sam Ritchie
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Raju Bitter
it. Visualizing code in such a way is amazing, could be extremely
useful when teaching how to program.
I think the browser-connected REPL in ClojureScript is already a good
step into the right direction, since it makes testing changes to the
code for visual effects A LOT easier. When I did a bit of Flex
development back in 2008 the application took 6 minutes to compile,
which meant a huge waste of time trying to improve UI effects. I've
heard of people who had compile times of up to 12-15 minutes for their
Flex apps. Imagine how much time you waste with such a workflow
(although that's more the case for very large enterpise apps, and not
a casual game).
Thanks again for the link!
- Raju
Phil Hagelberg
> Didn't have the time to watch thevideo yesterday, and just watched
> it. Visualizing code in such a way is amazing, could be extremely
> useful when teaching how to program.
Yes, what a great object lesson in the usefulness of being able to
disable locals clearing. Gave me a lot to think about regarding what
kind of feedback tools should provide.
It's funny to hear a half-hour talk on Cybernetics without mentioning
the term at all, but I'm glad the ideas are getting exposure.
-Phil
Craig Brozefsky
> Yes, what a great object lesson in the usefulness of being able to
> disable locals clearing. Gave me a lot to think about regarding what
> kind of feedback tools should provide.
I don't understand what "disable locals clearing" means.
--
Craig Brozefsky <cr...@red-bean.com>
Premature reification is the root of all evil
kovas boguta
In terms of images etc, I see these as resources that are referenced
by the expressions going over the wire, rather than embedded in the
expressions directly. You can just send the url to the image (or data
later turned into a url), and then the resource is loaded in the
browser via http.
Continuing my html5 repl rationale at
http://groups.google.com/group/clojure-tools/browse_thread/thread/f0ef25f5489b4554?hl=en
cameron
it was interesting that the binary search example only really works
with pure functions since you must specify all of the initial state
for the debugger/visualiser.
In non-pure functions (and oo) the user is unlikely to be able to
specify valid values for all the mutable state even if the application
could tell them which variables were being referenced.
In clojure something like this might not be too difficult, perhaps we
could:
- define a temporary function with the same text
- use CDT or another debugger to set a break-point in the temporary
function
- call the function and capture the current stack frame variables at
each invocation & display as in the video
Support for higher order functions and list comprehension (map,
reduce, for, etc.) may be difficult though.
Phil Hagelberg
>> Yes, what a great object lesson in the usefulness of being able to
>> disable locals clearing. Gave me a lot to think about regarding what
>> kind of feedback tools should provide.
>
> I don't understand what "disable locals clearing" means.
In order to avoid memory leaks when dealing with lazy seqs, Clojure's
compiler must emit instructions to clear references to locals so they
can be GC'd. This is necessary in production but severely cripples
debuggers since they only have access to locals that haven't been
cleared. It would also probably be necessary for this kind of live
tracing.
There's a patch that fixes this problem waiting to be applied:
http://dev.clojure.org/jira/browse/CLJ-860
-Phil
da...@axiom-developer.org
about "literate programming". What we do now is a "social wrong"
in the sense that we are creating software that could be so much
better, in an engineering sense, than we do now.
We create software but we lose the most valuable part of
the project by only crafting software that communicates with
the machine. The real value is the communicating the ideas
to other people.
Once we "change the world" to expect programs to be literate
everyone will have their expections raised to the point where
they consider non-literate programs to be unprofessional.
Tim Daly
da...@literatesoftware.com
Alex Miller
this year.
St. Louis, Sept 23-25
http://thestrangeloop.com
Alex
On Feb 24, 12:29 pm, Damien Lepage <damienlep...@gmail.com> wrote:
> Hi Everyone,
>
> You may have seen this already, if not I believe it's worth investing 1h of
> your life:http://vimeo.com/36579366
>
> That's already a good candidate for the technical talk of the year, if not
> the decade IMO.
> Ok, I'm getting a bit too enthusiastic here but this is so inspiring.
>
> After watching it, you can't help thinking that we have a whole new world
> to invent.
> As a side note, you may start thinking that a REPL is not good enough.
> - Personal message to Laurent Petit: please watch and start thinking about
> CCW 1.0 ;o) -
>
> But, most importantly, beyond any technical consideration, the last part is
> a great life lesson.
>
> --
> Damien Lepagehttp://damienlepage.com
> linkedin.com/in/damienlepage <http://www.linkedin.com/in/damienlepage>
David Nolen
Colin Yates
The lesson for me (which has echoes of the 'hammock driven design' message) is that sometimes the best ideas come not from evolutions of existing answers but starting completely from scratch. As techies, we sometimes (I think) restrict ourselves to improving our existing solutions which in effect restrict our solution space to our own (sometimes inferior) answers. For example, I doubt any of his answers came as an improvement to existing IDEs - they are new creations.
Hmm - not sure I made that clear - I learnt a lesson anyway. Excellent points and I certainly found the video inspiring.
Good link!
Col
On Friday, 24 February 2012 18:29:06 UTC, Damien wrote:
Hi Everyone,You may have seen this already, if not I believe it's worth investing 1h of your life:That's already a good candidate for the technical talk of the year, if not the decade IMO.Ok, I'm getting a bit too enthusiastic here but this is so inspiring.After watching it, you can't help thinking that we have a whole new world to invent.As a side note, you may start thinking that a REPL is not good enough.- Personal message to Laurent Petit: please watch and start thinking about CCW 1.0 ;o) -It also feels like ClojureScript is on the right path.But, most importantly, beyond any technical consideration, the last part is a great life lesson.
--
Nicolas
research.
While I can trust you can make, say an intuitive and reactive UI for
flash like animations, I think there are still problems to take care
of for the program example.
Here this is just a simple algorithm without long calls inside,
without access to external systems or mutable state. All kind of
things that would simply fail to work properly in pratice.
I can see this as an evolution of unit testing and debugging. You
still need to mock dependancies and take care to build input data to
test your program. But in exchange you can check interractively
execution outcome and intermediate steps and tweak it until it provide
the required result.
You could then ask to generate the proper unit test because well all
information is already available.
But making this kind of UI fluid and easy including a way to properly
specify your mocks (and what is not mocked) is going to be complex...
But I agree, functional languages that tend to favor pure functions
really help there.
> > linkedin.com/in/damienlepage <http://www.linkedin.com/in/damienlepage>