The Last Programming Language
TimDaly
programming language.
http://skillsmatter.com/podcast/agile-testing/bobs-last-language
Steven Tomcavage
all hackers and we all have a notion that things could be done better
if we just tweaked this or that a bit, and voila, you have a new
programming language.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
Ken Wesson
I don't see how that claim can be drawn from the textual content on
that page. He mentions Clojure exactly once, not as a candidate "last
programming language" but merely as an example, among several, of
languages that seem to be rediscovering the past (i.e. long-underused
language families like the Lisps, MLs, etc.). If he's arguing that
Clojure, specifically, could be it, modulo incremental refinements,
it's not in the text on the page you linked to.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
daly
Ken Wesson
> Watch the video.
What video? The only video I see linked from there is over an hour
long. Obviously you can't mean that one, since no one around here has
that kind of spare time at this hour on a Tuesday. :)
daly
The trailing conclusion of the video is that Clojure
The video reprises Gabriel's paper of the same title.
Bob Martin reminds me of James Martin from the 70s,
for those of us old enough to remember him. I wonder
if they are related.
Tim
craig worrall
Maybe. Or maybe Martin's talk should be entitled
"The Last Programming Language To Get Any Mind-Share".
On Jul 19, 3:42 am, Steven Tomcavage <ste...@tomcavage.com> wrote:
> I double we'll ever see The Last Programming Language, because we're
> all hackers and we all have a notion that things could be done better
> if we just tweaked this or that a bit, and voila, you have a new
> programming language.
>
Adam Richardson
On Mon, Jul 18, 2011 at 1:36 PM, TimDaly <da...@axiom-developer.org> wrote:
> Robert Martin argues that Clojure could be the seed of the lastI don't see how that claim can be drawn from the textual content on
> programming language.
>
> http://skillsmatter.com/podcast/agile-testing/bobs-last-language
that page. He mentions Clojure exactly once, not as a candidate "last
programming language" but merely as an example, among several, of
languages that seem to be rediscovering the past (i.e. long-underused
language families like the Lisps, MLs, etc.). If he's arguing that
Clojure, specifically, could be it, modulo incremental refinements,
it's not in the text on the page you linked to.
Ken Wesson
> Watch the video and you'll see the comment Tim is referencing.
Are you aware of the length of that video?
Colin Yates
--
Ken Wesson
> I find his videos very easy to watch - I think it was around a hour, but the
> time flies by.
An hour of Will Smith blasting aliens "flies by". An hour of a talking
head is better presented as text. An hour of talking head + slides is
better presented as text + inline images. Particularly since text is
searchable and video, for the foreseeable future, is not. :)
Ben Smith-Mannschott
> On Tue, Jul 19, 2011 at 10:05 AM, Colin Yates <colin...@gmail.com> wrote:
>> I find his videos very easy to watch - I think it was around a hour, but the
>> time flies by.
>
> An hour of Will Smith blasting aliens "flies by". An hour of a talking
> head is better presented as text. An hour of talking head + slides is
> better presented as text + inline images. Particularly since text is
> searchable and video, for the foreseeable future, is not. :)
True enough, though I should hasten to point out that Uncle Bob is an
unusually entertaining "talking head".
// ben
Colin Yates
gaz jones
a big will smith fan??? not that i know you at all other than reading
your posts here, but i really didnt see that coming...
Sean Corfield
> What video? The only video I see linked from there is over an hour
> long. Obviously you can't mean that one, since no one around here has
> that kind of spare time at this hour on a Tuesday. :)
Yes, an hour. It's an excellent talk. There's a higher quality video
of his NDC talk on this topic (same conclusion, different anecdotes)
but that needs to be downloaded and then skip the first five minutes
as they had the camera running before the talk started:
http://ndc2011.no/agenda.aspx?cat=1071&id=-1&day=3726
Ken, you might be surprised what an hour's investment will bring :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Alan Malloy
> > What video? The only video I see linked from there is over an hour
> > long. Obviously you can't mean that one, since no one around here has
> > that kind of spare time at this hour on a Tuesday. :)
>
> Yes, an hour. It's an excellent talk. There's a higher quality video
> of his NDC talk on this topic (same conclusion, different anecdotes)
> but that needs to be downloaded and then skip the first five minutes
> as they had the camera running before the talk started:
>
> http://ndc2011.no/agenda.aspx?cat=1071&id=-1&day=3726
>
> Ken, you might be surprised what an hour's investment will bring :)
really think it was worth the time. I would sum it up for Ken as:
Wouldn't interoperation be great if we all used the same language,
like mathematicians do? Such a language would have to be really good,
with features XYZ [no particular motivation for why all these features
are good]. I can't think of any other features we could possibly want,
either, because we seem to have already had all the interesting ideas
in language design. Look, Clojure has all of these features! It might
be a good start towards language standardization.
Brian Hurt
know very well, but I've never heard of this awk-a-mel. :-)
Seriously, his pronunciation of "ocaml" highlights, I think, the core
problem of his talk. There has been significant development in
languages, just not in the popular languages. It's been over there in
the "fringe" languages.
Alan Malloy
> What's this awk-a-mel he speaks of? Ocaml, pronounced oh-camel, I
> know very well, but I've never heard of this awk-a-mel. :-)
>
> Seriously, his pronunciation of "ocaml" highlights, I think, the core
> problem of his talk. There has been significant development in
> languages, just not in the popular languages. It's been over there in
> the "fringe" languages.
and I *thought* his pronunciation of ocaml was wrong, but I was left
with some uncertainty since I wasn't that confident to begin with.
Adam Richardson
What's this awk-a-mel he speaks of? Ocaml, pronounced oh-camel, I
know very well, but I've never heard of this awk-a-mel. :-)
Seriously, his pronunciation of "ocaml" highlights, I think, the core
problem of his talk. There has been significant development in
languages, just not in the popular languages. It's been over there in
the "fringe" languages.
daly
Adam Richardson
What's this awk-a-mel he speaks of? Ocaml, pronounced oh-camel, I
know very well, but I've never heard of this awk-a-mel. :-)
Seriously, his pronunciation of "ocaml" highlights, I think, the core
problem of his talk. There has been significant development in
languages, just not in the popular languages. It's been over there in
the "fringe" languages.
daly
Homoiconic representation is fundamentally important and lacking
in other languages. The programs == data idea is what makes the
macro facility work, allows dynamic program construction, compile
to core, etc. There is a story going around that McCarthy attended
a python talk where they made the claim that python IS a lisp-like
language. John pointed out that if it lacks homoiconicity it cannot
be a lisp. (I probably have the details wrong).
OCaml came from ML but the ideas came before either one. Lisp supported
functional programming long before either language. I believe the point
Robert was trying to make was that very few languages have increased our
stock of fundamental ideas. OCaml is not one of them.
Indeed languages (like Spad) built on lisp STILL support ideas I have
not seen anywhere else (e.g. dispatching on the return type as well as
the argument types).
Robert suggests that we need to develop a standard language.
Good luck with that.
I participated in the reviews of the X3J13 Common Lisp standard
(behind the scenes by passing on my comments and markups to people who
had the proposal directly). Trying to define a "standard programming
language" would be the ultimate language war. It has been tried several
times before (PL/I included everything and C++0xxxxx is trying hard to
include everything).
At best I believe we will muddle along and I will continue to be
rejected during job interviews for working in python 2.7 and not
"knowing" python 3.0. Forty years of lisp programming just makes
me too old to hire for any "real" programming job. Heck, I probably
don't know the difference between OCaml and awk-a-mel so I clearly
cannot program. :-)
>
>
> I don't need to know how many digits somebody can recite Pi to, but I
> would like to know how his experience with awk-a-mel lead him to
> believe that functional programming comes down to protecting variable
> assignment :)
>
>
> That all said, if Clojure is the seed for the last language, I'd be a
> happy man.
I believe that Robert missed the fundamental point though. It is
NOT just the space of ideas that makes lisp "the right language".
Another key reason is "impedance matching". (An impedance mismatch
is when you hook a soda straw to a firehose).
Programs exist to bridge the gap between the idea domain and the
machine domain. Some languages are close to the machine, like assembler,
so you have to "carry your idea" all the way to the machine. Some
languages are close to the problem (e.g. Mathematica) but the compiler
has to cross the gap to the machine. This is where the ability to
create domain-specific languages in the same syntax matters.
Lisp is the only language I know that allows you to work across the
whole spectrum in a single language. It is possible to say
(integrate (car x))
which takes the 0 displacement off the x pointer (machine) and then
does a mathematical integration routine (problem) and does it all with
the same syntax and semantics.
I wouldn't worry that we will stop creating new languages.
We have yet to explore the space of unicode replacements for the
semi-colon (although Fortress is starting). Kanji semi-colons.
I can't wait!
Tim Daly
Adam Richardson
On Tue, 2011-07-19 at 20:14 -0400, Adam Richardson wrote:
> On Tue, Jul 19, 2011 at 6:23 PM, Brian Hurt <bhu...@gmail.com> wrote:
> What's this awk-a-mel he speaks of? Ocaml, pronounced
> oh-camel, I ...
>
>
> I will confess that as I listened to the presentation (when I got the
> email with Tim's link, I just started the video while I was working on
> some drudgery), I felt like he missed some of the language features
> promoted in functional languages.
>
>
> He worded functional programming contributions in terms of advancing
> the idea of limiting/protecting variable assignment (immutability),
> and to me, that's missing the points of first class functions (which,
> in light of what he says OOP languages brought to the table, actually
> provided protected function pointers through purely functional
> languages without any need for OOP) and an emphasis on function purity
> and limiting the scope of unpure functions (to me, this goes beyond
> merely protecting assignment.)
>
>
> These omissions, coupled with the mispronunciations of functional
> programming language names, and the value placed on the last language
> being homoiconic (without much justification) had me wondering how
> much he actually has used languages such as OCaml or Haskell.
Homoiconic representation is fundamentally important and lacking
in other languages. The programs == data idea is what makes the
macro facility work, allows dynamic program construction, compile
to core, etc. There is a story going around that McCarthy attended
a python talk where they made the claim that python IS a lisp-like
language. John pointed out that if it lacks homoiconicity it cannot
be a lisp. (I probably have the details wrong).
Metaprogramming requires, at the least, that we have true first-class functions in the strict sense of the term, that is, that we be able to generate new functions whose behavior is determined dynamically. A homoiconic language can simplify metaprogramming [emphasis added] by eliminating the need to translate between internal (data structure) and external (syntactic) representations of programs or program extensions. (p. 563)
daly
Indeed it is ALMOST possible to do some things by referencing the
abstract syntax tree version of Haskell. If the AST version were
the actual language of Haskell you could build the syntactic-sugar
version on top of it. Unfortunately, they started the other way
around.
And, you'll note, the Template Haskell language has various
restrictions (e.g. non-recursive, separate files, etc) that make
it not-quite-first-class Haskell. This is more than a matter of
syntactic elegance. There are things you simply cannot do by
machine that you can do by hand (well, technically you can but
only with a lot of special case programming).
Eventually you need a Haskell parser you can invoke at
compile time. One of my AI programs "learned" by doing self
modification at run time. It rewrote itself to optimize the
cases and saved the changes. During execution, the program
gradually shifted until the code I originally wrote no longer
existed. I can't imagine doing that in Haskell or C++ or any
other language except maybe assembler.
A standard example is to write a dumb Rubics cube program that
rewrites itself when it discovers a shorter solution. You can
do this by interpreting a data structure but in lisp, the program
IS the data structure. It is fun to watch the program learn.
It is a shame we don't teach students to do this.
Imagine what Google COULD be if they bothered to unify programs
and data, letting Google learn by itself. But that is probably
too much science for an "engineering company". They need a few
more lispers on staff. Sigh.
Tim Daly
>
>
> Interesting points.
>
>
> Adam
Sean Corfield
> the value placed on the last language being
> homoiconic (without much justification)
Yeah, that was definitely a weak point of his talk. I thought there
was a lot of interesting stuff in there tho' and it was entertaining
(which was mostly why I enjoyed it - so many talks, even keynotes, can
be pretty dull even if the information is good :)
Ken Wesson
> NOT just the space of ideas that makes lisp "the right language".
> Another key reason is "impedance matching". (An impedance mismatch
> is when you hook a soda straw to a firehose).
>
> Programs exist to bridge the gap between the idea domain and the
> machine domain. Some languages are close to the machine, like assembler,
> so you have to "carry your idea" all the way to the machine. Some
> languages are close to the problem (e.g. Mathematica) but the compiler
> has to cross the gap to the machine. This is where the ability to
> create domain-specific languages in the same syntax matters.
>
> Lisp is the only language I know that allows you to work across the
> whole spectrum in a single language. It is possible to say
> (integrate (car x))
> which takes the 0 displacement off the x pointer (machine) and then
> does a mathematical integration routine (problem) and does it all with
> the same syntax and semantics.
+1 to all of this.
> I wouldn't worry that we will stop creating new languages.
> We have yet to explore the space of unicode replacements for the
> semi-colon (although Fortress is starting). Kanji semi-colons.
> I can't wait!
I sure can. I never intend to use any language I can't type without
meta keys and/or a special keyboard. :)
Nick Zbinden
and a very powerful macro system.
http://users.rcn.com/david-moon/PLOT/
daly
> On Tue, Jul 19, 2011 at 5:14 PM, Adam Richardson <simpl...@gmail.com> wrote:
> > the value placed on the last language being
> > homoiconic (without much justification)
>
> Yeah, that was definitely a weak point of his talk. I thought there
> was a lot of interesting stuff in there tho' and it was entertaining
> (which was mostly why I enjoyed it - so many talks, even keynotes, can
> be pretty dull even if the information is good :)
A justification of homoiconicisty is that programs == data.
A clever soul named Von Neumann made the observation that machines
were controlled by external commands (i.e. programs) to operate on
things (i.e. data). His insight was to unify the problem and treat
programs as data resulting in the invention of the stored program
computer.
If you completely separate something like a loader (program) from
its data (the binary program) then there is no way to treat the
program-you-load as the-program-to-run.
Today we teach students to write "programs to manipulate data" so we
have returned to the pre- Von Neumann mindset. It is considered the
height of bad form to execute data. In fact, some bright spot
added SELinux with the default policy that you could not
execute code from the heap!
Robert gave an example of self-modifying behavior with the IBM
move instruction where he talked about modifying the length field
dynamically. In fact, the IBM 370 included an EX instruction that
executes another instruction with modifications. Both of these are
easy to do since the program and the data have the same binary
representation.
In your best language (e.g. C++, Python, Ruby, etc) can you write
a program that modifies itself in the source language (e.g. C++)
while continuing to execute? Would this be considered a bug during
code review? (Fortran used to allow me to write over the FORMAT
output string which allowed me to change the output format based
on the data.) If you do write a self-modifying program, did you
have to write a C++ parser first? In lisp, all you have to do is
walk the program as a list, rplaca the target sublist, and continue.
Fortunately someone at Sun was able to cross this barrier when they
decided to write the hotspot JVM. Hotspot self-modifies as it runs
to improve performance, similar to the Rubics cube program I
mentioned previously. I wish they had been mindful enough to make
Hotspot a fundamental part of Java itself. We would be able to write
Java programs that self-optimize in ways that Hotspot cannot know
by accessing and rewriting our own byte codes. If someone reifies
the byte codes in lisp syntax it would be easy to write programs
directly on the JVM that look like lisp, compiles to byte codes,
and could be self modified.
Homoiconicity is Von Neumann's insightful idea that
programs == data
daly
Vivek Khurana
<snip>
>
> A justification of homoiconicisty is that programs == data.
>
> A clever soul named Von Neumann made the observation that machines
> were controlled by external commands (i.e. programs) to operate on
> things (i.e. data). His insight was to unify the problem and treat
> programs as data resulting in the invention of the stored program
> computer.
>
> If you completely separate something like a loader (program) from
> its data (the binary program) then there is no way to treat the
> program-you-load as the-program-to-run.
>
> Today we teach students to write "programs to manipulate data" so we
> have returned to the pre- Von Neumann mindset. It is considered the
> height of bad form to execute data. In fact, some bright spot
> added SELinux with the default policy that you could not
> execute code from the heap!
You are spot on with this. We have built a whole army of programmers
who would manipulate data instead of transforming data. Sooner or
later this practice results in bloated code.
regards
Vivek
--
The hidden harmony is better than the obvious!!
Luc Prefontaine
I worked a lot in several assembler implementations in the 80/90s and creating
self-rewriting code was still common.
I remember creating a program crawling in memory on an IBM 370 compatible computer
by copying itself before jumping in its new instance, I wrote this one as an amusement :)
I never considered data and code to different things. This was imposed on me when working
with other "high-level" languages except Lisp for with which I always felt more affinities.
When you look at code and data as being the same, things are much more simple to understand
and easier to deal with.
Divide to conquer they say... I think this division created faked walls that slowed down improvements
in software in general.
Luc P.
--
Luc P.
================
The rabid Muppet
Jeff Dik
Perhaps the last 6 or 7 paragraphs to
http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html?
Jeff
daly
Yes, that's the story. --Tim
Nick
Ouch.
This is an appeal for posters to think of their readers and trim for
readability. In this style, even having scrolled several pages and found one
insertion, there is no guarantee...
>>
>>>
>>> OCaml came from ML but the ideas came before either one. Lisp supported
>>> functional programming long before either language. I believe the point
>>> Robert was trying to make was that very few languages have increased our
>>> stock of fundamental ideas. OCaml is not one of them.
>>>
>>> Indeed languages (like Spad) built on lisp STILL support ideas I have
>>> not seen anywhere else (e.g. dispatching on the return type as well as
>>> the argument types).
>>>
>>> Robert suggests that we need to develop a standard language.
>>> Good luck with that.
>>>
>>> I participated in the reviews of the X3J13 Common Lisp standard
>>> (behind the scenes by passing on my comments and markups to people who
>>> had the proposal directly). Trying to define a "standard programming
>>> language" would be the ultimate language war. It has been tried several
>>> times before (PL/I included everything and C++0xxxxx is trying hard to
>>> include everything).
>>>
>>> At best I believe we will muddle along and I will continue to be
>>> rejected during job interviews for working in python 2.7 and not
>>> "knowing" python 3.0. Forty years of lisp programming just makes
>>> me too old to hire for any "real" programming job. Heck, I probably
>>> don't know the difference between OCaml and awk-a-mel so I clearly
>>> cannot program. :-)
>>>
...that I have found them all....
>>>
>>>>
>>>>
>>>> I don't need to know how many digits somebody can recite Pi to, but I
>>>> would like to know how his experience with awk-a-mel lead him to
>>>> believe that functional programming comes down to protecting variable
>>>> assignment :)
>>>>
>>>>
>>>> That all said, if Clojure is the seed for the last language, I'd be a
>>>> happy man.
>>>
...so I have the scan the whole abominable nest of quotes!
>>> I believe that Robert missed the fundamental point though. It is
>>> NOT just the space of ideas that makes lisp "the right language".
>>> Another key reason is "impedance matching". (An impedance mismatch
>>> is when you hook a soda straw to a firehose).
>>>
>>> Programs exist to bridge the gap between the idea domain and the
>>> machine domain. Some languages are close to the machine, like assembler,
>>> so you have to "carry your idea" all the way to the machine. Some
>>> languages are close to the problem (e.g. Mathematica) but the compiler
>>> has to cross the gap to the machine. This is where the ability to
>>> create domain-specific languages in the same syntax matters.
>>>
>>> Lisp is the only language I know that allows you to work across the
>>> whole spectrum in a single language. It is possible to say
>>> (integrate (car x))
>>> which takes the 0 displacement off the x pointer (machine) and then
>>> does a mathematical integration routine (problem) and does it all with
>>> the same syntax and semantics.
>>>
>>> I wouldn't worry that we will stop creating new languages.
>>> We have yet to explore the space of unicode replacements for the
>>> semi-colon (although Fortress is starting). Kanji semi-colons.
>>> I can't wait!
>>>
>>> Tim Daly
>>>
>>>
Ta, N
Alan Malloy
> On 22/07/11 05:30, daly wrote:
> > On Thu, 2011-07-21 at 23:03 -0400, Jeff Dik wrote:
> >>> On Tue, 2011-07-19 at 20:14 -0400, Adam Richardson wrote:
wrong, I don't like the style of this thread either, but by default
your post looks to me like:
Ouch.
This is an appeal for posters to think of their readers and trim for
readability. In this style, even having scrolled several pages and
found one
insertion, there is no guarantee...
Sounds like you might be happier if yours did this too.