hi and welcome everyone such a fantastic
uh way to start our work um
we we're gonna we are we have the
the honor and the pleasure to host uh
alan deeper
diapered excuse me alan diaper and
um everyone asked
we i mean the psychology community
and um
my name is danielle uh and
and i'm i was asked to moderate this
talk so
i'm so happy to that danielle switzky
reached out to me and that i get to do
that because i know
alan from way back if i can say that
uh i remember allen's work uh when
uh we were i was doubling in closure and
he came up with a uh very ambitious
front-end framework called hotline
and we will see what was impressive
about it was that it was based on
a completely different architectural
principle that we were used to uh
so i i don't remember i think it was
the react frameworks were was strong at
the time although maybe it was even
before that when
when there were other other frameworks
javascript frameworks
um strong but at any case
the idea of using the the paradigm
of of a spreadsheet and its reactive
functional model
to to render a front-end was
really novel at the time uh even and and
testament to the fact that today you
we we see this a little bit more uh
but it was uh the first time i i heard
about this kind of mapping of
of a concept onto web frameworks
so i at the time i already
was was uh convinced that uh alan was a
man of ideas
and he confirmed this all the time
because he
he managed to to do to come to come up
with novel ideas again and again
if i may say so um
because uh the next next thing
alan was doing was the boot
uh bit framework and that was also very
interesting
architecturally
because it solved a couple of problems
that
we we had with the traditional tools in
aligning them
performance wise but also um
it was based on the idea that
a build tool doesn't necessarily has has
to be
declarative and it came up with the idea
of giving the full power of closure
while while writing uh the build
programs the extensions for the build
tool
and that was very novel also and very
interesting
because normally build tools are either
declarative or they have a dsl
that you use to extend it
uh and and and and boot was very elegant
architectural solution which gave you
the full power of closure
so you might think that uh alan diaper
was happy in claudia land but next time
you hear about him and it's about in the
context of ah
and that is that is that is what i like
about alan it's that
it's not it's not it's not just about
one community
one language um this this
this uh this um you know
polyglotism if i may say you know the
ability to to
learn multiple languages and juggle with
the languages
polyamory even is that the same thing
different thing
[Music]
that's awesome yeah um
this idea of uh using languages for in
the context
uh in the right context and the idea to
uh to be able to move along and not to
to to be more married to the idea and
the concepts
behind what you're doing than than than
the
the particular uh implementation that
you're using
this this this this is uh for me
a sign of maturity in terms of
developers so
i think now it's the time to to see what
kind of audience we have because
this is this is uh these insights are
very useful to to uh to
to people who begin uh in their
beginners or people who who are
uh busy learning their first language
because there is also always
a first language and you have to master
it before you can start jogging with
concepts and
and ideas so uh
that is one thing but the other thing is
that alan also uh
is going to talk about a project which
is uh
in a yet another language common list uh
although it's the same family of
languages but uh the question now
is uh the about the audience we would
like to know two things
and uh please uh use the chat to
to answer the the question the first um
the first question is uh is about the
experience of everybody here so to know
uh how experienced the audience is in
terms of
career as a developer so maybe you can
put in the chat
how how long you've been programmed
thank you
okay 20 years for garyvalley
capital devices
10 years professionally seven years
six years six years 20
70. so we have uh i would say three
years
six times and
[Music]
everybody is kind of uh okay we have a
okay allen your audience is uh made of
uh
experienced developers which maybe
shouldn't be too surprising because this
is not the kind of meetup
you stumble upon if you start but anyway
now we know and then the second question
is
what is your daily uh driver in terms of
language because
we have maybe we have certainly closure
people which are recognized
but we might might have commonly people
and we might have people who
write in other languages as well so
maybe everybody can type in
what kind of programming language they
use as a daily driver
and the question is just the daily
driver because you might
know multiple languages but what what is
the the main
your main language that you use okay
nice
nice uh we have uh ruby we have
we have uh c plus plus we have kotlin
um we have
closure and python also
so so that's nice
commonly also your script that's cool
yeah okay so so great thank you very
much and i
i will now leave the
podium if i may say so
to adam thanks let me simulate coming up
oh thank you daniel uh very
humbling and flattering introduction uh
i cannot take full credit for boot or
hoplon
um my longtime friend and collaborator
misha niskin is here on the call
so that's the reason i have to be honest
about it uh he and i
designed all those things together so
um but yes thank you so much for the
opportunity to come here and speak
and i was telling
the daniels before the call uh
preparing for things like this is always
really fun
because you know i'm sure you've heard
it said the act of writing is kind of a
vehicle for thought and for honing your
thoughts
and every time i have an opportunity to
introspect and crystallize and share i
feel like i
gain new insights for myself so i'm
grateful
very much for this opportunity and i
hope i'm able to share something of
value and if not a value of interest
and if not of interest at least you'll
find it mildly funny
so without further ado let me uh
get my slides going here try a little
screen sharing
share screen
okay is everybody seeing a slide
yeah great
so yes if uh you have any questions
later
or just want to get in touch you can
reach me at these coordinates and i'll
share these slides
as well and get distributed and they
have real links and so forth
um yeah so
daniel has done a fantastic job of
biographying me
but i can fill in some gaps and
paint the picture a little more i think
this is important because
and i'll get elaborate more on this but
i don't think you can understand things
in the world without understanding
why they matter to other people and to
do that you have to know a little bit
about the other people
um and you know it understand where
they're coming from a little bit so
that's my goal here so i've been using
closure since 2009
i learned it when i was a student and
i had the uh
enthusiasm of the new convert big time
because
it seemed like closure was the end-all
be-all and i couldn't believe people
were using java that was
ridiculous and preposterous and there
was no way i was going to do anything
except closure
and as foolish as that perspective was
it turned out to pay pretty huge
dividends for my career and for my
friend's circles and everything because
going all in on something is valuable
you know you make
these lifelong friends and connections
you
uh are exposed to ideas
that you can use to compare other ideas
to later
and i know anyone who's learned closure
pretty much compares anything anybody
tells them about
to closure right i mean it's like okay
what
doesn't this do that closure does better
is kind of like after you know closure
that's kind of the standard you hold
at least i did for a while and tempered
somewhat there um
but yeah i was you know heavily invested
in the language the community and then
uh added participated in the creation of
new tools and infrastructure and
libraries and stuff
around 2016 i made a career change it
seemed like there was an opportunity for
me to apply
the skills and the knowledge i'd
accumulated in the closure community in
a new context
in the r world and more broadly in
scientific computing
and i think
this is this is a trend uh the concept
of data scientists the concept of
scientific computing
i remember when i was in college
scientific computing meant
like grid computing with c and mpi and
stuff like that and i
vaguely was aware that this was going on
i never participated in it
but i think since then the concept of
data science has opened up significantly
to the point where we have a category of
person who is a new programmer who needs
to explore data
and that's interesting because i think
that's pretty much the same kind of
person
as someone who's using a dynamic
language for the first time
programmer or not you know it's all
about working your way through dad data
finding patterns defining patterns
uh carrying yourself to new levels of
understanding of the data filling in the
gaps with abstractions and so on
so this this little period in my life
when i was doing r
and javascript and immersed in the data
science world was really interesting
and my experience with closure paid off
there
in parallel to all of this back in 2010
i was working at what was then relevance
and we had a concept of open source
fridays where we would
do some open source stuff and we were
paid to do that
and i was helping out with like
low-hanging fruit and closure itself
and closures plus
function uh
and functions in closure generally
support something called
inlining and what that means is
in like syntactic instances of
expressions like plus one two
can get replaced at compile time
with a call to i think it's closure
math ad or something like that like
there's a java static method underneath
closures plus
and if you can replace the function call
to plus
with a direct call to the java static
method without any variatic arguments
then you get a slight performance
improvement and
when i was studying i've never seen
anything like this before it's like a
dual headed function and macro because
plus is a function not a macro but there
is a
an understanding of a kind of macro that
is applicable to even functions like
plus and so that was new to me
and it turns out the optimization is
called broadly compiler macros
and this is a feature of common lisp and
that's where rich got the idea
presumably
so he told me this and sent me over to
the lisp
documentation and i landed on something
called the hyperspec which i'll show you
later
but i was really impressed with the
depth and breadth of the common lisp
documentation because beyond the
hyperspec you've got dozens of books and
technical articles and academic articles
and i found myself getting kind of
distracted by it and kind of
being more interested in learning about
common lisp and then making closures
plus
as fast as possible and i had to kind of
consciously step back from the common
list thing to get back to my work
but uh that was my first glimpse
um since then i have not used lisp
professionally at all i'm like uh i'm
i'm an enthusiast uh it's a hobby thing
for me
um and i should say further that not
only am i an enthusiast and not use it
professionally i don't even really know
how
you would use it professionally i have
vague ideas about and i know
more or less the affordances of the
different implementations and so on
but one of the things i would hate for
anyone to take
from this talk is i'm going to use
common lisp at work because alan diaper
told me to
and i don't i don't want to be on the
hook for that okay the career
consequences for you are undefined
okay so for me this is a hobby and by
that same token
i'm not an expert at common list i'm if
i'm closest to being something like an
expert in closure
but i cannot claim to be an expert in
common lists but i think lack of real
production experience is probably what
keeps me from that
but maybe in the future it'll be
something i'll be able to pursue it's
certainly an aspiration
um for the moment i am still a closure
programmer
i came back from the r world about a
year ago i switched jobs and now
like well i technically work for myself
but i have customers who have me doing
closure and
javascript which i enjoy and it's great
and um yeah closure is closure is
awesome
so broad stroke agenda here uh
yeah i i it's been many years since i
first saw common lisp and i'm still
interested and excited about it and i
don't
really know why that is like i don't
really know why
uh i think it's good and i like it and
i'm marginally obsessed with it
it's funny because my interest in this
has really confused and surprised a lot
of my friends in the closure community
and even in the art community
like what what do you see in this um
so some of the time i'm looking at this
stuff i think
maybe maybe i'm just going crazy like
maybe i have a brain tumor or something
like that
but um you know i don't have any other
symptoms
so i think it really is just it's
interesting
um so i hope to convey why
why i think it's history and interesting
and this is the introspection that i
mentioned earlier that i that i did that
i haven't done
is i've known i've been afflicted with
this like obsession
but i haven't really thought about why
i'm so interested and so i hope to share
that
um the other thing is context i think i
mentioned
you know if you want to understand an
idea it helps a lot to understand the
people behind it and what motivated them
to do stuff um and i don't think
common lisp common lisp
was not designed by one person first of
all and
none of the people who promote it now
lay claim to it or particularly invested
in its future directly
uh i mean everybody's part of the
community but that nobody has special
standing the way that rich hickey has
special standing in the closure
community
so you hear a lot of different versions
of why common lisp is good and you hear
common lisp explained in a lot of
different ways
but the people who originally designed
it are more or less out of the public
sphere they're retired
you know playing it playing it's low
so you don't hear much about what
motivated the people originally
to make it so i'm
not that person obviously this was i
mean come the design on common list
started before i was born
and the stuff that the other lists the
common lists are based on
existed decades before i was born so i
can't i'm not going to be that person
but i have read a lot of that stuff and
so i hope to
share some of some of what i run into
that i thought was informative
and then finally there's a lot of
activity in common list right now
not as much as enclosure not as much as
in probably
any other language you've heard of but
it's there
and it's really exciting i think um
because the foundation is so solid and
well there's a lot of reasons for causes
for excitement that i'll get into
uh what this definitely isn't is the
kind of talk where i'm trying to
shoehorn
these into some kind of dichotomy um
daniel mentioned earlier that you know
i'm polyamorous
or poly poly polytheistic
polylingual i'm down for all these ideas
i have recognized great personal benefit
from investing heavily in one thing
which i did with closure for like 10
years
but i think there's also tremendous
benefit in
recognizing that it's possible to like
multiple things at the same time
and you know we don't have to be fully
invested and i think this is a message
more for
junior people and my former self i don't
think anyone here probably
is would disagree with this
um so yeah both closure and common list
can exist at the same time and both be
amazing at the same time and we can
uh we can have you know
recognize and realize great benefits
from holding both in our heads at the
same time
and maybe even switching between them
when it's convenient
okay so why are we here why am i
why why is this meeting worth your time
and
i think it's because common lisp is not
going anywhere it is going to wait for
you for the rest of your life
to learn without changing um and that's
because
it's a standard it's already agreed upon
it's in the books you know they there's
a thing
there's a plate the standards
organization keeps it on file
so whether you learn it today tomorrow
next year
or on your deathbed it's going to be the
same and
to me as someone who spent a lot of time
in the web development world
and at the mercy of people who
changed libraries for reasons that
aren't in alignment with
my own interests or business repurposes
that's very refreshing because
um it's kind of part of nature now
it's not a product it's not even an
instance of a thing that exists on a
disk it's
literally a standard
and still it has value and i think
that's because the fundamental problems
of programming have not changed
since people started programming the
human brain hasn't changed
the user interface the you know the
human computer interface hasn't changed
we still have keyboards symbols letters
we use natural language in identifiers
um we can more you know
it's not like people now can hold more
ideas in their head at the same time as
people in 1981.
and the same kinds of things that humans
find intuitive and natural in the same
ways that people think generally are all
the same
and so these are the affordances of a
language
and common lisp offers these affordances
and it tackles these problems still
so there's value there clearly
the other interesting thing about it
compared to most other
language implementations and design
initiatives is the amount the sheer
amount of experience
that went into this thing usually
people when people from closure or even
the scheme community talk about common
lisp
they sneer at the legacy you know the
the problem of backward compatibility
um but the flip side of that the benefit
of a legacy is that everything there was
put in for a reason at some point
so it might bother you now that the
interfaces aren't perfectly uniform
but who's to say that your perfectly
uniform interface won't be
corrupted in the future when you decide
to use it and considering that
all of the problems are the same it
seems to me unlikely that you're never
going to have to
corrupt whatever idea you have for
abstraction now in the future
so why not just start with the set of
corruptions from
prehistory and build up from there
knowing full well with your eyes open
that these are compromises
and that just hindsight doesn't free you
from having to make
compromises so um
and yeah i think it's interesting i
don't i'm not sure people come together
i'm not aware of any more recent
examples of
people with this depth of programming
experience coming together from such
wide parts of the programming world to
make something
and to pour their experience and their
interests into something
so i think commonlist was singular as an
artifact
um yeah so dldr commonlist is a great
thing to learn because it's not going
anywhere it's not going to change
whatever you learn about commonlist
today and this meeting is going to be
applicable
in 10 years whatever code you write is
probably going to work
and that's what circling back to me and
my interest
my obsession like when i first got
back into common list in 2016 i was
programming and reading about it
probably two or three nights a week
before bed like three hours a week or
something like that
and that's been an ebb and a flow like
i'll pick those projects up
three months later six months later a
year later
um and i don't perceive
like i'm in no rush and it's been really
honestly delightful
and that's partly that's the delight of
a hobby project because there's no
business pressure
you know um but it's also partly because
uh i'm confident these things aren't
going to change and i can really learn
at my own pace in a way that
is difficult to do with other things
that change more frequently
so when i talk about the trade-offs and
the history and stuff
not only was lisp designed by people
with a really
depth d really deep and wide experience
but we have some visibility in the
modern era into those experiences and
there's a few different sources of
information
this is an email from
the original i believe it's the original
[Music]
multi-institution
design mailing list so there were people
from mit
stanford symbolics all the major players
of the early 80s
and they were on an email list and they
discussed
fundamental design problems and
we have visibility into those
discussions some of the discussions are
kind of contentious
some some of a lot of the times they're
referring to
meetings they had in person and so you
don't get the full picture
but it's nevertheless it's a window like
here's an example that i pulled up this
is an email from somebody at mit about
they're talking about commonless
language probably the first edition
which was um it's like a 1200 page book
that was a
draft of the specification that guy
still put together in i think 1981 or 82
and that book circulated around at these
different institutions and they would
read it and
think about it and prototype things and
then they would
communicate to each other on this
mailing list so this guy's asking about
the thing for making a hash table
uh takes a test keyword argument
and one of the equality comparators is
is missing
you know why is that it seems like it
should be in there and so people respond
to him
um separately there is this thing called
the hyperspec which i mentioned which is
a hyperlinked
documentation of everything more or less
everything in common list so anything
that's named in common lisp has
represented somewhere in the
hyperspec this is not the specification
this is a proprietary view
of the specification with examples that
was put together by ken pittman who's
one of the
original lisp luminary people from mit
so this this basically is like a javadoc
for lisp
and you can see why that is you get your
arguments your return value your
description and then a little bit of
high level overview
but the interesting thing is that these
javadoc things link to
design issues and represented in the set
of design issues is
a reference to the problem we saw from
the design mailing list which is
they had like a committee discussion
about which equality constructs
hash tables should support
um so you can if you know if you have a
problem with why common lisp does it
this way you can find the source
and uh i think
i think that's really cool i think very
few things that we
use that are designed to give you this
kind of visibility into the why and how
and the context
and that's actually not fair to python
with the peps and stuff like that
like this this tradition is alive um but
i think uh common list was an instance
of it
which is for it's for its benefit
um so circling back to closure what is
the killer feature of closure this is a
this is a subjective question you know i
mean some people
really like the lisp syntax aspect of it
uh certainly the immutable connect
collections we're getting a
few questions
oh so uh proprietary view the
the the hyperspec is a
document with a copyright and that
copyright belongs to a company
and the copyright does not
allow arbitrarily copying and pasting
hyperspec
so while the constructs that the
hyperspec mentions are free and open and
you can talk about them
in any normal way you can't for example
take the text of the hypertext or of the
hyperspec and copy it into your program
or
you know make a new website called
allen's hyperspec
uh where i've just replaced all
instances of ken pitman with alan
deibert or all instances of common lisp
with you know
rainbow unicorn or whatever does that
answer a question tori
no problem so yeah killer feature of
closure
java interval java interrupt that's huge
but i think the killer feature is rich
hickey
and the reason i say that is because
rich hickey
yes he made a language yes he put all
these features together but there's a
consistent philosophy behind the
language
and most importantly rich makes it very
clear up front
why he's doing what he's doing so
when anyone comes to closure they're not
looking at individual features
they're connecting with this person and
his story
and his needs and his philosophy and
once you're
holding that in your head then all the
features and stuff in closure fall out
naturally like you can understand his
perspective and why he made the
decisions he did
and that empowers you to really design
closure for yourself
in a way that also is i think rare uh
generally when people
are promoting technology they talk about
specific features or
if you're lucky they'll talk about you
know stories
um like user stories or case analysis
what do they call that case studies um
but you don't really get a holistic
fundamental view part of that is because
uh it's really rare for for large
intellectual artifacts in computing to
be really designed by one person
that's pretty rare even you know most
most things are designed by
small groups of people but this really
is
a one person thing and so because it's a
one person thing you have unprecedented
visibility into why
and i think it's great i i'm this this
was new to me like i
when i when i learned closure this was
very compelling to me because
it seemed like i had to learn java just
because that's what everybody learned
and if i wanted to do stuff on linux i
had to learn c because that's what
everybody does
but neither of those things
came with this deep philosophical
historical
background and so that i was i was
almost shocked by this
i'm giddy and i think all these things
are still on youtube
and this is a great reason to to use
closure today still and
it's awesome
so yeah you know rich is big on on
rationale and
and doing things with intent and in an
open source project this is critical
because
uh the intent messages to people whether
or not they want to have anything to do
with your thing
whether they want to help you you know
are you in alignment with what they want
if you don't have this rationale then
you get pull requests that you have to
shut down
which makes everybody feel bad so it's
better to say what you're going for and
let people come to you rather than not
say what you're going for
and people come to you with ideas that
aren't in alignment with your own and
you know for himself
i know richard this for himself this is
this is the outcome of years of his own
thinking and research
um and it's great uh and um
lisp doesn't their common lisp doesn't
have a document like this like there
isn't a common lisp rationale document
part of that is because there is no
single person
who could have written it the other part
of it is a lot of their rationale was
implied
to themselves at the time so you can
piece something like this together for
yourself if you do the research and you
can find it in the emails and the
hyperspec and the issues list
but it's not all in one place like this
but i think this is very powerful
all right the champion so that's where i
introduce myself i'm the champion
i'm the hero of this talk i'm the person
who's
who's uh distilling all the context uh
for you all
and i'm certainly joking uh there is no
such person
but there is room for such a person to
pretend to be such a person which is
what i'm doing now
um well this slide is mangled
so a little light criticism of closure
is in order
uh i still use in love closure but one
of the things in the rationale
is emphasis on functional programming
which
i think anyone here would agree is a
good thing
but there is no free lunch you know
every every design decision comes with a
set of trade-offs
and um in one interview rich described
closure as uh a programming language
that inhabits a place
in the set of possible designs that he
really likes and wants to be in
so it's a multi-dimensional space he
made a few design
decisions that took him to a particular
place that he likes but
um maybe it's not the best place for
other people to be in
so one of the tenets of closure is
functional programming and as the basis
for that closure has a really
comprehensive sense of equality
general generalized equality but that in
itself is a trade-off
because arbitrary comparison between
arbitrary pieces of memory
requires some heuristics to be applied
because there is no universal
mathematically sound definition of what
something is
so whoever's designing that has to make
some cuts
um and yeah sorry i skipped to the
fourth bullet but with regard to the
first bullet
um when i was originally in use closure
the concept of everything as data was
very refreshing
because i was used to needing to write
really obtuse java programs
and the other end of it
the idea that you could describe things
as data was really empowering
but as i doubled down on that approach
and continued in my career i realized
well if even if you put data together
you still
have to interpret it somehow and
you're going to need code to do that and
sometimes the kind of interpreter you're
going to write looks suspiciously like a
lisp interpreter hiccup
is an example of this it's like huh this
is kind of like a lisp and a lisp
at first i thought it was really cool
but then as i matured i thought um
i wonder if this might be going backward
a little bit
because i've heard it said that you know
any system evolves into lisp
that's greenspun's 10th 10th rule you
know any any
large system is a ad hoc
incomplete version of common list and i
thought i wonder if i'm subject to that
enclosure world
um and yeah i think there's an emphasis
on keywords enclosure as a result like
keywords are a really dominant part of
most closure programs
and arguably they form a namespace
because they're global
they can have multiple meanings and be
used for multiple different purposes in
a program
and that's a trade-off same with
polymorphism
you know closure has several different
mechanisms for polymorphism
there's protocols multi methods
various library contributions like spec
for
pulling apart dispatching on pieces of
data structurally
you know each of those is that is code
that's going to be on disk and code
that's going to be
in memory and also the burden of
choosing which one to use is on the
programmer
so it's all a set of trade-offs overall
though
i mean i'm still really grateful for
the spot on the design space that
closure inhabits here because it is
unique
and it is very very powerful like it
really it's very easy to make
things that are likely to work on the
first try
and are just conceptually nice
it feels nice so um that's it for the
light criticism
uh i can't really crit and the other the
other point is i can't really criticize
the design of closure
because i you know it was made for its
time and place
and i'm in a different time and place so
it's not fair
um so this isn't really criticism's
criticism so much as revisiting some of
the points and closures rationale in the
modern era so pleasure
this the most of the closure rationale
is i think written 10 or 15 years ago
and certain truths about the
computing landscape have changed since
then
one of them is that
docker and the cloud have
put renewed emphasis on operating
systems and i think you see things like
alpine linux
and various other custom os
abstraction layers for use in cloud
environments
um i don't think it's the case that
vms are the future i but i think
technology and approaches that are in
vms are proliferating
into os's and into infrastructure
jit is an example of this so you know 15
years ago
hot spot was and maybe lua luagit we
came a little later but
it was a pretty new idea
but the idea of a jit
was more or less proven in 1999 at hp
and what they did there is they
uh made a jit compiler for
an architecture i figured what it was it
was like a
alpha processor i believe and
they wrote a jet for the alpha processor
that compiled into code for
for a real alpha processor and so they
had a program
that emitted alpha processor machine
code
and then they fed that into their alpha
processor jit
which emitted code for an alpha
processor and the code running on the
jit was faster than the machine code
if you ran it just by itself which made
it clear
that jits could be could do
could add value regardless like even at
the machine code level like the concept
of tracing
and hot reloading and stuff or you know
moving code motion and all that stuff
like there was value there even the
machine level and
that kind of smarts is moving further
into the computer as we see with apple's
m1 chip that thing is basically like a
little hotspot on it
but it has a full view of memory and and
stuff going on in the computer the other
trade-off with jits
which was true even 15 years ago is
they make it harder to reason about the
performance envelope
of a particular function because
something that to you might seem
intuitively
fast might actually have a non like a
non-local effect of making something
else that you thought would be fast slow
because it gets kicked out of cash for
example the code trace gets kicked out
of cash because your thing
now dominates in some way that intrigues
the jit
so again i think this is something that
is a trade-off for most people using
java it provides more benefits than
problems
but if you're really interested in
reliable performance envelope like you
really need to make sure that this
function runs the same speed every time
and there's various applications that
need that then
java and jits are not necessarily the
right thing for you
um platform on platform issues i think
this is this is still true which is if
you have different platforms with
different memory models
uh like for example if on what one
platform you have strings are immutable
and another platform strings are
immutable or you know there's 32 bits
and a float
or there's 32 bits in a integer here
64 bits and an integer here um
you know you can see how that
complicates
fitting one thing to the other thing or
setting one thing on top of the other
thing
you can imagine how there's
inefficiencies that creep in there
because you have to coerce and copy and
do stuff to make it all match up right
um which leads me to this key another
key contextual difference
uh and i i think maybe a better term
than context is situation
you know rich talks about the
situational aspect of programming and
how nothing really makes sense unless
it's embodied or situated somewhere
oh yeah i'm i'm not sure if there's a
closure script rationale
i actually if you go to the first commit
enclosure script
there's a uh an org file the original
closure script read me there's a
bulleted list foreclosure script that's
similar to the one for closure but i
don't know if it's
um i don't know if that's on the closure
script website
whoops
so um right this is this is the big
difference
really closure is two things the
compiler and the runtime
built on a really pretty deep stack of
other stuff
and this was a
this is a tactical decision now you can
imagine you're a person you're a single
person you can only be awake for so many
hours in the day you can only type so
fast
uh but you want to make a new
programming language are you going to
define
a new kind of computer and operating
system to make that happen
no you're going to make a dsl you're
going to do some prototyping
and rich when he made closure it was all
him you know he had some ideas
and he wanted to move as quickly as
possible from those ideas to being able
to use them professionally and
industrially
you know he had the experience with c
plus plus and common lisp industrially
he wanted to make those things go in a
way that he could sell
in a way that he could start using like
within his lifetime
so the platform aspect
for him just in terms of his
time available to engineer stuff
certainly was really
really uh key um i should say also
i i do you know i have worked with rich
and i have a personal connection to him
but i don't speak for him on any of
these things
and i'm going based really only on
information that he's made public or
written about or spoken about
um but which with which he may now
disagree
so again i don't i am not rich hickey
i don't speak for him but this is my
assessment of
maybe why he made these decisions
reading reading between the lines a
little bit
common list on the other hand much much
much broader set
of desired capabilities
i have operating system at the bottom of
the stack there
but even the earliest lisps were really
tightly integrated with the operating
system
and the operating system was in some
cases written almost entirely
in lisp so even that boundary is not
really
very uh
easy you know or obvious uh
lisp the idea you can use to describe
a whole computer um and where you want
the fun the foundational stuff of the
computer to end and list
to begin is kind of a design design
decision
but commonlist was not architected to
take on the problems of the operating
system so
some things are absent from the spec and
are provided by third parties or
implementations now
threads is one of those c interop
cffi is another one that's uh platform
uh dependent but you know it's been 20
years
so i'll even a lot of these platform
dependent things
have converged on something like a
standard that works across platforms
like the thread standard board there's a
library called bordeaux threads
but nowadays most implementations
provide their own native version and
they all
interoperate and people in the community
take interoperation between
different implementations pretty
seriously um
so yeah it's a different thing it's
apples and oranges really
uh going back to my second slide about
you know is it
is which one is better and it's like
they really are different significantly
um so we have all these abstractions in
play
and they exist at different levels
in our tower
and we have to choose which ones to
build on and how to integrate them and
then this is the this is the work of
design
this is what anybody who makes a
language has to do
closure has a set embodies a set of
perspectives on how to do this
that it delivers as a set of features
or you know forms and runtime objects
that we have access to
oh and you could say and this is on this
fourth bullet i kind of roll this up and
say
my own definition of abstraction is
maybe hiding unnecessary details and
emphasizing necessary concepts
so this is what makes things simple
and then things that are simple can be
made easy
right but this raises the question like
what is unnecessary how does somebody
else know what's necessary to me or not
and that's a good question i think this
is back to comes back to alignment
like are you trying to do the same thing
that the person who made
your language is trying to do if you are
then you're probably going to
come to the same conclusions as they did
about what's necessary and unnecessary
if you're not then you're going to feel
like this thing is in your way
certainly when rich designed closure he
felt this way about java he thought you
know this is
these the the people who design java
their priorities are all wrong i don't
want to program in this way and i'm at
odds with this way of programming so i'm
going to find my own way
well enclosure because it inhabits that
top part of the platform
abstract that the abstraction stack
it's at the very top so a lot of
decisions from top to bottom
are already are made for you already but
in common list
you have more room to make your own
decisions you have more leverage
more rope to hang yourself a lot more
rope
as an example of that commonlist does
not
explicitly does not have offer
a concept of
general equality um
and that's intentional uh the downside
of it is that there's like
half a dozen or more equality operators
and they work on all different types so
this is exactly the kind of
legacy uh corruption
that people point out when they say
common list doesn't have unified
abstractions like it doesn't even have a
single equal
what's up with that that's crazy um
but there's a reason for it
and that reason is in the
hyperspec and i think it's one of the
issues attached to the equal p
or equal um
and this is just philosophically true
there isn't a general way of comparing
to
places in memory for equality um any
choice you make about how to do that is
going to suggest
or imply other constraints on the system
and so in the interest of making as many
things possible in common lisp
as they can they decided not to make a
decision about this
and what this means is that if you want
something like closure style
immutable structures with general
equality you're going to have to make it
yourself or
use library
and this goes back to the tension of
platform versus language on top of a
platform this is
commonlist taking a stand as a platform
and saying we're not going to approach
this
we're going to leave this to the users
and contrast with closures
generally quality operator equal
which you can pretty much use
intuitively in any context where you
situation demands equality
but there are a few costs associated
with this convenience
um you need
uh the fourth one is maybe the
the meatiest one which is um you know
you can extend quality quality to your
own
new objects but when you do that you
need to mutate the list of
uh equality comparator functions inside
closure itself and that's what you're
doing that's effectively what you're
doing when you're
extending an interface in java or if
you're extending a protocol enclosure
oh yeah uh yeah henry baker yeah
yep um yeah so
uh in some of his early talks uh
rich references egal and this is henry
baker's attempt
to who's another original mit list
person
to bring some sanity to common lisps
equality
operations because he he also was
disgusted by the
proliferation of equality functions and
he had an idea about how to make a
better one or at least a more
comprehensive one
but there are trade-offs associated with
his approach
so yeah you know the nice thing about
these abstractions is they
change the economy of using them
and it's either to your advantage or
your detriment depending on
what you're trying to do and if you're
trying to write
a hot you know new parrot numeric type
loop or doing scientific computing
then and you know you're always going to
be working with a particular
you know signed integer or whatever then
this may get in your way more than it
helps you
um maybe i mean again it's it's
contextual
so if i were to like sum up the
conceptual
abstraction differences between closure
i would say in common list i think you
know closure is like this tightly
integrated
beautifully designed internally
consistent
view of how to program and in particular
how to program on a platform like
java or javascript common lisp
it evolved over a long period of time it
has amazing ideas in it those ideas are
not especially artfully
connected but where their connections
dissatisfy you can at least go find out
why
there's always a place to figure out why
like what experience
led to this what was the discussion
behind this why is it that way
and so it's a patchwork it's a very
broad patchwork
and so um that makes it feel kind of
weird
coming from closure honestly and i think
that's why when i would tell people
that i came up with in the closure
community i told them about common list
but i sent them to the hyperspec and
they see that it looks like you know
copyright 1994.
what is this like why are you
looking at this and um yeah so it has a
weird
weird vibe it's old-timey but it's
lovable
endearing and again will never change so
whatever time you spend learning it it's
going to pay a dividend on the long
the long tail
so i've got a list of things
that i am interested in of late um
i think by far the one i'm most excited
about is this project which i'll
see if i can open it up
oh cool it's not loading anyway um
there is a professor in france his name
is robert strand
he is a longtime lisper
and he's known for many uh libraries and
initiatives in the common list community
and like rich he has dedicated
a large part of his life to the pursuit
of the kind of programming that he wants
to do
and so there's always a lot to learn
from such people
and there's a lot to learn from him in
particular he's given a lot of talks
that are on youtube he's written a lot
of papers and all of his papers
are really short and clear relative to
other
papers even even list papers so
everything about this guy and his
projects i'm super into usually um
there's an irc channel on free node it's
the sickle channel where you can
follow what he's doing he checks in
every morning and he says good morning
everyone this is what i'm working on
today
so you have like it's it's kind of
exciting i i'm never
i'm rarely able to offer him any kind of
feedback but i always try to register my
interest
and support um but
he has a really comprehensive and
well-designed plan
to write a new implementation of common
lisp and
for his implementation to have
properties that no other implementation
does
principally
well two things the benefit of hindsight
like the hindsight of multiple
implementations
most of the implementations today are
are
descended from implementations of the
80s
and early 90s that have built into them
certain assumptions about you know
what's efficient
most of them do not use common lisps
highest level abstractions in their
implementation so they're not
strictly speaking they're meta circular
because they are written in lisp
but they're not fully object oriented
using lisp's
best object-oriented constructs
and i'm sorry to use that word but in
lisp it's a good word
trust me um
so his idea is make a new implementation
written in the highest possible level
common lisp that he can
and then bootstrap from the existing
implementations
so what you end up with and what he has
is a set of libraries
that sum up to an implementation they're
just all
beautifully written um and his
implementation of one of commonless
standard macros the loop macro is what
got me into sickle originally so
i can't i can't recommend his stuff or
things related to this project enough
it's like a great source of
really high quality information
and it's exciting because uh i think it
was last week or the week before
he was able to use sickle to either to
load and compile
a large part of a package called
alexandria which is like commonly
standard third-party utility package and
this is like many thousands of lines of
common lisp
using a lot of esoteric features
and so when he was able to load that up
he announced it in irc and i got really
excited because i thought oh
i might be able to use sickle in my
lifetime for sure like maybe even the
next couple years
so that's fun um jackal
is my i mean certainly in comparison to
sickle
hobby pet thing i don't work on this
every day i don't even work on it every
week
it's a long term bet and a lot of it is
educational for me but this is
uh an attempt to bring the common lisp
platform
at least parts of it to javascript and
to think about
those platform impedance issues that i
mentioned having to do with lining up
the data types and lining up the
abstractions and use cases and so on and
so there's a paper that i wrote about
that that
uh that illuminates that
and uh i still i still poke at that most
recently i've been working on multiple
value return
support to be efficient in there which
is the thing i'll talk about
um and yeah i think i'll leave these
other things for you to explore
uh one thing i will
emphasize or one thing i'll highlight is
peter norvig so peter norvig
long time whisper and also
lisp's most famous defector probably
because he famously switched from after
doing decades of common lisp and ai
for ai research to using python and
i think that confused and saddened
many people in this community but
if you click on this video he's
interviewed on a podcast i think two
years ago and he gets into
why he did that uh and he has
a very nuanced perspective and he's a
really smart guy so
any opportunity to watch him speak about
lisp or anything else is you know i
recommend
um i think i'm at a good place to
stop uh this is the end of my slides
my plan was to give you these slides to
give you some background and then we can
whatever time we have we can use for
discussion or questions
or i can do little demos of things
sure that was a delightful
talk i could hear you talk so much
longer you could go forever
um what a joy what a pleasure really
thank you and
i want to say hi to mikhail who came
because i didn't have the opportunity
and uh it's good to see you also
i just want to mention that uh at a
certain time
when uh alan and michael were doing the
boot project
um that's when i i got to contribute a
little bit of my own and i want to say
that it was always such
a um nice interaction with the host
and anybody who is doing open source uh
know how difficult it can be
to you know interact with people the
community
and and and and and make sure that uh
interactions happen on a on on a human
level
um that is agreeable to everyone and
you really did a spectacular job not
only
for myself i i was just also observing
you how you were interacting with the
community and it was really a joy so um
kudos to you and thank you uh
so yeah so i think uh we we could uh go
on and
and um uh go go uh see what uh what the
what kind of questions we have from the
audience
so yeah go ahead shoot sammy hi
somebody wanted to to i heard that look
said leave his
son who was that
slanted no no sorry um i i was just
trying to type until uh so
i can i can just ask it live if you want
yeah sure yes yeah yeah um i i actually
i i um
i think it's you made a great
introduction
um because uh one thing uh where i also
wrote
it's a great slide um where you could
see um
a calmness which more or less takes the
whole stack from
bare metal to space or
um you can you can work on on the in
lisp yeah
you're still in this but you can work on
the nitty-gritty
compiler details where you get uh i
don't know
your virtual operations into the
registers of your of your processor
uh up to highest abstractions uh
whatever
and it's all inside of list and there's
also um
several attempts to to start new
common lisp
[Music]
operating systems so that you really get
from
bare metal to whatever
[Music]
the most recent that i'm aware of is
mezzano
which uh seems to make uh some progress
recently
um what uh what i wanted to ask actually
was um
what other details are so some some
features something like uh of course i
have
some ideas about that but um um what you
think um
makes common list um what do you miss
and closure what commonness pass
well i'm not sure i'm i don't know if i
miss it
but i'm certainly aware of it is
the rebel situation in these two
things um i i should have had a slide
for this
it's an important point which is both of
these languages are very rebel focused
and what i mean by that is everything
about the language supports
interactive development and everything
about
compilation and delivery it accounts for
and admits
it allows for interactive development so
there's a strict concept of a top level
form in both of these languages
and the semantics of the top level form
are the same whether you're
pre-compiling
or whether you're interpreting or
whatever
and this is kind of subtle um
but i think it's a property of the
language that
we take for granted that actually very
few languages have which is such a
low-level compilation unit
the trade-off here is
rich has spoken to this point in hacker
news threats
about single pass versus multi-pass and
so
lisp compilers have always been single
pass in the sense that you feed the
top level forms in and you accumulate
a lisp image inside the computer so what
you're doing is you're
contributing code to a stable
identity which is the lisp image and you
have certain assurances like
if loading a top-level form fails your
image isn't corrupt for example so it's
like a transaction um
so both of the languages have that in
common and this
is different from languages in the
scheme
tradition um which
have broadly speaking and this is a
generalization that i'm not a scheme
expert so feel free to correct me but
one of the things that you have in
common lisp enclosure are first class
packages or name spaces
so that lisp image you're building up
it's introspectible
and there are well there are you know
public
entry points into the database of
information contained in the lisp image
and that's accessible from the reppl
using various functions for looking at
documentation
there are third party programs like list
works that give you uis on top of that
um and in in common lists the probably
the most popular or third party ui is
list works
but there are other ones uh and then in
closure maybe rebel
is um analogous
so those are the ways that the same one
way that they're different
is in terms of the platform
trade-off so in common lisp when you're
at the reppel
um there's a can there's a sophisticated
error handling system called conditions
and there's also a traditional idea of
what a debugger can do
and one of the things that the average
common list debugger can do
is give you a lisp rebel at a place in
the call stack
so like if you it would be like if you
throw an exception in java
and instead of the stack unwinding and
you're seeing a stack trace
execution can actually be suspended in
common lisp and you can have a reply at
the place where the exception was thrown
so you can
inspect local variables you can write
new code that gets run in that same
stack context
which is pretty cool it's pretty cool
and it's i think it's still unique
among languages closure does not have
that you know we have java stacked we
have java exception semantics
and java stack traces um and
at one point when i was learning common
list i reflected on why
i didn't really even once i knew about
the common lisp way why i didn't miss it
in closure
and the best i could come to an
explanation was the most of the closure
programs i was writing
kept their important state in the
database so i was writing mostly web
applications
or writing applications that interacted
with services
and so if i needed to restart my jvm it
was a bit of a pain but it wasn't the
end of the world it's not like my data
of record was in the heap
and turning off the jbm was going to
ruin my day
20 or 30 years ago when lisp machines
were running 24
7 in ai labs and they had persistent
object systems
and the the os the database and your
program were all
in the same computer and even in the
same memory space
um it was much more important that you
had that
depth of debugging capability i think
this is it's not like i have that
experience again i wasn't even born when
people are
programming this way but my perception
is that uh one thing that has changed
about the kinds of programming most
people do is that we generally have
databases now for managing
transactional data but that hasn't
always been the case and when common
lisp
first came into existence it was really
important
to be able to do that kind of very very
surgical debugging
because you might lose data if you
didn't have an opportunity to do it
right then and actually
you can see this in action there's a
youtube video of a screencast
of i believe symbolics
only employee right now so there is
still a symbolic company and they
distribute uh
cds of opengenera and vlm which are
their
it's a it's a list machine virtual
machine and the os on top and they
actually employ someone who used to work
at symbolics
and he did a screencast at a meetup
where he showed how he debugged the
network driver
or something like that and it's pretty
incredible because
like svante is saying you see him go
from like the highest levels of
abstraction
like you know right clicking and
navigating hyperlinks to like
pausing in the stack inside the ethernet
or the network drive the chaos net
driver or whatever he was doing
and like twiddling bits in there and
then
like this is like in the middle of like
he's actually i believe
it was actually like in the middle of a
network
transaction it would be like pausing
linux inside a packet so that you could
you know look at the packet or change
what was going to happen to the pack or
something like that
um so i think yeah i think in our modern
usage of languages that capability isn't
as important
and part of it might be because we've
given up
the need for that because we have we we
rely on the platform you know again to
our
benefit and our detriment if that's
depending on your perspective
but yeah i'll i'll find a link to that
video it's pretty
pretty amazing
yeah um just adding to that um you
mentioned the condition system which i
think is also
a very defining thing there's a
commonest guy who um
recently i think two or three months ago
um just
wrote a little a java library that
implements the common list condition
system in java
so if you if you're interested in that i
posted the link to that
into the
definitely check that out oh foe
yes he wrote a book too didn't he
recently
yes excuse me right right
um cool very cool
kenneth can i just ask
the audience if um we have common
lispers here
who would like to add
anything from their own experience uh
and and just uh you know if if you feel
if you want to say something
please do uh i'm i'm very interested and
probably more more more people are
absolutely
maybe i'll just uh offer a comment um
adam
i think on your last slide you had a
list of things that you
might talk about one was the um symbols
and the
and the package system um when i
so so i had a background in common lisp
when i was learning closure
and i found the way symbols worked in
closure to be
i guess i came in with a bunch of
assumptions that just went weren't
true and i it took me a while to really
understand how
how common this sorry how closure
symbols worked
um i think that they're they're quite a
lot different
to common lisp symbols i just wondered
if you had any any um i guess you've got
some thoughts on that because of
what was on your slide there yes two
thoughts so first of all
uh i don't know about you all but when i
was learning closure
the ns macro took me a really long time
to become comfortable with and i think i
was thinking of it like
you know python's import syntax i took
the syntax
for the thing which you know as you
learn lisp you
realize that the syntax is the front end
for the thing and if you really want to
understand the thing you have to go
beneath the syntax but
um yeah so i was pretty befuddled by the
ns macro and i didn't have my head
around the closure package system and
then i finally did
and i think based on what i've read
about the common list package system i
think there are a lot of the same uh
at least people who are learning seem to
have some of the same problems
but anyway that's that's sort of neither
here nor there that doesn't address your
question exactly
um yeah the big difference the specific
technical difference between the reader
the symbol reader enclosure and the
simple reader and common lisp
is that the common lisp
symbols are interned in the current
package
when they are read so there's no concept
of a
pat of a symbol without a package
and what this means is that you can be
looking at a fragment of code
in a particular global environment and
you can see with your eyes things that
look like they're the same symbol or you
would assume them to be the same symbol
um like you would assume them to be eq
like they're
the same object um but they were
actually interned in different packages
and so they're not eq all even though
textually they may appear to be
eq and that's context dependent and you
can do you can set up situations like
that
by um you know switching the package in
a let binding for example because you
can dynamically bind the current package
which changes there's there's just
actually that's not that's not not a
that may or may not be true maybe i
don't have my head around it completely
but the big the big part is the mutation
of the package
is what happens so when you read a when
you read a closure symbol
um a if a symbol is associated with a
package that information is attached to
the symbol in its symbol syntax and we
have a namespace qualified symbols
there's also a concept enclosure of
referred symbols which
means that closure will interpret
symbols
that it reads without a package to be in
a particular package so you can
establish a mapping
between a packet between a symbol that
doesn't have
a package and a package and you can
install that in your package
if that makes sense but the symbols
themselves
are not installed in particular packages
the the
package environment is not mutated by
the reader
and that if in the closure rationale i
think this is actually mentioned
specifically rich says something to be
effective i don't like that
the reader necessitates mutation because
you know he believes strongly in data
and he believes strongly in
the idea that data should be
require data should not necessitate
interpretation in any way
that's my understanding of the key
difference is the mutation of the
packages when you're reading symbols
follow-on thought is that
mutation uh
is contextual because if you have a
functional programming language and
you're doing a bunch of mutation
inside a function and nobody outside of
the function knows
then do we really care and closure that
idea is delivered with transients
but i think it illustrates a more broad
point which is you know mutation is just
a matter of perspective because when you
run a program you're mutating the call
stack you're mutating pixels on the
screen
you know regardless of what kind of
programming you claim to be
they claim to be doing um so it's just a
question of perspective
and in sickle robert strand
the professor he has a concept
of first class global environments
that he's written a paper about but this
encapsulates the mutation that i just
described
into another concept another abstraction
a higher level abstraction called the
first class global environment
and so now yes the reader mutates but
that mutation is limited to the first
class global environment
so now is it really bad i don't know
again it's a matter of
perspective and trade-offs and so on but
uh that's that that that first class
global
environment thing is kind of a recent
development i think he uh
is still working on that paper
just for the the youtube recording um
people who will not be able to read the
chat uh dave
dave yarwood has this this way of
summarizing at this point
he writes uh if a var is mutated in a
forest and nothing references it
does the value change right
okay and then we have a nice
careful
question uh yeah so
i think we we have to talk about it even
even though
uh if you if you don't i mean feel free
to
to uh to skip it but uh it is
interesting
i find i myself also a bit interested in
what you might say
uh on this topic and that is the uh
uh lisp one of us at least two so um
right well i think you have to address
the fact that closure
that uh that rich hickey coming from
commonly
corrected i think there's an argument
that he made it worse
so let me know this is a fun topic no so
this is another matter of perspective i
think um
you know there is a traditional there's
a classical
understanding of what lisp one versus
lisp two is and it's limited
to uh the interpretation of symbols
but you know there's a lot of dimensions
of interpretation in the programming
language obviously
and if you add other types of atomic
values
you know atoms to this discussion then
for me this point becomes less important
so for example is closure a list one
let's think about this
what does a symbol mean well a symbol
can stand for a locally bound function
but it can also stand for a java class
right
because java class names and closure
symbols intersect
and so there is an if statement there in
the reader
which is a source of complexity
keywords
in practice closure libraries
lean pretty heavily on keywords and even
use keywords to invent new naming
schemes
like to name for example subscriptions
or
conditions like the x info function
a lot of people pass that a keyword to
indicate
you know to identify the condition or
the exception they're throwing
so anytime people use those identifiers
they've created their own global
naming scheme with their own interpretat
you know their own semantics there
so that's kind of a dimension of naming
there is the there is the namespace of
reader macros
enclosure they're data literals but any
package
that you load into the classpath
enclosure has it can
provide a datareaders.clj file which
will automatically get executed and
contribute a data literal syntax to
closure and those have an opportunity to
conflict so i think we're at a lisp four
now
so my point with this is that uh
in my view now this is actually a really
small
and maybe even not very important
distinction between these two things
um because the same is true for common
lisp if you go and catalog all the
different
things that can be named globally or
interfere with each other at a global
level
it's a lot of stuff and
i'm not sure you can get away from
having a lot of stuff i think you're
just going to have a lot of stuff
um for my part i
i think it the lisp2 thing contributes
to the old-timey feel which i
enjoy i haven't written enough lisp code
to leverage any of the
purported benefits i don't think but it
certainly i don't
in the little list code i've written it
i don't feel like it's gotten in my way
but that that is just my opinion
right which is interesting because i i
can
i can uh testify myself that uh the same
way that uh you were
uh drawn to common lisp in in this kind
of uh
oh this looks interesting let's have a
closer look at it
i uh i have this kind of hobby where i
uh
study scheme implementations or at least
uh try to follow what's happening in the
skin world
and trying trying some implementations
on and trying to understand how it works
and understanding the
standard systems serif is and stuff like
that
um and in that respect
the the the major maybe difference
except of course the least is two thing
is that scheme is evolving
because the standard itself it is also a
standard like common list
but it's another that is that is um
that has revisions and which is ongoing
with the committee that is being
um so maybe maybe you want to
to address this this aspect uh just just
uh just a thought like
um scheme is going to change uh
commonly is not so that's interesting
right
well um it's interesting and
strictly speaking is true but uh
i think the implementations of common
lisp have continued to evolve
and because of the culture of platform
interop the culture rather of
implementation
interop um
like for example there's a there's a
fairly recent feature in
a common list called package local
nicknames and that's
enclosure we've had that from the
beginning and that's the ability to give
pac uh namespaces aliases
so you can use um some abbreviated
version of a package name
forward slash and then you know
something some symbol from that package
um but that's not in the common list
standard and so you have to either
deal with you know collisions or fully
qualify
you know and so this is a
feature that all major common lifts have
now
and it's non-standard but in practice
like you can pretty much count on an
existing and
you know that's at odds with the spirit
of the standard
because that is strictly speaking that
is not conformant
you know uh or not um or rather not uh
there there's particular terms that
people in commonlist use when they refer
to different features and whether or not
they're implementation dependent or
conformant um but that adds gray area to
say the least you know it complicates
the situation
um but um
another other thing that comes to mind
is there's a there well there are a few
things there's a sequence of protocol
in uh a you know non-standard but
universally supported sequence protocol
in common lisp um so
which is to say that yeah street
strictly speaking common list for
standard is unlikely to change anytime
soon
but there is movement there is
activity um and uh
you know the culture is what makes it
tolerable to me it's not like other
languages where they're changing or
packages or libraries where they're
changing fundamental things on on a whim
um there is a culture of backward
compatibility which
is here to stay i think
sure anybody else want to chime in
simon do you want to explain a little
bit maybe why um
or how how transitioning from common
list to closure is if
if if that's what you've done
hi um yeah so it's tough to remember a
little bit because it's about
it's coming up for 10 years ago i
suppose um
i'm trying to think if i can say an
interesting intelligence um
uh i think it probably took me a good
while
maybe it's probably a gradual thing but
um there were definitely things i
tripped up on and and and um
i mentioned the thing with with um
symbols and and
packages um so i think
this might not be quite right but i
think one of the reasons why
closure symbols are as they are is
is to make it easier to write hygienic
macros
um now i'd have to think to kind of tie
that back into to what we were talking
about earlier
um but i think
um i think when when you get the thing
with um
uh the symbols being interned at read
time
um i think i'd really have to think
about this but i think that draws you
into
getting um
that's one of the things that makes it
harder to write hygienic macros in
common lips i think
um and so closure's approach i think
part of the rationale for that
was maybe um
to make hygienic macros easier yes
second speak to that relationship
um cool again yeah it's it is a really
complicated part of both languages
um so i could be wrong but yeah in
common list there is a function
and syntax for making what they call
uninterned symbols
and so like the gen sim function in
common list returns one of these
and that's a that gives you an object
that is a symbol type with a distinct
name
and a distinct identity so it's not eq
or identical question mark to any any
other symbol in the system if once you
get it back from gen sim
um and so those identifiers can be used
in code
that you're generating in a macro for
things like the name of something in a
let binding
and that's the um i think maybe that's
what you might be getting at simon
because that's because that thing does
not inhabit a package
uh regardless of the package in effect
when the macro is called
the identity of that symbol is
guaranteed not to conflict with the
identity of any symbols either in the
caller's package or anywhere else in the
in the system and um we don't we don't
need to go out of our way to do that
in closure because the symbols naturally
are uninterned
right yup
santa are you a common whisper or a claw
jeweler yeah
but both in a way i have been doing
communists for longer but
but at work i'm not for five years or so
i'm using closure
um yeah i think um
that's also uh this like dancing thing
is also a
thing which uh interacts with uh this
one or this two
because um if you have this one then you
have a much higher
um or
the the hygiene of a macro is a much
much more important
because um if you uh if you know that
only operators
can be uh shadowed accidentally
then you can be a bit uh you have a lot
more leeway in
in writing your micros um and
you only need to use jensen for your
variables that you introduce in your
macro body
and but in
if you have this one then it's both the
operators and the values and they're all
in the name name space
the variables and the and the operators
um are all in the name
same name space so uh for example you
can't uh
suppose a much more possibility for
conflict
yeah um and so you need to to to be very
careful about gendering anything
um and um so what what closure does is
uh that it includes um the
uh facility that for one every symbol
that you use in a
in a macro body is automatically
fully qualified and it's not the same
well you have to use that or you have to
fully qualify it as
so it's a little bit the other way
around um
and um so um when you
use your um
wait i'm sorry i have to no
really you have to you have to fully
qualify it but the backtech
syntax sugar does that for you yeah so
so it automatically fully qualifies also
the symbols that are in the backtick
body and um you also
have this thing where you can extend a
variable name
used in the macro with a little hash
sign then
there there's the autogensen so there's
this is automatically expanded
uh to a gent name so in effect there's a
little number uh
yeah increasing number it attached to it
so it's always a different symbol
and you get all this hygiene from that
so it's it's
um much easier and closer to write a
really
hygienic macro yeah so so you get all
this
accidental shadowing out of the out of
the way
and in communism you have to be a bit
more explicit about it yeah so you have
to
many macros that are a bit more
complicated
start with uh okay make these gemstones
there's a macro for making jensens
in a more convenient way but
you always use that and um but
you don't have to be so careful about
not accidentally shadowing
um um function names
with your variables yeah you you you
can't
have a led keys something
and uh oh oops uh my keys function is
gone
and that's uh something that uh took me
up and when i came to closure
it was always oh i can't use keys it's
it's a function in the
in the chord yeah i can't uh i can't use
ends because it's
it's a operator in core it's uh
i want to destruction numbers n and ends
oh
damn um wells
uh no you can't say vowels you have to
say values
is okay uh yeah values is okay uh yeah
so
it's uh it's i i feel more restricted by
it being a lisp one um
on the other hand it's of course um
always this thing this funny thing about
um okay if i use higher order functions
and i want to pass a function then i
have to
reference it from the function here so i
have to put this hash science
quote before it to pass it and it's
always a bit more hassle a bit more
why doesn't this work oh i forgot this
and and when i'm
writing a lot yeah and i come to
columbus then i sometimes mix this up
but
uh i didn't know the point that uh for
me
in terms aesthetically high order
functions and at least one is just
this is just elegance uh embodied for me
i mean
to be able to say you know uh map and
then
the name of the function and your
collection that's without
going through the to this uh yeah but uh
that's that's maybe just an aesthetic
point and really not not really
important
well the aesthetics are important i
think to the extent that you know your
your tastes are in alignment with what
you're using because it's only it's only
a pain if you
are forced to use something that yeah
um a suggestion was made to do a rebel
which i
i'd love to do we could oh great
for sure yeah let's do it
i'm glad there are other people here
with actual lisp experience because i'm
a
bit of a fraud in that regard
okay so um
i don't use list books myself for
anything i'll occasionally open it up to
poke around
test things out but i'm glad that it
exists and what it is
is it is a commercial lisp
implementation and ide
and someday i will buy a license to it
because
i think it's neat and i want to support
the work
but the license costs like three
thousand dollars
and i want other things first so
it's not going to happen anytime soon
but you can download this thing for free
and run it
it doesn't have any kind of nagging
features
i think it turns off after two hours or
something like that but it'll warn you
but what it is is it's the closest thing
we have today to the kind of
environment that the whispers of your
had where there were first-class package
browsers
first-class uh you know ui support for
the stuff in common list
um so we can do you know
i've got a what's called a listener over
here a listener is a
is a term you'll see used in the common
list world to refer to a rebel
um but usually the kinds of rebels you
can expect in common lists
are more featureful than what we're used
to in the closure world and i think uh
that's just again part of being the
platform is
they have special affordances
so this is the most important thing to
write first
excuse me my phone is blocking
um
one second i uh just need to turn off my
video
it's a family member who doesn't want to
be seen
will access the pantry behind me
all right everybody still there yeah all
right great
so um right so we have the listener we
can type stuff in
you know everything that we would expect
i'm actually i've been writing closure
code into the reply and it's working
magically
um but we
can let's look at some of the things
that we were discussing
uh we were talking about list one versus
lisp two
so there is a function list
in common lisp and it's very attic takes
things puts them in a list
here i wrote a function called my
function that takes an argument called
list
and returns it um now in
closure this would
this function parameter would shadow
the list function and so
we
let me do this
okay so this is kind of confusing let's
see what it does
weird okay so um
we have an argument list so this is a
lexical variable
which means it is a symbol whose
so a symbol in lisp is a is mutable
in the sense that symbols have a
metadata protocol this is back to a big
significant difference in syntax which
is
in closure you can attach metadata to
almost any
cl anything that's readable
there's some subtlety there into whether
the metadata is copied
if you add something to that like
there's a concept of losing metadata
enclosure like if you
have a vector with metadata on it and
then you conjure something onto that
vector
is the vector you get back does it still
have the metadata
and i think it does in most cases but
there might be cases when it doesn't but
an
area of subtlety and closure in common
list there is no general metadata thing
there's not syntax for it
but symbols are mutable in the sense
that they carry a property list
which is a set of associations between
other symbols and values
and they also have what are
traditionally called the function and
value
cells and these are basically slots or
fields on the symbol
that can either carry a value at some
in some environment or a function value
and by default if you just refer to a
symbol
without any qualification it's the value
cell
that is going to be accessed and so
that's
effectively how lisp ii is implemented
is its admission of the
symbol as a mutable container
and then it's the admission of a
syntactic default
to interpret occurrences
of symbols as accesses of their values
and not necessarily accesses of their
function values
right so in this function we have this
parameter list
lexically it takes the value of the
parameter
that's activated on the stack when it's
activated on the stack
and then so now list is a variable but
look
on this i don't have line numbers here i
have a call to the list function
well because that's a syntax enlist
called an operation form
we have a symbol a list with a symbol
and some number of arguments
that's distinct as a reference to the
function cell of
list and which we can look at
oh whoops
so there's another operator called
function which takes a symbol
and will give you the actual function
value
so that's like the instance of the
function
as opposed to the instance of the name
that
contains the function inside of it um
yeah so it's that this object
is what we're extracting here as the
first argument to apply
so you can see
these two return the same object and
that's because
this hash quote is a
reader macro that basically expands to
this
you can think of it as expanding to that
um yep so this occurrence of list
is not a function call we could say
that's uh the symbol appears in value
position maybe
but you could say whether or not we're
accessing the symbol or the function is
you know syntactically dependent and
lexically dependent
any questions about that
cool maybe maybe you want to show funk
all because
that's the entire of the function
[Music]
oh well there's uh
uh yeah i mean map car
is what closure we know enclosure is map
so um
map car is a higher order function and
it takes
a function as its first argument and
then
a list as its second argument and it
iterates through the list and applies
the function to each element
um i believe so in lisp there's a
concept of designator
which is uh basically
it's kind of like a polymorphism system
in the sense that it
acknowledges that uh intuitively
we want to use a set of objects to
represent the same idea
and in this case the symbol one plus
now strictly speaking this is a a quoted
symbol
but in a context where we were expecting
for the cloaded
symbol to represent a function um
we would want it to designate a function
and so
i think in the case of map car
we could also pass it the symbol one
plus and it will infer for us that hey
i'm passing you the symbol for its for
its use as a function
and so we don't need to wrap it in
so there's a lot of ways to do this and
they're all different variations of
you know this general idea that um
we have a symbol that can have multiple
meanings
and there are different contexts in
which the meanings will be
inferred automatically and but we also
have tools to make
explicit references to aspects of this
symbol
so yeah i mean not very savory honestly
from a closure perspective like these
are all the details that
closure helps us avoid but at the same
time there is some value in
them existing because you have
um uh
you have more flexibility along certain
certain dimensions um foremost among
them is this
lac the fact that this function variable
does not shadow the list function
and so honestly like i'm kind of
refreshed because like
in closure you know you do things like
you have to make you have to you know
you don't want to
shadow close your list so you make a
little variable version or
you know that's better the haskell style
yeah so
yeah yeah uh is it easy
to inspect to inspect the environment
and see
all the symbols as data yeah so
um there are definitely so
in the same way that closure this isn't
going to work
so you know closure offers functions for
inspecting
the global environment looking at
packages looking for things in packages
a common list is the same way there are
functions for doing that i'm actually
going to
share my whole screen
that's not the one i'm looking for
so i'm at the hyperspec
in lisp they refer to
the set of functions and symbols
relevant to some concept as that
concept's dictionary
which i like so this is the packages
dictionary and you can see there's a set
of symbols and each symbol
is defined either by its function
whether it's a function a class macro
variable so we can look at
let's look at find symbol yeah so find
symbol takes a string
a package designator so this is
something that represents a package
now let's let's try this so let's let's
do um
see what it says about this okay
so interesting thing popped up notice
how two lines of output printed
this means that this function returned
two values
which is you know mathematically
bankrupt because what does that mean
but what it is is it's an efficiency
normally in a programming language
there's conceptually a register that a
return value is put into
and a normal programming language
maintains one such register
but common lisp exposes some performance
related features and one of them is this
idea that a function can return multiple
values
and it's based on the observation that
um
a function can box up multiple values
into a list
for example or vector enclosures case
but that means that you need to allocate
a fresh vector that's immediately going
to be thrown away by the consumer it's
going to be destructured and then
gc'd
so if you just have if you have a
concept of multiple values then you can
maintain a set of registers say like a
hundred
and instead of allocating a new vector
when somebody wants to return multiple
things
you just return a special value that
indicates there are multiple values
involved and then you could pass like an
offset into the registers or something
but at the end of the day there's no
allocation happening necessarily
so no pressure on the gc no allocation
and the caller has very fast access to
the values returned
this is somewhat famously not in closure
closure doesn't have multiple values
probably the biggest reason is because
java doesn't have multiple values and
you can imagine how crazy that would be
to
try and do but
closure actually defended his decision
but
richie defended his decision in a
separate way
he a couple years ago maybe like 10
years ago he had a discussion
that there is a
there is a um this is written down but
he had a discussion with cliff
click uh who's a
more or less the implementer of java's
hot spot and
daniel weinreb who is one of the
symbolics founders
and i think wine rebb mentioned to rich
this
lack of multiple values and rich
suggested that
multiple values were not even really
desirable for
performance reasons because of advances
in garbage collection since
um common list was standardized in
particular ephemeral garbage collection
so the cost of allocating something on
the stack from the garbage collector
is very very low nowadays um
on java on on any system that has
different
uh that partitions new objects based on
how long they've been around
and so i objects that haven't been
around for very long are the first to
get collected
usually and so what that means is that
the cost of allocating things is much
lower
in practice at least that was rich's
argument
but anyway in case rich is wrong we have
multiple values in
common lisp and which is what we're
seeing here so find symbols returning
two values
symbol plus and then inherited which is
a keyword that means
it's present in the package as an in oh
uh
ah yes it's inherited through use
package so what this means is that like
we're in a package cl user which is
analogous to closures user
user package and plus is a symbol from
a different package but when we type it
in
without a namespace or a package
qualification
uh in this current package it's going to
be interpreted to mean something else
so it's very similar to closures refer
you know it's the same way that you can
type plus in the username space and it
becomes closures
we can do this so
we can look up the package where the
symbol is installed or interned and it
says the common list package which is
different from the one we're in
um i don't have
a whole lot of time left well no i do
let's see we've been
oh yeah i have to go soon but um
there were a few things i wanted to show
one of one of them was close
common lesson system it's not going to
happen um
but i will show you this which is the
loop macro it's simultaneously
i think one of the
most offensive macros to people coming
from closure and i think also one of the
most illustrative of the differences
between common lisp and closure
but there's a macro in common list
called loop and
let me just write out a thing
all right so
it looks like i'm writing in blub here
right it's like straight up imperative
stuff
um but what this is is this is the dsl
embedded in common lisp and it is a
really
slash complicated language
for performing iteration
so in common enclosure we have lazy
sequences
we have uh recursion we have
uh the loop recur construct for doing
iteration
and those are all functional in the
sense that they don't
imply or they don't necessitate mutation
of anything so you don't need to name
something in order to mutate it so that
you can add something to it
uh lupercur is is like probably closure
is most
i don't know i feel is one of the most
elegant things in closure because
it's a functional iteration construct
and it bottles up
the concept of iteration in an
interesting way i agree and
that's the equivalent of the i mean if
if you had
visuality recursion in the jbm then you
wouldn't
you wouldn't even need the recur you
could you just use the same symbol
that you use to define your liking
scheme you can
do very elegant reversion right right
um so uh
common lisp is not the focus of common
list is not functional programming
um it's not impossible to do but when
it's done it's done by convention and
with the help of libraries
but all of the iteration constructs that
are in common lisp
other than recursion are
uh you know non-functional or at least
admit
mutation uh or imperative stuff into
their
paradigm into their dsl
so loop
is a basically a small programming
language embedded in common lisp
and it's for doing iteration
and i guess you can use it in a
functional way like here we're
collecting a list we're not strictly
mutating anything
but it supports a concept of
oh oops
yeah so
i think i it's not clear to me exactly
what's going on here but
there's multiple keywords supported in
loop four creates
the bounds of an iteration and then when
is a conditional inside the body
do lets you do a side effect at that
point in the iteration and then collect
will contribute a value to an implicit
set of or an implicit list of values
you're accumulating um
i think the yeah the direction i'm going
with this is just that first of all it's
pretty crazy coming from closure
to have this involved of a dsl be
supported out of the box is pretty wild
but i think it also shows and for me it
has shown
that
you there is the value of this deliver
is is this doesn't rely on any runtime
abstractions
so there's no need for a lazy sequence
abstraction
loop expands into the lowest
level possible common lisp code like
basically go to
is what it expands into go to's with
mutating and
cutters and stuff like that so it's high
level in the sense that it gives you a
high level language to work with
that looks pretty much like python or
something
but it's low level in the sense that
it produces code that depends on only
commonly lowest level runtime
affordances
and that's a trade-off obviously
you know this doesn't participate in a
system of runtime constructs or
distractions the way sequences enclosure
do
but at the same time you're not paying
for such a system
so um yeah just kind of conceptually
interesting
thing that occupies a point in a design
space that i don't think we
use or are supposed to use enclosure
because we have lazy sequences and
recursion and so forth if that makes
sense
cool well i think with that
i should probably go but maybe i'll take
one more question
i'm not sure we have the time for that
but
i can't help asking
the one thing you didn't talk about and
are in this whole universe of yours
oh yeah well
i i enjoyed working with r and
i think r is i mean
by mccarthy's definition r is a lisp i
mean it is written
in data structures that you have
accessible
at runtime and it's an online compiler
and everything um
i think r so
i did not find myself getting obsessed
with it the way that i am obsessed with
common lisp
i don't know why that is i don't know if
it's because i'm just immune to being
obsessed with things that are popular
um i i don't know i i certainly never
really had any problems with r and i
think it
occupies again another point in the
design space that's very valuable to
lots of people
um an interesting thing about
maybe you need s expressions in your
life say that again
maybe you need s-expressions in your
life
maybe maybe that's what it is yeah i
think
um you know like common lisp
r is also has kind of an old-timey feel
it's descended from a pretty old
language called s
and um the ideas go back decades
and uh that's fun
bye tori thanks for coming um
there is a very interesting thing about
r that is unique to r
among lisps and among all languages that
i've ever known which is that r has
f expressions fespers so
r is a call by need language and lazy
evaluation
and ours so you know common lisp has
first class a lot of things that come
unless our first class but one thing
that's not for
first class is the lexical environment
which is that
inside a function you don't have access
to that function's lexical scope
that's all been compiled away into
identifiers that are gone by the time
your function actually runs
so this is something the compiler
manages for you at compile time
but in r the environ the runtime
environment of a function
is attached to the function object and
you can actually
look at the variable the lexical
variables inside a function like from
the reply
and even modify them so like if inside a
function body there's imagine like
there's a let binding
and the outermost let in the function
binding says x1 and then there's a bunch
of stuff
in r you can do the moral equivalent of
after that function has been defined go
in there mutate
its environ internal environment um
which uh you know again pretty egregious
from the closure functional perspective
i think that's possible
but uh it also gives you a level of meta
programming capability
that is i think unparalleled uh
except by other lips so
um very very interesting language um
and i think you know the the reason
that f expert thing did exist in lisps
for decades before common list and i
think it was thrown out for performance
reasons
long before common list came to be
standardized um
but one thing that this is kind of
another observation i have is that
um there's a concept of computer
performance and there's a concept of
human performance and
it's okay for something to have very
poor computer performance
if it unlocks some kind of human
performance because
yes our relatives are things kind of
slow because of this first class
environments thing
but you can use it to make a really nice
dsl on top of something that's written
in c
plus for example so it gives you
a testbed in which to prototype
uh constructs and semantics that are
valuable to people
and then later if at all you have a
layer on which you can make those things
more efficient
and it makes me regret that not adding r
to my little platform and abstraction
level
chart like that's sort of a bar chart
really um
you know r sits even higher than closure
maybe
on the on or well i guess it's a it's
complicated i have to think about that
more
but um it too offers semantic
affordances at a very high level
and there are trade-offs with the ones
it does offer
and it occupies a unique like closure
occupies a point in the design space
that has benefits for people who do a
certain kind of thing or like a certain
kind of thing
yeah i still really like it and
i uh i enjoyed the process of learning
it it also it
also light closure is significantly
influenced by common lisp
which is fun so it's kind of a sibling
to closure in that way with that
i think i shall leave you fine people do
your own programming
that was a phenomenal talk thank you so
much
thank you everyone yep thank you i
enjoyed that
you're very welcome yeah thank you so
much for coming and uh yeah i'll
i'll send the slides to the daniels and
um
and there's links on there on how to
contact me and stuff to look at and so
forth but uh
uh yeah thanks for coming thanks for
watching