I claim that Lisp will rise again - and sooner than later, it will do
so from an unexpected cross between knowledge and end user programming.
As computation infuses nearly every aspect of the modern world, the
need for domain specific communities to develop their own programming
paradigms (approx. domain-specific programming languages) will explode.
Lisp is ideally suited to this; indeed, it is the only language ideally
suited to this because of its unique extensibility, combined with its
simplicity. Moreover, what the user communities of the near future will
want to do with computers is not numerical computation, but some
combination of interface development, device control, and, most
importantly: knowledge processing. The paradigm for interface
development is in process of being worked out in the now pervasive
client-server model of web browsers. On the client side of this
equation, Javascript reigns supreme as (the closest thing we have to)
an end-user programming language. On the server side, one does whatever
works, and at the moment - in the world of the mega-servers - C and
its kin are the fashion. But, Google not withstanding, the days of the
mega servers are numbered. In the same way that the IBM PC defeated the
IBM mainframes in the 80s, personal computers in a different form will
defeat Google in the 2010s. The desktop will remain, although it is
already becoming a home-wide media center, and wireless devices ranging
from cell phones to cell cars to cell toasters will pervade the
computation landscape - peer to peer sharing and, more importantly
for the present discussion, *personal knowledge programming* will
become the fashion to replace the "vending machine" model of
computing that we see today (where we fill in some fields, and get an
answer back, and that all she wrote). People will, I claim, want to
make these devices do things that they weren't preprogrammed to do
"at the factory" - and that the things they will want them to do
are knowledge-based things They will want their music to turn down when
their baby monitor starts to register sounds of restlessness; They will
want the phone to screen calls from anyone who isn't in their myspace
best-friends list, and only some of them when they are trying to get
work done; They will want podcasts related to their favorite topics of
interest to be autoloaded into their media player, and played in
particular orders throughout the day when relevant. They will want the
car stereo to play certain sorts of music when they are in certain
parts of their commute, and to turn down when they are in difficult
traffic. These are knowledge programming problems - simple or not so
simple - and demand huge numbers of domain specific knowledge-facile
programming languages, all of which talk to one another, to implement.
Of course, not everyone will program in these languages, and even fewer
will develop such languages, but, given the right tools, a wide range
of people who are not now, and will never program in C or anything like
it, can and will develop such languages, and a wider range of people
will program in them to make their coffee-maker understand when they
are in a bad mood because of the music they're listening to and so
need a stronger shot. My claim is that Lisp is ideal situated to play
this role. Crazy as it may sound, I believe that people will, in the
near future, plug a keyboard into their car and enter s-expressions -
of course, they won't know they're programming in Lisp - to them
it will just be The Car Language, The Home Media Language, The iPod
Language, The Dishwasher Langauage -- and it may not be literally
s-expressions - maybe it will be a visual programming language that
compiles to s-expressions, but it will amount to the same thing -
they'll be talking to a lisp system and posting their specialized
lisp-based device functionality online - maybe even on an ebay, and
maybe get paid for the clevel ones. Moreover some (a samller number)
will learn to use macros to extend this sort of programmability to the
syntax of the languages themselves, make them even simpler for the real
users: parents and kids and teachers and students - to program for
themselves.
········@gmail.com writes:
> As computation infuses nearly every aspect of the modern world, the
> need for domain specific communities to develop their own programming
> paradigms (approx. domain-specific programming languages) will explode.
> Lisp is ideally suited to this; indeed, it is the only language ideally
> suited to this because of its unique extensibility, combined with its
> simplicity. Moreover, what the user communities of the near future will
If the views of Joel Spolsky are representative of mainstream
developers, this is indeed the way to go, but throwing enough
greenspunning to the problem can apparently reduce the need for Lisp:
http://www.joelonsoftware.com/items/2006/09/01b.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
I think he's talking about a slightly different (although related)
thing. His company (apparently) developed a product with a specialized
language for IT people who install his product to use. You can expect
them to be slightly computer competent -- able at least to write a
couple of lines of BASIC code. The same is true for nearly all
specialized programming languages these days -- they're still
programming languages that you need to be a programmer to use. What I'm
talking about it beyond that -- it's a programming language for the
masses. Google (and other search engines) is a near miss on this
concept. When you put a search into Google (etc) you are essentially
populating the test in the following function:
(sort
(loop for page in (the-whole-web)
when (search "my-string" page)
collect page)
#'page-rank)
[Yes, I know it's not that simple! Not relevant here!]
What I'm talking about is what would happen if Google (and other
non-centralized applications -- indeed, if ALL applications!) let you
put in that whole chunk of code. If you could do THAT, then you could
also do:
(sort
(loop for page in (the-whole-web)
when (search "my-string" page)
collect page)
#'> :key #'page-date)
or:
(sort
(loop for page in (the-whole-web)
when (and (search "my-string" page)
(> (length page) 1000))
collect page)
#'> :key #'page-date)
and so on. Even better, you could define macros, thereby letting
everyone else in the world do things you'd invented!
This is what we do in the KnowOS, and more particularly in BioBike --
it's an open programming environment where the biologist/users can
program up their own queries and even make their own biological
domain-specific sublanguages! Few of them actually do this, but some
do, and so I made my initial hyper-caffeinated remarks in the same
vein, but where the KnowOS model is expanded beyond KnowOS/BioBike, and
even beyond servers, to the distributed world of embedded computing.
... I think, anyway.... maybe I just need to increase my meds.
On 3 Sep 2006 15:22:49 -0700, ········@gmail.com wrote:
>
> What I'm talking about it beyond that -- it's a programming language
> for the masses. Google (and other search engines) is a near miss on
> this concept.
Programming is inherently a specialized skill. Otherwise, you
wouldn't see people making jokes about not bothering with all
the bells and whistles on their VCRs; some people are control-freaks
but most people couldn't care less. It's not that they wouldn't
love to have their VCR know what they want to do, it's that they
don't have the time or patience for telling it what to do.
I believe you want to gather data by extension of interfaces
that people already know how to use, and then apply that data with
some form of reasoning or data mining system. Think about what
the true purpose of an online social networking system, and
how those systems achieve their goals -- they do it by convincing
people to give up information that they don't realize they're
giving up, and rewarding them to do it; and they aggregate a
bunch of seemingly-unrelated data and make money that way.
Google was (dunno if it's fair to say still is) a major step
forward because they spent a lot of time identifying user
types and refining their UI accordingly. Most people do not
use the advanced search capabilities; some people have a hard
time distinguishing between Google's search field and their
browser's address bar.
I do think Lisp is a key to future technical advancements,
but no way can I see my parents ever typing sexpr's into
a keyboard attached to their VCR.
--
Jack Unrue
Jack Unrue wrote:
> Programming is inherently a specialized skill. Otherwise, you
> wouldn't see people making jokes about not bothering with all
> the bells and whistles on their VCRs; some people are control-freaks
> but most people couldn't care less. It's not that they wouldn't
> love to have their VCR know what they want to do, it's that they
> don't have the time or patience for telling it what to do.
> [..]
> I do think Lisp is a key to future technical advancements,
> but no way can I see my parents ever typing sexpr's into
> a keyboard attached to their VCR.
My thoughts aren't settled on this, but the original post reminds me
that Richard Stallman claimed at a Lisp conference:
"Multics Emacs proved to be a great success -- programming new editing
commands was so convenient that even the secretaries in his office
started learning how to use it. They used a manual someone had written
which showed how to extend Emacs, but didn't say it was a programming.
So the secretaries, who believed they couldn't do programming, weren't
scared off. They read the manual, discovered they could do useful
things and they learned to program.
"So Bernie saw that an application -- a program that does something
useful for you -- which has Lisp inside it and which you could extend
by rewriting the Lisp programs, is actually a very good way for people
to learn programming. It gives them a chance to write small programs
that are useful for them, which in most arenas you can't possibly do.
They can get encouragement for their own practical use -- at the stage
where it's the hardest -- where they don't believe they can program,
until they get to the point where they are programmers."
http://www.gnu.org/gnu/rms-lisp.html
Also, we can observe the most popular programming notation is the
HTML/XML family, which has obvious similarities to sexps. (Some might
dislike me calling *ML "programming", but we're in a context where
we're discussing data-driven programming.)
http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf
But certainly you make interesting points on interfaces... there are
certainly serious people out there gunning to improve the
human-computer interface, and perhaps some of them will be successful.
Tayssir
On 3 Sep 2006 16:53:24 -0700, "Tayssir John Gabbour" <···········@yahoo.com> wrote:
>
> Jack Unrue wrote:
> > Programming is inherently a specialized skill. Otherwise, you
> > wouldn't see people making jokes about not bothering with all
> > the bells and whistles on their VCRs; some people are control-freaks
> > but most people couldn't care less. It's not that they wouldn't
> > love to have their VCR know what they want to do, it's that they
> > don't have the time or patience for telling it what to do.
> > [..]
> > I do think Lisp is a key to future technical advancements,
> > but no way can I see my parents ever typing sexpr's into
> > a keyboard attached to their VCR.
>
> My thoughts aren't settled on this, but the original post reminds me
> that Richard Stallman claimed at a Lisp conference:
>
> [snip]
Good point! I may well be short-changing people's abilities. It
does seem to tie in with motivation, though. Hmmm...maybe there
is a pseudo-economic argument that could be made about cost vs.
utility. Very interesting.
--
Jack Unrue
> My thoughts aren't settled on this, but the original post reminds me
> that Richard Stallman claimed at a Lisp conference:
Emacs is an interesting case. I use only Emacs to program but I rarely
program emacs in Lisp. I have programmed Emacs in Lisp, and some of my
programs have become part of the standard release, but I don't usually.
Why? Well, because I program Emacs a LOT using Keyboard Macros (kbdms).
I find that I can do nearly everything I want to do in Emacs using
kbdms. In fact, whenever I do anything for anyone else using a kbdm,
they are nearly always so shocked that they immediately what to know
how to do it themselves -- these are non-programmers (otherwise I
wouldn't be doing it for them, usually).
I will now make the insane argument that emacs kbdms are exactly the
sort of thing I'm talking about: A functional programming language,
essentially equivalent to Lisp [actually, oddly enough, essentially
equivalent to APL!] You can think of a kbdm as a set of micro functions
that form an expression where the partial results are passed from one
microfunction to the next. The "partial results" here are the buffer
space. And when you do ESC-nnnn-^xe what you're essentially doing is:
(dotimes (i nnnn)
(my-kbdm *buffer-space*))
········@gmail.com wrote:
> > My thoughts aren't settled on this, but the original post reminds me
> > that Richard Stallman claimed at a Lisp conference:
>
> Emacs is an interesting case. I use only Emacs to program but I rarely
> program emacs in Lisp. I have programmed Emacs in Lisp, and some of my
> programs have become part of the standard release, but I don't usually.
> Why? Well, because I program Emacs a LOT using Keyboard Macros (kbdms).
> I find that I can do nearly everything I want to do in Emacs using
> kbdms. In fact, whenever I do anything for anyone else using a kbdm,
> they are nearly always so shocked that they immediately what to know
> how to do it themselves -- these are non-programmers (otherwise I
> wouldn't be doing it for them, usually).
>
> I will now make the insane argument that emacs kbdms are exactly the
> sort of thing I'm talking about: A functional programming language,
> essentially equivalent to Lisp [actually, oddly enough, essentially
> equivalent to APL!] You can think of a kbdm as a set of micro functions
> that form an expression where the partial results are passed from one
> microfunction to the next. The "partial results" here are the buffer
> space. And when you do ESC-nnnn-^xe what you're essentially doing is:
>
> (dotimes (i nnnn)
> (my-kbdm *buffer-space*))
Insane maybe, but also among the most interesting things I know in
computing. ;) There's a couple of tech dissidents whose works really
struck me as topical, when my thoughts went around this area... where
users can participate in the tech and produce things, rather than be
entirely passive consumers of it.
Alan Kay talks about the very tactile, kinesthetic kind of programming
that I think Emacs keyboard macros represent. Particularly in "Doing
with Images Makes Symbols" and "The Computer Revolution Hasn't Happened
Yet". [1]
Also neo-luddite David Noble discussed numerical control vs.
record/playback, in the context of manager-oriented vs. worker-oriented
tech. [2] I don't know machining, but keyboard macros really struck me
as a possible example.
[1] - http://video.google.com/videosearch?q=alan+kay&hl=en
Easily bored types might like to skip to 52:50 in "Doing with
Images..."
The other talk, "The Computer Revolution Hasn't...", starts out
entertaining.
[2] -
http://nooranch.com/synaesmedia/wiki/wiki.cgi?DavidNoble/ForcesOfProduction
Tayssir
Tayssir John Gabbour wrote:
> My thoughts aren't settled on this, but the original post reminds me
> that Richard Stallman claimed at a Lisp conference:
>
> "Multics Emacs proved to be a great success -- programming new editing
> commands was so convenient that even the secretaries in his office
> started learning how to use it. They used a manual someone had written
> which showed how to extend Emacs, but didn't say it was a programming.
> So the secretaries, who believed they couldn't do programming, weren't
> scared off. They read the manual, discovered they could do useful
> things and they learned to program.
>
> "So Bernie saw that an application -- a program that does something
> useful for you -- which has Lisp inside it and which you could extend
> by rewriting the Lisp programs, is actually a very good way for people
> to learn programming. It gives them a chance to write small programs
> that are useful for them, which in most arenas you can't possibly do.
> They can get encouragement for their own practical use -- at the stage
> where it's the hardest -- where they don't believe they can program,
> until they get to the point where they are programmers."
> http://www.gnu.org/gnu/rms-lisp.html
Now that reminds me of an architect friend of mine who steadfastly
believes she cannot program, when I've watched her doing exactly that
in AutoLisp. :-)
"Christopher Koppler" <········@chello.at> writes:
>> "So Bernie saw that an application -- a program that does something
>> useful for you -- which has Lisp inside it and which you could extend
>> by rewriting the Lisp programs, is actually a very good way for people
>> to learn programming. It gives them a chance to write small programs
>> that are useful for them, which in most arenas you can't possibly do.
>> They can get encouragement for their own practical use -- at the stage
>> where it's the hardest -- where they don't believe they can program,
>> until they get to the point where they are programmers."
>> http://www.gnu.org/gnu/rms-lisp.html
>
> Now that reminds me of an architect friend of mine who steadfastly
> believes she cannot program, when I've watched her doing exactly that
> in AutoLisp. :-)
Any homo sapiens sapiens with the right number of chromozomes is able
to program and is doing it everyday without realizing it. They're
even able to debug, the proof being the genie in the lamp stories.
But as soon as you label that activity "programming" most of them are
afraid and freeze. What's wonderful, is that if you don't call it
"programming", but anything else, like configuring, editing, setting
your preferences, anything, they keep functionning.
Personnaly, as a professionnal programmer, I only see one downside in
letting users program, it's when we have to "maintain" their programs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Jack Unrue <·······@example.tld> writes:
> On 3 Sep 2006 15:22:49 -0700, ········@gmail.com wrote:
>>
>> What I'm talking about it beyond that -- it's a programming language
>> for the masses. Google (and other search engines) is a near miss on
>> this concept.
>
> Programming is inherently a specialized skill. Otherwise, you
> wouldn't see people making jokes about not bothering with all
> the bells and whistles on their VCRs; some people are control-freaks
> but most people couldn't care less. It's not that they wouldn't
> love to have their VCR know what they want to do, it's that they
> don't have the time or patience for telling it what to do.
The main problem of most electronic devices, is the use of base 1 for the UI.
I understand the concern of providing cheap devices and stil making a
lot of millions for the CEOs of electronic device manufacturing firms.
Nowadays, they could remove all the buttons and display, and just
provide a Wifi or Bluetooth interface with a web browser to configure
them easily.
The other problem is that each device uses its own "programming
language". If they all standardized on lisp ( ;-) ) there would be
only one programming language to learn to program all our devices.
> [...] some people have a hard
> time distinguishing between Google's search field and their
> browser's address bar.
>
> I do think Lisp is a key to future technical advancements,
> but no way can I see my parents ever typing sexpr's into
> a keyboard attached to their VCR.
No, but some lisp hacker could program some AI in them to behave
automatically according to the wants of the users in their presence.
Just have each person wear a distinct bluetooth "remote".
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
On Mon, 04 Sep 2006 02:59:31 +0200, Pascal Bourguignon <···@informatimago.com> wrote:
>
> Jack Unrue <·······@example.tld> writes:
>
> > On 3 Sep 2006 15:22:49 -0700, ········@gmail.com wrote:
> >>
> >> What I'm talking about it beyond that -- it's a programming language
> >> for the masses. Google (and other search engines) is a near miss on
> >> this concept.
> >
> > Programming is inherently a specialized skill. Otherwise, you
> > wouldn't see people making jokes about not bothering with all
> > the bells and whistles on their VCRs; some people are control-freaks
> > but most people couldn't care less. It's not that they wouldn't
> > love to have their VCR know what they want to do, it's that they
> > don't have the time or patience for telling it what to do.
>
> The main problem of most electronic devices, is the use of base 1
> for the UI.
>
> I understand the concern of providing cheap devices and stil making a
> lot of millions for the CEOs of electronic device manufacturing firms.
> Nowadays, they could remove all the buttons and display, and just
> provide a Wifi or Bluetooth interface with a web browser to configure
> them easily.
I think we're almost there, at least in the auto industry. Already
today you can buy cars that interface to the right model of cell
phone via Bluetooth, and there are cars with displays for built-in
GPS / street directions, not to mention the hybrids with fancy
power efficiency displays. It sure doesn't seem long before consumer
devices achieve what you're describing.
The use-cases that Jeff describes I think require a bigger jump
than next-generation web-enabled UIs. Like Tayssir mentioned,
there are people doing HCI research on this.
> The other problem is that each device uses its own "programming
> language". If they all standardized on lisp ( ;-) ) there would be
> only one programming language to learn to program all our devices.
This is the part I have a problem with. A programming language like
we think of Lisp being is similar to a VCR interface in that they
both require interpretation and manipulation of symbols to access
functionality. And they both involve decomposition of steps to get
from current state to desired result. But Jeff is talking about
knowledge-based systems, and the problem with a programming
language like Lisp is that it is too abstract and too far away
from the task at hand. That's why I claim that programming is
a specialized skill, and that knowledge might be obtained more
effectively as an emergent property.
Tayssir's RMS quote is interesting, because in some ways it
supports your view better than mine. But on the other hand,
the fact that secretary is programming the editor without
realizing it is sort of what I'm getting at.
> > [...] some people have a hard
> > time distinguishing between Google's search field and their
> > browser's address bar.
> >
> > I do think Lisp is a key to future technical advancements,
> > but no way can I see my parents ever typing sexpr's into
> > a keyboard attached to their VCR.
>
> No, but some lisp hacker could program some AI in them to behave
> automatically according to the wants of the users in their presence.
> Just have each person wear a distinct bluetooth "remote".
Yes! This is closer to what I think, too. A system like Jeff has
in mind is built by skilled architects and programmers for use by
domain experts to set things up in a default configuration. And
then once the system is in use out in the wild-wooly real world,
it acquires more specialized knowledge.
Now here's a twist: what happens when two people enter
the room simultaneously with conflicting wants? This is where
a DSL providing a "hinting" mechanism might also help. E.g.,
Mom's or Dad's preferences have priority (or maybe not, depends
on the family) over the kids' preferences; but Mom and Dad have
to work out some other way to resolve conflict in the prioritization
schema.
Setting this complication aside for a moment, if the system
could learn that whenever Dad enters the room at 5:30pm
EST, the TV channel is most likely going to be changed to NBC so
he can watch the Nightly News, then this is input obtained without
manual programming by the end user. Likewise, Dad usually gets
home at 5:30pm and gets a cup of coffee, which the coffee maker
can certainly detect. Now here we can start talking about
connectivity between knowledge bases, with interesting non-obvious
results being possible.
--
Jack Unrue
Jack Unrue wrote:
> Programming is inherently a specialized skill. Otherwise, you
> wouldn't see people making jokes about not bothering with all
> the bells and whistles on their VCRs; some people are control-freaks
> but most people couldn't care less. It's not that they wouldn't
> love to have their VCR know what they want to do, it's that they
> don't have the time or patience for telling it what to do.
Sorry, but I can't disagree more.
Put aside "the time or patience for telling it what to do",
communication with devices from computational to laundry
should not be (and would not be) subject of any specialized skills but
domain knowledge.
All progress in of human-computer interfaces grows from binary interface
through early assemblers and C to more and more abstract "programming"
languages toward domain specific subsets of natural language.
And finally to something as close to human-human interface as possible.
cheers
DG
--
...this cultural transferral that keeps making us human, again and again,
generation to generation.
--Rodney Brooks
········@gmail.com wrote:
> When you put a search into Google (etc) you are essentially
> populating the test in the following function:
>
> (sort
> (loop for page in (the-whole-web)
> when (search "my-string" page)
> collect page)
> #'page-rank)
>
> [Yes, I know it's not that simple! Not relevant here!]
I think it is relevant.
>
> What I'm talking about is what would happen if Google (and other
> non-centralized applications -- indeed, if ALL applications!) let you
> put in that whole chunk of code. If you could do THAT, then you could
> also do:
>
> (sort
> (loop for page in (the-whole-web)
> when (search "my-string" page)
> collect page)
> #'> :key #'page-date)
>
Well, the problem is that what google *actually* does is nothing like
that, because a linear search would have such appalling performance.
Instead it has some fancy index which it searches, into the
construction of which is wired the page rank function. So, no, you
couldn't just modify the search as you suggest: instead you'd have to
generate some new index, which would require hundreds of machines and
lots of storage etc etc.
This is similar to the relational database index issue: SQL makes it
*look* as if you can ask all sorts of arbitrary things about the data,
but in fact you can only do that if you're willing to wait really a
long time for results, and probably hammer the performance of the whole
system while doing so. Instead you have to understand how the indices
are constructed, what is indexed, and so on.
Or, closer to home, how sensible is it to intervene in SLOT-VALUE? how
difficult is it to write a system which lets you do that without
destroying the performance of all sorts of unrelated code?
Or, in other words, there are a lot of complicated issues which make it
very hard to `just plug in' things in a way which might seem obvious to
the naive.
--tim
> > [Yes, I know it's not that simple! Not relevant here!]
>
> I think it is relevant.
No, I think that it's not relevant. I may have confused you by
mentioning google. I don't care about Google. Google is history. Google
is a giant (unprogrammable) time sharing system. Google is Netowrk TV
-- 50 channels of porn supported by advertising. I was just using it as
an example of how easy it might be to get people to accept typing
things into a tool if it does something interesting, and how easy it
would be to expand that capability. I was envisioning programming your
iPod, not google. Sorry for the confusion.
HOWEVER, since you bring it up, let me argue that you're (slightly)
wrong anyway! :-)
I proposed that one could do something like:
(sort
(loop for page in (the-whole-web)
when (search "my-string" page)
collect page)
#'> :key #'page-date)
which you, correctly, point out might require turning Google's
algorithms upside down. However, I think that one could get nearly the
desired effect by simply operating on the results of the EXISTING
google results. In other words, treat: (google-search <strings>) as a
black box that just does that by whatever mechanism, and returns a few
hundred results (you can get ten from them now, and as many as you like
in linear time by screen scraping). For many, perhaps most purposes it
would be adequate to be able to operate on THOSE few hundred results.
That take no computing at all, and doesn't require changing anything
inside Google. Granted, this isn't equivalent to what I wrote above,
but as I originally said, doing this literally to google isn't the
point, so probably it's not worth arguing this further.
········@gmail.com wrote:
> > > [Yes, I know it's not that simple! Not relevant here!]
> >
> > I think it is relevant.
>
> No, I think that it's not relevant. I may have confused you by
> mentioning google. I don't care about Google
I don't either. What I was arguing against was what you said: `What
I'm talking about it beyond that -- it's a programming language for the
masses.'. That just doesn't fly because there are issues in
programming which are hard, and are not to do with syntax but to do
with time & space complexity and so on. People who are barely numerate
(which is almost everyone, including most `programmers') are just not
going to be able to cope with this.
--tim
> What I was arguing against was what you said: `What
> I'm talking about it beyond that -- it's a programming language for the
> masses.'. That just doesn't fly because there are issues in
> programming which are hard, and are not to do with syntax but to do
> with time & space complexity and so on. People who are barely numerate
> (which is almost everyone, including most `programmers') are just not
> going to be able to cope with this.
I both agree and disagree. First, there are enough people who can cope
with these issues (call them programmers if you like), that given an
exposed programming language on these boxes will provide for the rest
of the lusers who can't. Second, I don't think that searching the 10000
songs on your iPod is going to slow anything down unless you do
something exponential. Third, aside from a simple cross-product, you'd
have to be a programmer already to even program something very
exponential, and if you do try to do one of the common simple class of
cross-products the compiler can see what you're up to and "do the right
thing", like SQL does. Finally, the most common complex screw cases
will get enclosed in built-in functionality (like SORT), or those
"programmers" from point 1, above, will build it in.
The category I'm after is #1 -- again, you can call them programmers if
you like -- let's call them "surface programmers", to distinguish them
from the folks who program the internals of the cell phone now ("deep
programmers"). At the moment the only categories understood are users
and deep programmers. I'm proposing to provide for surface programmers
as well.
········@gmail.com wrote:
> Second, I don't think that searching the 10000
> songs on your iPod is going to slow anything down unless you do
> something exponential. Third, aside from a simple cross-product, you'd
> have to be a programmer already to even program something very
> exponential,
You'd be surprised - though you shouldn''t be - how easy it is to write
things which have really quite bad performance. Seriously, go and look
at the Lisp programs naive users write, for instance.
(loop for song in songlist
do (setf song-titles (append song-titles (title song))))
Or, in Java:
String titles = "";
for (Song s: songList) {
titles = titles + s.title + "\n";
}
Oh, gosh, Java is slow isn't it? And don't tell me no one would write
code like that: I can tell you from first-hand experience of teaching
people (postgraduate students at a good University) Lisp that yes, they
do write code really very similar to that. Worse, I can tell you from
first-hand experience of commercial systems in production use, that
yes, they really do.
> The category I'm after is #1 -- again, you can call them programmers if
> you like -- let's call them "surface programmers", to distinguish them
> from the folks who program the internals of the cell phone now ("deep
> programmers"). At the moment the only categories understood are users
> and deep programmers. I'm proposing to provide for surface programmers
> as well.
There have been *many* attempts to do this - Logo, SmallTalk to some
extent, HyperTalk, AppleScript &c &c &c. Why have these not been
blindingly successul? Hint: programming is hard and boring.
--tim
> You'd be surprised - though you shouldn''t be - how easy it is to write
> things which have really quite bad performance.
I'm definitely not surprised. My theory is that most of the simple
cases, like the one you gave, are single-level cross-products which can
be easily optimized out, Like SQL does, or at least identified and
flagged at run time. Regardless, I believe that surface programming is
going to rapidly overtake the world, so we might as well lead the wave
than follow it.
On 2006-09-04 19:01:24 +0100, ········@gmail.com said:
> I'm definitely not surprised. My theory is that most of the simple
> cases, like the one you gave, are single-level cross-products which can
> be easily optimized out, Like SQL does, or at least identified and
> flagged at run time. Regardless, I believe that surface programming is
> going to rapidly overtake the world, so we might as well lead the wave
> than follow it.
A language with a non-obvious performance model like Lisp is definitely
not going to be a success when used by naive programmers. At least get
rid of the linked lists and make sure you use something for which
appending is cheap. Like, say, Python. And macros, for God's sake, who
understands them?
Of course, *no programming language has ever been a success with naive
programmers* and there's a good reason for that which I've stated
enough times now, but that's by the by.
--tim
> And macros, for God's sake, who understands them?
Yeah, and parens, god you'd think those crazy Lisp folks would have
come up with some kind of sensible syntactic markers, like, oh, I don't
know, white space, or indentation, or line noise.
[I agree with you about the tables/dictionaries, though. Having to make
every hash table I use is somewhat of a pain. In fact, I have in the
past macrofied defun with an &tbls argument that binds #'equals hash
tables to the symbol args.]
All of this performance discussion is besides the point...yes, lusers
can write infinite loops, and the easier the language, the easier to
write an infinite loop.
This *is* to the point:
> Of course, *no programming language has ever been a success with naive
> programmers* and there's a good reason for that which I've stated
> enough times now, but that's by the by.
...but even though I think that it's on point, and even that I agree
with it, it's looking backward, not forward, and that as a result it's
irrelevant.
Look: Until blogs, only journalists could do news; until digital video
and youtube, only professional film makers could make films that were
worth watching. (Okay, most of youtube isn't worth watching, but I'll
bet you watch more than you want to anyway! :-)
My claim is that devices are going to have open programmability sooner
than later, and that when they do people will program them -- yes, some
people will write slow progams and some will write infinite loops, but
some won't, and there will be enough of those to make life interesting.
Moreover, what is needed here, I claim, is exactly a language like
Lisp, which can handle knowledge easily, is highly extensible, and
doesn't need you to insert line noise at the right places in order to
write useful code.
So, I say: Forget the Web. The Web is sooooooo 2000's -- Leave web
services to Ruby and move on to the future where small, efficient,
extensible, knowledge-rich, device programming is going. Move on to
Ambient (to use the word I just learned!) Lisp and leave the web to
Google -- which can have it as far as I'm concerned.
········@gmail.com wrote:
> All of this performance discussion is besides the point...yes, lusers
> can write infinite loops, and the easier the language, the easier to
> write an infinite loop.
The point I was trying to make is thar programming is *hard* and
*boring*, and no language we have makes that go away to any significant
extent. Hard and boring things tend not to be popular.
> > Of course, *no programming language has ever been a success with naive
> > programmers* and there's a good reason for that which I've stated
> > enough times now, but that's by the by.
>
> ...but even though I think that it's on point, and even that I agree
> with it, it's looking backward, not forward, and that as a result it's
> irrelevant.
`Those who do not learn the lessons of history are doomed to repeat its
mistakes'. Or: go and look at those systems and understand why they
failed so badly. What has changed?
>
> Look: Until blogs, only journalists could do news; until digital video
> and youtube, only professional film makers could make films that were
> worth watching. (Okay, most of youtube isn't worth watching, but I'll
> bet you watch more than you want to anyway! :-)
(I have never looked at youtube in fact.) This analogy is basically
useless however, because you haven't thought about what the technical
barriers are. People have been able to write reasonably coherent
English for hundreds of years, but until recently there has been a huge
cost to publication. Technology has made that go away: there's still
more skill than people generally understand to writing something
interesting, which is why almost all blogs / usenet articles are still
junk, but now publiching the junk is cheap and easy. Films are
somewhat the same - before video it was enormously expensive just to
capture moving images of any quality, before digital video it was
enormously expensive to edit them, and before bandwidth became cheap it
was enormously expensive to distribute them. There is still a
considerable skill involved (and it's a rarer skill than being able to
write interestingly) which is why youtube etc is full of crap but
capturing, editing and distributing is now cheap.
There is also a barrier in the way of pervasive programming, and it's
this: programming is hard and boring. It was hard and boring in 1960,
and it's hard and boring now. There has been almost no progress in
removing this barrier. Programmable devices have been available for
many, many years: calculators, video recorders, central heating
controllers, cheap computers, cheap computers with special easy-to-use
scripting systems like HyperTalk and AppleScript. Almost no video
recorders have their clock set because (yes) programming them is hard
and boring, and so for the rest.
You need to remove the technical barriers if you want programming to be
pervasive. And they are not what you think they are. Consider why
cats don't write blogs.
--tim
On 2006-09-05 10:46:07 -0400, ········@gmail.com said:
> My claim is that devices are going to have open programmability sooner
> than later, and that when they do people will program them -- yes, some
> people will write slow progams and some will write infinite loops, but
> some won't, and there will be enough of those to make life interesting.
> Moreover, what is needed here, I claim, is exactly a language like
> Lisp, which can handle knowledge easily, is highly extensible, and
> doesn't need you to insert line noise at the right places in order to
> write useful code.
I've been saying something like this here on c.l.l for a long time, to
similar objections. The history of computer use is a history of ever
expanding numbers of users as interfaces became easier to work with. In
the last thirty years we went from a world where a majority of computer
users were computer programmers, to a world where non-programmer users
number in the hundreds of millions and far outnumber programmers.
Among these hundreds of millions of non-programmer users are millions
of people who are every bit as bright as people who can program, and
whose work would benefit if they could construct their own custom
software. All that's needed is an interface that's somewhat better than
existing programming languages. I agree that lisp would be an excellent
platform to build such languages on. For each increase in ease of
programming a larger group of users is enabled to construct custom
software. It will happen - it's just a question of who moves it forward.
The fact that most users won't learn to program doesn't mean that there
aren't tens of millions of users out there who will learn to do so with
the right tools. I think that the next major development in programming
languages will be crafting programming tools that allow advanced users
to construct custom software. This is why it's important to view
language constructs from a lay perspective - it lets you know whether
such an approach will be generally useful to many of today's
non-programmers who will come to outnumber programmers as developers of
custom software. Viewed in this light, constructs that are too clever
for intelligent lay users to work with are big losers. Constructs that
hew more closely to natural language are winners.
On Thu, 7 Sep 2006 00:46:04 -0400, Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-09-05 10:46:07 -0400, ········@gmail.com said:
>
> > My claim is that devices are going to have open programmability sooner
> > than later, and that when they do people will program them -- yes, some
> > people will write slow progams and some will write infinite loops, but
> > some won't, and there will be enough of those to make life interesting.
> > Moreover, what is needed here, I claim, is exactly a language like
> > Lisp, which can handle knowledge easily, is highly extensible, and
> > doesn't need you to insert line noise at the right places in order to
> > write useful code.
>
> I've been saying something like this here on c.l.l for a long time, to
> similar objections. The history of computer use is a history of ever
> expanding numbers of users as interfaces became easier to work with. In
> the last thirty years we went from a world where a majority of computer
> users were computer programmers, to a world where non-programmer users
> number in the hundreds of millions and far outnumber programmers.
>
> Among these hundreds of millions of non-programmer users are millions
> of people who are every bit as bright as people who can program, and
> whose work would benefit if they could construct their own custom
> software. All that's needed is an interface that's somewhat better than
> existing programming languages. I agree that lisp would be an excellent
> platform to build such languages on. For each increase in ease of
> programming a larger group of users is enabled to construct custom
> software. It will happen - it's just a question of who moves it forward.
I guess this is as good an opportunity as any to acknowledge that
my view on this is fairly elitist (I had said I consider programming
to be a specialized skill and that I didn't see my parents programming
their VCR in lisp). I have never subscribed to the notion that
non-programmers are unintelligent. People have expertise in their
respective domains, and those domains don't have to overlap with
computer programming for me to respect that expertise; for those
people, the computer is a tool or a source of entertainment or
whatever.
One frequent problem in UI development is a tendency amongst
programmers to allow implementation details to bubble up and
confront the user. I feel the same way about programming languages
as we know them today, in the context of this discussion. I *still*
feel it is too much of a leap for most people -- not because those
people lack intelligence, but because they would laugh and say
"are you seriously making me deal with this crap?" I *do not* think
it's correct to dismiss the "time and patience" issue, because that
is a gut reaction to a real problem. So I think programming languages
for the masses have to be designed a lot better than what we have
today. This is part of what you are saying, Raffael, and I agree.
Some of the other comments in this long-running discussion have
cause me to rethink my opinion. In particular, and as others have
illustrated quite nicely, people today engage in an activity that
is not called programming but nevertheless is indeed exactly that
and this has been a successful approach at a small scale.
A couple of recent developments, at least in US society, have to
be addressed in order to achieve greater scale. One is a frequent
depiction of programmer folks as weird geeks by the mass media. And
a very unfortunate anti-intellectuallism movement in this country.
So the successful programming language designer will also be a
successful marketer. As the scope and depth of programming extends,
the boundary of what is called "programming" will be pushed back
like the proverbial goalposts; but the boundary will remain.
> The fact that most users won't learn to program doesn't mean that there
> aren't tens of millions of users out there who will learn to do so with
> the right tools. I think that the next major development in programming
> languages will be crafting programming tools that allow advanced users
> to construct custom software. This is why it's important to view
> language constructs from a lay perspective - it lets you know whether
> such an approach will be generally useful to many of today's
> non-programmers who will come to outnumber programmers as developers of
> custom software. Viewed in this light, constructs that are too clever
> for intelligent lay users to work with are big losers. Constructs that
> hew more closely to natural language are winners.
I agree here, too. But I would go further and claim that some of
the functionality that Jeff described as being achieved through
programming (even if we assume more of a natural language style
as you mentioned), I think will actually be accomplished better
through machine learning and reasoning.
--
Jack Unrue
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-09-05 10:46:07 -0400, ········@gmail.com said:
>
>> My claim is that devices are going to have open programmability sooner
>> than later, and that when they do people will program them -- yes, some
>> people will write slow progams and some will write infinite loops, but
>> some won't, and there will be enough of those to make life interesting.
>> Moreover, what is needed here, I claim, is exactly a language like
>> Lisp, which can handle knowledge easily, is highly extensible, and
>> doesn't need you to insert line noise at the right places in order to
>> write useful code.
>
> I've been saying something like this here on c.l.l for a long time, to
> similar objections. The history of computer use is a history of ever
> expanding numbers of users as interfaces became easier to work with.
> In the last thirty years we went from a world where a majority of
> computer users were computer programmers, to a world where
> non-programmer users number in the hundreds of millions and far
> outnumber programmers.
>
> Among these hundreds of millions of non-programmer users are millions
> of people who are every bit as bright as people who can program, and
> whose work would benefit if they could construct their own custom
> software. All that's needed is an interface that's somewhat better
> than existing programming languages. I agree that lisp would be an
> excellent platform to build such languages on. For each increase in
> ease of programming a larger group of users is enabled to construct
> custom software. It will happen - it's just a question of who moves it
> forward.
>
> The fact that most users won't learn to program doesn't mean that
> there aren't tens of millions of users out there who will learn to do
> so with the right tools. I think that the next major development in
> programming languages will be crafting programming tools that allow
> advanced users to construct custom software. This is why it's
> important to view language constructs from a lay perspective - it lets
> you know whether such an approach will be generally useful to many of
> today's non-programmers who will come to outnumber programmers as
> developers of custom software. Viewed in this light, constructs that
> are too clever for intelligent lay users to work with are big losers.
> Constructs that hew more closely to natural language are winners.
>
While I think this is partly true, we need to also factor in
evolution and how constructs which seem alien to the majority of
people now are likely to be second nature in another 30 years. When
you look at the concepts users struggled with 30 years ago, you can
find quite a few which are now common knowledge.
I'm sure in a few more generations, we will be approaching the star
trek ideal. I can see a group of kids trying to work out the best
trades for their baseball cards and one saying "Hang on - lets just
get some data from the national trade show database, run it through
this genetic algorithm to get a base data set and apply a simple
neural network on that multi-dimensional matrix representing collector
preferences and we should be able to get a priority sorted list of
trade options.
--
tcross (at) rapttech dot com dot au
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> Among these hundreds of millions of non-programmer users are millions
> of people who are every bit as bright as people who can program, and
> whose work would benefit if they could construct their own custom
> software. All that's needed is an interface that's somewhat better
> than existing programming languages. I agree that lisp would be an
> excellent platform to build such languages on. For each increase in
> ease of programming a larger group of users is enabled to construct
> custom software. It will happen - it's just a question of who moves it
> forward.
>
> The fact that most users won't learn to program doesn't mean that
> there aren't tens of millions of users out there who will learn to do
> so with the right tools. I think that the next major development in
> programming languages will be crafting programming tools that allow
> advanced users to construct custom software. This is why it's
> important to view language constructs from a lay perspective - it lets
> you know whether such an approach will be generally useful to many of
> today's non-programmers who will come to outnumber programmers as
> developers of custom software. Viewed in this light, constructs that
> are too clever for intelligent lay users to work with are big
> losers. Constructs that hew more closely to natural language are
> winners.
Are speaking of Metafor? http://www.primidi.com/2005/03/24.html
It looks interesting. I'm just wondering how deep it is.
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On 2006-09-07 12:46:20 -0400, Pascal Bourguignon <···@informatimago.com> said:
> Are speaking of Metafor? http://www.primidi.com/2005/03/24.html
> It looks interesting. I'm just wondering how deep it is.
This is precisely the direction I think programming tools should be
moving in. Right now it can only construct the highest level
scaffolding code, so it is not too "deep" as you say, but I hope that
it will become generally usable by lay knowledge workers who want to
construct their own custom software. Also worth noting is the fact that
lisp is one of the languages that it converts a limited subset of
English to.
········@gmail.com writes:
>
> So, I say: Forget the Web. The Web is sooooooo 2000's -- Leave web
> services to Ruby and move on to the future where small, efficient,
> extensible, knowledge-rich, device programming is going. Move on to
> Ambient (to use the word I just learned!) Lisp and leave the web to
> Google -- which can have it as far as I'm concerned.
That's so true...But what about concurrency. Keeping tens of devices that
you own in sync. I mean, Scheme is geared towards concurrency, but
is Common Lisp? It sure weights a lot. And it isn't very portable.
H.
From: Pascal Costanza
Subject: Re: Too Much Caffeine I -- End-User Programming
Date:
Message-ID: <4ma053F57k8oU2@individual.net>
HL wrote:
> ········@gmail.com writes:
>
>
>> So, I say: Forget the Web. The Web is sooooooo 2000's -- Leave web
>> services to Ruby and move on to the future where small, efficient,
>> extensible, knowledge-rich, device programming is going. Move on to
>> Ambient (to use the word I just learned!) Lisp and leave the web to
>> Google -- which can have it as far as I'm concerned.
>
> That's so true...But what about concurrency. Keeping tens of devices that
> you own in sync. I mean, Scheme is geared towards concurrency, but
> is Common Lisp? It sure weights a lot. And it isn't very portable.
That's incorrect. Neither Scheme nor Common Lisp say anything about
concurrency in their specs. Both have implementations that support
concurrency. Both have portable implementations.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mon, 04 Sep 2006 19:48:57 +0100, Tim Bradshaw wrote:
> And macros, for God's sake, who understands them?
The same thing applies to concurrency and multithreading in general about
a thousand times over. Deadlock, livelock, deadly embrace, inefficient
spinlock. And now multicore systems are entering the mainstream, which
means Joe Blow House-O-WinDOS-Apps will have to deal with them. I don't
know any language that will make it any easier.*
Especially languages dumbed-down enough to be 'enterprise-ready' and/or
'industry standard'.
We both agree that programming is hard. My point is that some kinds of
hard percolate up through just about any language.
*(Well, I kind of do: Program to a single-threaded VM that either tries
and fails to multithread the code or doesn't try at all. Neither is good
enough to build a game engine on.)
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts wrote:
>
> We both agree that programming is hard. My point is that some kinds of
> hard percolate up through just about any language.
Yes, I agree. And I'm fine with the idea that Lisp makes it as easy as
it can be (I think it's wrong, actually, but that's a different
discussion). *hard* is the point though. Hard, generally very boring,
and requiring a very specialised way of thinking in which almost no one
is interested.
--tim
Tim Bradshaw <··········@tfeb.org> wrote:
+---------------
| Chris Barts wrote:
| > We both agree that programming is hard. My point is that some kinds of
| > hard percolate up through just about any language.
|
| Yes, I agree. And I'm fine with the idea that Lisp makes it as easy as
| it can be (I think it's wrong, actually, but that's a different
| discussion). *hard* is the point though. Hard, generally very boring,
| and requiring a very specialised way of thinking in which almost no one
| is interested.
+---------------
Someone (Dijkstra?) once commented that the "smarter" our IDEs
become, the more *difficult* the process of programming becomes,
since with all that "easy stuff" taken care of automatically,
all that is left are the *hard* bits!! ;-} ;-}
Or said another way, Lisp makes all the boring, repetitive,
fiddly bits easy, which leaves only the *hard* parts...
All of which just means that the (reported) factors of 10x to 100x
between the median and the very best programmers isn't ever going
to go away.
On the other hand, from practical experience helping non-programmers
with editor macros & simple scripting, I agree with Jeff Shrager that
"surface programming" by average people *is* both possible and desirable.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> On the other hand, from practical experience helping non-programmers
> with editor macros & simple scripting, I agree with Jeff Shrager that
> "surface programming" by average people *is* both possible and desirable.
Those are people who are already trying to do complicated things with
an editor. I'm not denying that there are people who need to do this:
there have been people doing this for a long time (I taught secretaries
to write shell scripts & TeX macros in the early 90s, and my wife did
similar things in the 80s, Unix itself got a lot of its start as a
system for people doing document preparation 15 years before that, and
I'm sure it's possible to go all the way back). What I am arguing is
that this is a relatively small number of people, and it is not about
to explode, because *nothing has changed*: in particular *no technical
barriers have gone away*. It's as hard and boring as it ever was and
people are notoriously averse to doing hard and boring things unless
they need to. Try and think of it from the point of view of an average
human being rather than some sad loser who spends all their time time
making a machine do tricks.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> Rob Warnock wrote:
>
>> On the other hand, from practical experience helping non-programmers
>> with editor macros & simple scripting, I agree with Jeff Shrager that
>> "surface programming" by average people *is* both possible and desirable.
>
> Those are people who are already trying to do complicated things with
> an editor. I'm not denying that there are people who need to do this:
> there have been people doing this for a long time (I taught secretaries
> to write shell scripts & TeX macros in the early 90s, and my wife did
> similar things in the 80s, Unix itself got a lot of its start as a
> system for people doing document preparation 15 years before that, and
> I'm sure it's possible to go all the way back). What I am arguing is
> that this is a relatively small number of people, and it is not about
> to explode, because *nothing has changed*: in particular *no technical
> barriers have gone away*. It's as hard and boring as it ever was and
> people are notoriously averse to doing hard and boring things unless
> they need to. Try and think of it from the point of view of an average
> human being rather than some sad loser who spends all their time time
> making a machine do tricks.
On the other hand, the main problem might be to stick this image of
sad loser to people who like to make machines do tricks.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
From: HL
Subject: Re: Too Much Caffeine -- Users v. Surface v. Deep Programming
Date:
Message-ID: <86irk0b4pg.fsf@agora.my.domain>
Tim Bradshaw <···@tfeb.org> writes:
> Of course, *no programming language has ever been a success with naive
> programmers*
BASIC was such language, was it not?
H.
········@gmail.com wrote:
> I'm definitely not surprised. My theory is that most of the simple
> cases, like the one you gave, are single-level cross-products which can
> be easily optimized out, Like SQL does, or at least identified and
> flagged at run time.
Um, are you implying that SQL can magically optimize queries? Enough
queries that, for instance, you never need to spend time poring over
the table structure and/or the querty optimizer output to try and work
out why on earth *this* query is really quick, but *this* tiny
perturbation of it is eating all your disk bandwidth for half an hour?
I guess I just imagined all those high-paying DBA jobs, then.
--tim
Tim Bradshaw wrote:
> ········@gmail.com wrote:
> > Second, I don't think that searching the 10000
> > songs on your iPod is going to slow anything down unless you do
> > something exponential. Third, aside from a simple cross-product, you'd
> > have to be a programmer already to even program something very
> > exponential,
>
> You'd be surprised - though you shouldn''t be - how easy it is to write
> things which have really quite bad performance. Seriously, go and look
> at the Lisp programs naive users write, for instance.
>
> (loop for song in songlist
> do (setf song-titles (append song-titles (title song))))
>
> Or, in Java:
>
> String titles = "";
> for (Song s: songList) {
> titles = titles + s.title + "\n";
> }
>
> Oh, gosh, Java is slow isn't it? And don't tell me no one would write
> code like that: I can tell you from first-hand experience of teaching
> people (postgraduate students at a good University) Lisp that yes, they
> do write code really very similar to that. Worse, I can tell you from
> first-hand experience of commercial systems in production use, that
> yes, they really do.
Isn't algorithmic complexity just a scaling problem? Just like we don't
expect emails and SMSes to scale into books, Youtube vids into movies,
home remodelling into cathedrals...
Sure there'll be a few hammered fingers, embarrassing videos of someone
playing Star Wars...
And hey, such scaling problems mean the Norvigs and Waters of the
future can write whole articles on things like queues...
Tayssir
--
http://www.youtube.com/watch?v=GWUGk4Qm2XE
On 2006-09-05 01:27:02 +0100, "Tayssir John Gabbour"
<···········@yahoo.com> said:
> Isn't algorithmic complexity just a scaling problem? Just like we don't
> expect emails and SMSes to scale into books, Youtube vids into movies,
> home remodelling into cathedrals...
No, it's a `clicking this button takes 30 seconds' problem.
From: HL
Subject: Re: Too Much Caffeine -- Users v. Surface v. Deep Programming
Date:
Message-ID: <86odtsb4sr.fsf@agora.my.domain>
········@gmail.com writes:
> The category I'm after is #1 -- again, you can call them programmers if
> you like -- let's call them "surface programmers", to distinguish them
> from the folks who program the internals of the cell phone now ("deep
> programmers"). At the moment the only categories understood are users
> and deep programmers. I'm proposing to provide for surface programmers
> as well.
What would be exquisite is having a visual symbolic language whereby
you can compose actions. I'm thinking of sign language and
blissymbolics, in the direction of very high level written software
(like software for blogs). This would be like GUI oriented. Actually, not GUI as
we know them (windows, events).
If you could have the visual equivalent of UNIX pipe capabilities...
So it would be very "surface".
Like I said, blissymbolics and sign language already achieve the sort
of composition you have in other mediums, like algebra. Except, both
these languages are intuitive.
Cheers.
H.