I was reading Planet Lisp and happened across Dave Roberts' post about
RAD in Lisp:
http://www.findinglisp.com/blog/2004/11/lisp-rad.html
This post, combined with some of the recent discussion on comp.lang.lisp
about application delivery and games and whatnot, reminded me of SK8,
one of the Lisp-based projects I worked on at Apple.
Like Lisp itself, SK8 is a little hard to summarize briefly. It was a
development environment in which all the system-native widgets, plus
widgets that you could create dynamically by dragging graphical objects
together, were SK8 objects that you could manipulate as first-class
values. Like CLIM and Dynamic Windows, SK8 provided an easy way to get a
reference to any screen object so that it could be inspected or treated
as a parameter to a function call. Like HyperCard, SK8 enabled you to
'open up' any screen object and write a 'script' for it, in Common Lisp,
or in a HyperTalk-like language called Sk8Script. The great advantages
of SK8Script over HyperTalk were that its object model was the full CLOS
object model, rather than the much more restricted HyperTalk object
model, and it compiled to native code.
Using SK8, you could dynamically assemble a UI by snapping together UI
widgets, or by building new ones by snapping together graphical objects
and giving them behavior written in SK8Script or Common Lisp. It had
very rich support for sound, video, animation, constraints, and object
persistence. Once you had built an application by creating objects,
giving them behavior, and plugging them together, you could deliver it
by saving it directly to an executable.
If you've only seen tools like the GUI builders that are common
nowadays, it's hard to appreciate how seamless the SK8 experience was.
All the UI objects were live and you could interact with them normally,
as if the application was running (because it was). At the same time,
you could 'open up' any UI object (including those of SK8 itself) and
see how it was implemented, clone it, and modify it to look and behave
some other way.
Now, SK8 ran only on MacOS, and it belonged to Apple. However, it
occurred to me that if something like SK8 existed now, built on a free
Lisp that runs on various platforms, then a lot of what people have been
talking about and wishing lately for would be available, and in a very
nice package.
So I contacted the creator of the original SK8 project, Ruben Kleiman,
and asked him if he would be willing to help out with an open-source
project to create something like SK8, but free and portable. He replied
right away that he would be very interested in helping out with such a
project.
So, for those Lisp enthusiasts who pine for a media-rich,
cross-platform, GUI application development platform in Lisp, here's
your chance: you could volunteer to help out building a new generation
of SK8 on one of the free Lisps.
Recreating SK8 would not be a small task, but, speaking as someone who
worked on the original, I think it would be a blast, and well
worthwhile. And if we pulled it off, it would be a killer way to put a
stop to the perennial questions about deliverability of portable GUI
apps written in Lisp. And the opportunity to work with Ruben on
something like this is worthwhile in itself. He's quite a character.
My time is already very crowded with projects, but I'll set aside some
cycles to help get this thing going if enough people are interested. If
your are interested, drop me a line. Let's see if a motley group of Lisp
Hackers have it in them to make something really cool.
From: Rahul Jain
Subject: Re: RAD, SK8, and a lisp development platform
Date:
Message-ID: <87actlqshf.fsf@nyct.net>
mikel <·····@evins.net> writes:
> Like Lisp itself, SK8 is a little hard to summarize briefly. It was a
> development environment in which all the system-native widgets, plus
> widgets that you could create dynamically by dragging graphical objects
> together, were SK8 objects that you could manipulate as first-class
> values. Like CLIM and Dynamic Windows, SK8 provided an easy way to get a
> reference to any screen object so that it could be inspected or treated
> as a parameter to a function call. Like HyperCard, SK8 enabled you to
> 'open up' any screen object and write a 'script' for it, in Common Lisp,
> or in a HyperTalk-like language called Sk8Script.
[...]
> So I contacted the creator of the original SK8 project, Ruben Kleiman,
> and asked him if he would be willing to help out with an open-source
> project to create something like SK8, but free and portable. He replied
> right away that he would be very interested in helping out with such a
> project.
It sounds really, really cool. I always liked the online-development
aspect of HyperCard and adding this to a Lisp GUI toolkit is in perfect
symmetry with the Lisp language itself.
Is SK8's model compatible enough with CLIM that it could be implemented
atop/within McCLIM?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> mikel <·····@evins.net> writes:
>
>
>>Like Lisp itself, SK8 is a little hard to summarize briefly. It was a
>>development environment in which all the system-native widgets, plus
>>widgets that you could create dynamically by dragging graphical objects
>>together, were SK8 objects that you could manipulate as first-class
>>values. Like CLIM and Dynamic Windows, SK8 provided an easy way to get a
>>reference to any screen object so that it could be inspected or treated
>>as a parameter to a function call. Like HyperCard, SK8 enabled you to
>>'open up' any screen object and write a 'script' for it, in Common Lisp,
>>or in a HyperTalk-like language called Sk8Script.
>
> [...]
>
>>So I contacted the creator of the original SK8 project, Ruben Kleiman,
>>and asked him if he would be willing to help out with an open-source
>>project to create something like SK8, but free and portable. He replied
>>right away that he would be very interested in helping out with such a
>>project.
>
>
> It sounds really, really cool. I always liked the online-development
> aspect of HyperCard and adding this to a Lisp GUI toolkit is in perfect
> symmetry with the Lisp language itself.
>
> Is SK8's model compatible enough with CLIM that it could be implemented
> atop/within McCLIM?
I don't know quite how to think about that question. I would say, from
my experience with both, the I think it would be much easier to
implement CLIM in SK8 and the other way around.
By the way, I have received a pretty encouraging initial response, and
will be putting together a message to the respondents and to Ruben that
makes and solicits some suggestions for how best to proceed.
From: Rahul Jain
Subject: Re: RAD, SK8, and a lisp development platform
Date:
Message-ID: <87d5yhpahw.fsf@nyct.net>
mikel <·····@evins.net> writes:
> Rahul Jain wrote:
>
>> Is SK8's model compatible enough with CLIM that it could be implemented
>> atop/within McCLIM?
>
> I don't know quite how to think about that question. I would say, from
> my experience with both, the I think it would be much easier to
> implement CLIM in SK8 and the other way around.
Hmm... I don't get it... where would the low level stuff in CLIM hook
into. From what you described SK8 looks like it's a GUI builder meshed
with an IDE. The GUI functionality could be built upon CLIM (using
gadgets and all) and leverage the abstraction it provides over the
native graphics and widget system. Is there something at the low-level
that SK8 provides that doesn't mesh well with CLIM so that CLIM would
need to use SK8's APIs to that functionality? Maybe doing a side-by-side
comparison of the facilities provided by both libraries would be the way
to analyze this question. CLIM provides:
Geometry
regions
bboxes
transforms
Windowing
Sheet and medium output
text
graphics
colors
designs
Extended stream output
output recording
table and graph formatting
bordered output
text formatting
redisplay
Extended stream input
presentation types
input editing
menus
dialogs
Applications
commands
frames
panes
gadgets
I suspect that SK8 can use CLIM's geometry, windowing, sheet and medium
output, application, and of course presentation type functionality,
possibly extending or overriding bits of the application functionality
with stuff more appropriate to RAD and adding nice builders for PRESENT
methods.
> By the way, I have received a pretty encouraging initial response, and
> will be putting together a message to the respondents and to Ruben that
> makes and solicits some suggestions for how best to proceed.
Great! I'm looking forward to this.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> mikel <·····@evins.net> writes:
>
>
>>Rahul Jain wrote:
>>
>>
>>>Is SK8's model compatible enough with CLIM that it could be implemented
>>>atop/within McCLIM?
>>
>>I don't know quite how to think about that question. I would say, from
>>my experience with both, the I think it would be much easier to
>>implement CLIM in SK8 and the other way around.
>
>
> Hmm... I don't get it... where would the low level stuff in CLIM hook
> into. From what you described SK8 looks like it's a GUI builder meshed
> with an IDE.
That's because of my inadequate description. You can't get something
very much like SK8 by combining a GUI builder and an IDE. To the extent
that it was like a GUI builder at all, it was more like a GUI-builder
builder, and also a widget builder (SK8 could build arbitrary graphical
widgets by sticking together primitive graphical elements; you could
take a collection of such stuck-together elements and say "now this is a
FOO", and then name its parts and define methods on FOO and its parts).
You could take in-built system-native widgets and stick annotations on
them so that the SK8 object system could reason about them as if they,
too, were made of such stuck-together elements.
A canonical Smalltalk enivronment is closer in feel than GUI builders,
but even recent Squeak versions don't have the richness and seamlessness
of direct-manipulation editing that SK8 had. In fact, 'editing' seems
like the wrong word; to my mind, it was more like sculpting.
SK8 is rather hard to describe. In latter days, Ruben spent an
inordinate amount of time in a perpetual roadshow demonstrating and
explaining it to various management types to prevent its cancellation on
the grounds that they didn't understand it.
I had a bash at the side-by-side comparison, but it just ends up with
line after line of me saying 'you build that on SK8's FOO subsystem.'
Not very helpful.
SK8 is about as hard to succinctly describe as CLIM. It was built on a
persistent frame system. All graphic objects were also frames. As in
CLIM, all screen objects could be grabbed and dropped in a listener as a
reference to the underlying Lisp object. Any object, in a listener or on
the screen, could be inspected with a click. All screen objects (not
just special GUI-builder objects; *all* objects) could be opened and
inspected, and their behavior and definition interactively edited.
It didn't do output recording; that would have to be implemented from
scratch. It did have an event system that should make it reasonably easy
to implement.
>The GUI functionality could be built upon CLIM (using
> gadgets and all) and leverage the abstraction it provides over the
> native graphics and widget system. Is there something at the low-level
> that SK8 provides that doesn't mesh well with CLIM so that CLIM would
> need to use SK8's APIs to that functionality? Maybe doing a side-by-side
> comparison of the facilities provided by both libraries would be the way
> to analyze this question. CLIM provides:
>
> Geometry
> regions
> bboxes
> transforms
> Windowing
> Sheet and medium output
> text
> graphics
> colors
> designs
> Extended stream output
> output recording
> table and graph formatting
> bordered output
> text formatting
> redisplay
> Extended stream input
> presentation types
> input editing
> menus
> dialogs
> Applications
> commands
> frames
> panes
> gadgets
>
> I suspect that SK8 can use CLIM's geometry, windowing, sheet and medium
> output, application, and of course presentation type functionality,
> possibly extending or overriding bits of the application functionality
> with stuff more appropriate to RAD and adding nice builders for PRESENT
> methods.
I wouldn't want to try to implement some of SK8's low-level graphic
behavior on top of CLIM. SK8 supported a lot of video effects and
pixel-bashing. It's an issue that Ruben has already raised in the mail
discussion.
>
>
>>By the way, I have received a pretty encouraging initial response, and
>>will be putting together a message to the respondents and to Ruben that
>>makes and solicits some suggestions for how best to proceed.
>
>
> Great! I'm looking forward to this.
Me too! A bunch of people volunteered, and Ruben is already off and
running, describing how he thinks things should be done, so maybe it
will work out well.
mikel <·····@evins.net> writes:
> SK8 is rather hard to describe. In latter days, Ruben spent an
> inordinate amount of time in a perpetual roadshow demonstrating and
> explaining it to various management types to prevent its cancellation
> on the grounds that they didn't understand it.
Some technology historian should probably write a book on projects
from research labs in industry and academia that were scrapped, and
never saw the light of day...
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
In article <···················@newssvr13.news.prodigy.com>, mikel wrote:
> I was reading Planet Lisp and happened across Dave Roberts' post
> about RAD in Lisp:
>
> http://www.findinglisp.com/blog/2004/11/lisp-rad.html
>
> This post, combined with some of the recent discussion on
> comp.lang.lisp about application delivery and games and whatnot,
> reminded me of SK8, one of the Lisp-based projects I worked on at
> Apple.
Apple has published SK8 at ftp://ftp.apple.com/research/sk8, but
damned if I can find a license for it. Some of the files say
The code in this file is protected under the terms of the current
SK8 License. For information on this license, see
http://sk8.research.apple.com
but that site doesn't seem to exist any more. Googling for various
combinations of sk8/apple/research/license doesn't turn up anything
obvious either.
Rainer Joswig commented here[1], in 2002, that he'd downloaded SK8 and
compiled it for MCL. Ruben also posted on that page, so he obviously
knows (or knew at one time :) about the Apple release.
SK8 sounds wicked cool, I must say.
-- Larry
[1] http://www.lemonodor.com/archives/000028.html
Larry Clapp <·····@theclapp.org> wrote in message news:<····················@theclapp.ddts.net>...
>
> Apple has published SK8 at ftp://ftp.apple.com/research/sk8, but ...
Some of these files don't get extracted/uncompressed propery via
Stuffit Expander v.8.0.2. I get "An error has occurred while
expanding the file "sk8sources.sit.hqx" (The archive may contain
damaged content)."
Any ideas? Is there somewhere a non-corrupt version of this file? Or
is there a different app I should be using to open it?
TIA,
olivier
Quoth Olivier Drolet on or about 2004-11-14:
> Some of these files don't get extracted/uncompressed propery via
> Stuffit Expander v.8.0.2. I get "An error has occurred while
> expanding the file "sk8sources.sit.hqx" (The archive may contain
> damaged content)."
I downloaded all the files except the ones with `ppc' in the name. They
extract fine with Expander 5.5 under BasiliskII / MacOS 8.1. I think you
are seeing Aladdin's planned obsolescence.
-t
Larry Clapp wrote:
> In article <···················@newssvr13.news.prodigy.com>, mikel wrote:
>
>>I was reading Planet Lisp and happened across Dave Roberts' post
>>about RAD in Lisp:
>>
>>http://www.findinglisp.com/blog/2004/11/lisp-rad.html
>>
>>This post, combined with some of the recent discussion on
>>comp.lang.lisp about application delivery and games and whatnot,
>>reminded me of SK8, one of the Lisp-based projects I worked on at
>>Apple.
>
>
> Apple has published SK8 at ftp://ftp.apple.com/research/sk8, but
> damned if I can find a license for it. Some of the files say
>
> The code in this file is protected under the terms of the current
> SK8 License. For information on this license, see
> http://sk8.research.apple.com
>
> but that site doesn't seem to exist any more. Googling for various
> combinations of sk8/apple/research/license doesn't turn up anything
> obvious either.
Yep; I've been down that road. I've also made attempts before to get
Apple to release discontinued projects I worked on as open-source, and
that seems like a non-starter, so I think we're going to start from scratch.
> Rainer Joswig commented here[1], in 2002, that he'd downloaded SK8 and
> compiled it for MCL. Ruben also posted on that page, so he obviously
> knows (or knew at one time :) about the Apple release.
>
> SK8 sounds wicked cool, I must say.
It was. With any luck, its descendant will be again. Ruben and a cast of
a dozen or so are off and running in discussions.
In article <···················@newssvr13.news.prodigy.com>,
mikel <·····@evins.net> wrote:
> Larry Clapp wrote:
> > In article <···················@newssvr13.news.prodigy.com>, mikel wrote:
> >
> >>I was reading Planet Lisp and happened across Dave Roberts' post
> >>about RAD in Lisp:
> >>
> >>http://www.findinglisp.com/blog/2004/11/lisp-rad.html
> >>
> >>This post, combined with some of the recent discussion on
> >>comp.lang.lisp about application delivery and games and whatnot,
> >>reminded me of SK8, one of the Lisp-based projects I worked on at
> >>Apple.
> >
> >
> > Apple has published SK8 at ftp://ftp.apple.com/research/sk8, but
> > damned if I can find a license for it. Some of the files say
> >
> > The code in this file is protected under the terms of the current
> > SK8 License. For information on this license, see
> > http://sk8.research.apple.com
> >
> > but that site doesn't seem to exist any more. Googling for various
> > combinations of sk8/apple/research/license doesn't turn up anything
> > obvious either.
>
> Yep; I've been down that road. I've also made attempts before to get
> Apple to release discontinued projects I worked on as open-source, and
> that seems like a non-starter, so I think we're going to start from scratch.
Though I don't have a document of it, I can remember that
the Sk8 that has been released by Apple was released as
mostly free and open source. It would be necessary to
get the license information - but it should then not be necessary
to recreate it. I think it is Open Source and can be ported
to other platforms.
> > Rainer Joswig commented here[1], in 2002, that he'd downloaded SK8 and
> > compiled it for MCL. Ruben also posted on that page, so he obviously
> > knows (or knew at one time :) about the Apple release.
I did for myself a preliminary port to MCL 4.3 on PowerPC - way back.
> >
> > SK8 sounds wicked cool, I must say.
>
> It was. With any luck, its descendant will be again. Ruben and a cast of
> a dozen or so are off and running in discussions.
Rainer Joswig wrote:
> In article <···················@newssvr13.news.prodigy.com>,
> mikel <·····@evins.net> wrote:
>
>
>>Larry Clapp wrote:
>>>but that site doesn't seem to exist any more. Googling for various
>>>combinations of sk8/apple/research/license doesn't turn up anything
>>>obvious either.
>>
>>Yep; I've been down that road. I've also made attempts before to get
>>Apple to release discontinued projects I worked on as open-source, and
>>that seems like a non-starter, so I think we're going to start from scratch.
>
>
> Though I don't have a document of it, I can remember that
> the Sk8 that has been released by Apple was released as
> mostly free and open source. It would be necessary to
> get the license information - but it should then not be necessary
> to recreate it. I think it is Open Source and can be ported
> to other platforms.
If you can find a copy of the license that is supposed to apply to it,
I'd like to see it.
Ruben seems to want to do some things differently from the ground up
this time, in any case.