Since the contenders in the Lightweight Language wars are now down to
only Ruby and Lisp (Perl having been supplanted by Python, only itself
to be rapidly overtaken by Ruby), and since Ruby is nearly Lisp, I
think that the practice of tracking around after Ruby Quiz is
backwards of what we ought to be doing. Instead of showing that, yeah,
you can do in Lisp anything you can do in Ruby -- nyah nayh nyah nyah
nyah -- we should be doing the opposite: Showing that many things that
you can do in Lisp, you CAN'T do in Ruby. Similarly, instead of
writing books called "Practical Common Lisp", we ought to write one
called "Impractical Common Lisp" which, instead of highlighting that
Lisp can do the same "real" (read: work-a-day) computing that you can
do in other "real" (read: "work-a-day") languages. What would be the
chapters of such a book/elements of such a quiz. Here are some
candidates:
* Write a web listener that enables you to directly execute code in
the language through the web in a live programming environment - now
build a time-sharing system out of it! (My personal favorite for
obvious reasons.)
* Add a new kind of conditional construct to the language; perhaps one
that executes its sub-clauses in parallel and you get the result for
the one that returns first, or some such thing.
* Similarly (although on a larger scale), put a theorem prover (or, if
you prefer, prolog interpreter) right into the programming language/
environment.
* Change the MOP. For example, brain-damage it to look like Ruby. :-)
Other ideas?
On 27 out, 13:40, Jeff Shrager <········@gmail.com> wrote:
> Since the contenders in the Lightweight Language wars are now down to
> only Ruby and Lisp (Perl having been supplanted by Python, only itself
> to be rapidly overtaken by Ruby), and since Ruby is nearly Lisp
amazing the amount of distortion one has to go to reassert oneself
that there is only Lisp.
yea, I could say Ruby is a Lisp. A friggin practical, concise, hip,
but slow performant Scheme, actually.
> yea, I could say Ruby is a Lisp. A friggin practical,
> concise, hip, but slow performant Scheme, actually.
Gosh, you're right; Sorry ... I completely forgot that most feature of
Ruby: It's hipness! It does seem unlikely that Lisp was, or will ever
be, hip. That's so sad, since, as we all know, hip is what computing
is all about.... My mistake! (As for "friggin pratical", that would
seem to me to be at least balanced out by "friggin slow." And if you
want "really friggin practical" (and "really friggin fast!" you should
be coding in Java!)
On 28 out, 05:54, Jeff Shrager <········@gmail.com> wrote:
> And if you
> want "really friggin practical" (and "really friggin fast!" you should
> be coding in Java!)
ah! but I don't want the "really friggin bureaucratic and verbose"
part!
> ah! but I don't want the "really friggin
> bureaucratic and verbose" part!
Fair enough, but let's really talkabout "really friggin bureaucratic
and verbose". You seem to think that Ruby is somehow unbureaucratic
and concise, such that even thought its slower than molasses in
Januarty, you're willing to put up with it. I will claim that Lisp is
the LEAST bureaucratic and the MOST concise language on the planet,
bar none (AND it's fast, too!) I hear you lol'ing already, but that's
because you probably don't understand macros (or, if you do, then you
don't use them enough)! How much less bureaucratic can you get than:
You can change ABSOLUTELY ANYTHING about the language? As for concise,
again, macros enable you to take any complex construct that you can
think of, and turn it into a more concise construct. So whereas other
languages may well be more concise than writing out the code in base
CL, you could, in CL, build APL if you wanted it -- and, man, you
don't know concise until you've used APL!
On Oct 28, 2:54 am, Jeff Shrager <········@gmail.com> wrote:
> > yea, I could say Ruby is a Lisp. A friggin practical,
> > concise, hip, but slow performant Scheme, actually.
>
> Gosh, you're right; Sorry ... I completely forgot that most feature of
> Ruby: It's hipness! It does seem unlikely that Lisp was, or will ever
> be, hip. That's so sad, since, as we all know, hip is what computing
> is all about.... My mistake! (As for "friggin pratical", that would
> seem to me to be at least balanced out by "friggin slow." And if you
> want "really friggin practical" (and "really friggin fast!" you should
> be coding in Java!)
Remember that Lisp was once accused of being too slow.
Eric
http://www.lispcast.com
On 2007-10-27, Jeff Shrager <········@gmail.com> wrote:
[snip]
> Similarly, instead of
> writing books called "Practical Common Lisp", we ought to write one
> called "Impractical Common Lisp" which, instead of highlighting that
> Lisp can do the same "real" (read: work-a-day) computing that you can
> do in other "real" (read: "work-a-day") languages. What would be the
> chapters of such a book/elements of such a quiz. Here are some
> candidates:
As the person who posted the ruby quiz I do not know if I agree
with you doing this as a replacement. The main use of ruby quiz,
in my opinion is as a marketing and training tool to/for the
developers involved and the language. The way I see it is not a
programming contest but a newsletter with feed back from the
community. To do this you need the following:
1: an editor to manage the processes, time consuming job
1.1: request articles, problems, from the community
1.2: review them, size and complexity good fit check spelling etc.
1.3: deal with submissions.
1.4: provide reasonably detailed feed back to the community
2: Tech support
2.1: website
2.2: CMS system, for production management
2.3: Testing infrastructure
2.4: reporting on results
2.5: bells and whistles, TBD
2.6: things I do not know about but are absolutely critical.
To make this work you need #1 and #2 would be nice to have. I will
freely admit that things in #2 will make #1 much easier, but it is
just not necessary. And the simple fact is that this will be a lot of
work to do for the people running it and someone needs to do it and
they need to be a fairly advanced developer to accurately scope the
problems for your target audience.
Now to get back on message the main value here is not that people
write code to win. It is that several people write solutions and
that they can look at other people work to see how they did it *and*
that still more people can comment on the code to explain how they
could make it better if they did it again, new algorithm or better
coding practices or something else. And this is how you build community
and grow developers. And that is what I see as the primary benefit
of ruby quiz is for ruby. This would also apply to CL if something
like that happend here.
>
> * Write a web listener that enables you to directly execute code in
> the language through the web in a live programming environment - now
> build a time-sharing system out of it! (My personal favorite for
> obvious reasons.)
>
> * Add a new kind of conditional construct to the language; perhaps one
> that executes its sub-clauses in parallel and you get the result for
> the one that returns first, or some such thing.
>
> * Similarly (although on a larger scale), put a theorem prover (or, if
> you prefer, prolog interpreter) right into the programming language/
> environment.
>
> * Change the MOP. For example, brain-damage it to look like Ruby. :-)
>
> Other ideas?
Please keep track of the target audience, can a Jr programmer do this in
8-24 hours after working a full day? This would include research time.
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Although I think that you are correct on (nearly) every one of your
points, you missed my purpose, perhaps because I did not make myself
clear. My purpose is not at all to mimic Ruby Quiz, which serves all
the functions you describe in but rather to distinguish Lisp from
Ruby. There is already a Lisp quiz that serves these functions.
Now, the point on which I disagree is whether it requires editors and
machinery to run such a quiz. I don't think that it requires any more
editors and machinery than are already provided in the medium that we
are conversing within at this very moment: Google Groups nee Usenet.
All we need to do is post them here and solutions, complete with
surrounding disucssion, arise!
Which leads me to a meta p.s. perhaps obvious to all here, but
apparently not elsewhere: With all the chatter about Web 2.0 social
yada yada, can someone explain to me why this system (i.e., Google
Groups nee Usenet) isn't pretty much the original and still the best
resource for getting things posted/discussed/done, and all it takes is
about ten lines of code (in Lisp, anyway! :-)
On Oct 27, 12:01 pm, marc spitzer <······@sverige.freeshell.org>
wrote:
> On 2007-10-27, Jeff Shrager <········@gmail.com> wrote:
>
> [snip]
>
> > Similarly, instead of
> > writing books called "Practical Common Lisp", we ought to write one
> > called "Impractical Common Lisp" which, instead of highlighting that
> > Lisp can do the same "real" (read: work-a-day) computing that you can
> > do in other "real" (read: "work-a-day") languages. What would be the
> > chapters of such a book/elements of such a quiz. Here are some
> > candidates:
>
> As the person who posted the ruby quiz I do not know if I agree
> with you doing this as a replacement. The main use of ruby quiz,
> in my opinion is as a marketing and training tool to/for the
> developers involved and the language. The way I see it is not a
> programming contest but a newsletter with feed back from the
> community. To do this you need the following:
>
> 1: an editor to manage the processes, time consuming job
> 1.1: request articles, problems, from the community
> 1.2: review them, size and complexity good fit check spelling etc.
> 1.3: deal with submissions.
> 1.4: provide reasonably detailed feed back to the community
>
> 2: Tech support
> 2.1: website
> 2.2: CMS system, for production management
> 2.3: Testing infrastructure
> 2.4: reporting on results
> 2.5: bells and whistles, TBD
> 2.6: things I do not know about but are absolutely critical.
>
> To make this work you need #1 and #2 would be nice to have. I will
> freely admit that things in #2 will make #1 much easier, but it is
> just not necessary. And the simple fact is that this will be a lot of
> work to do for the people running it and someone needs to do it and
> they need to be a fairly advanced developer to accurately scope the
> problems for your target audience.
>
> Now to get back on message the main value here is not that people
> write code to win. It is that several people write solutions and
> that they can look at other people work to see how they did it *and*
> that still more people can comment on the code to explain how they
> could make it better if they did it again, new algorithm or better
> coding practices or something else. And this is how you build community
> and grow developers. And that is what I see as the primary benefit
> of ruby quiz is for ruby. This would also apply to CL if something
> like that happend here.
>
>
>
>
>
>
>
> > * Write a web listener that enables you to directly execute code in
> > the language through the web in a live programming environment - now
> > build a time-sharing system out of it! (My personal favorite for
> > obvious reasons.)
>
> > * Add a new kind of conditional construct to the language; perhaps one
> > that executes its sub-clauses in parallel and you get the result for
> > the one that returns first, or some such thing.
>
> > * Similarly (although on a larger scale), put a theorem prover (or, if
> > you prefer, prolog interpreter) right into the programming language/
> > environment.
>
> > * Change the MOP. For example, brain-damage it to look like Ruby. :-)
>
> > Other ideas?
>
> Please keep track of the target audience, can a Jr programmer do this in
> 8-24 hours after working a full day? This would include research time.
>
> marc
>
> --
> ······@sdf.lonestar.org
> SDF Public Access UNIX System -http://sdf.lonestar.org- Hide quoted text -
>
> - Show quoted text -
On 2007-10-28, Jeff Shrager <········@gmail.com> wrote:
>> The machinery is not needed for this to go forward, what *is* needed
>> is the victim, err editor, to own the process to ensure consistent
>> quality and steady posting of problem sets. My main point with the
>> editor was that it was necessary to build a consistent regular experience
>> for people to coalesce around.
>
> You mean, like:
>
> www.uncommonlisp.org
>
> ???
>
no I do not. The editor is a person/team that does work every week to
put out a good quiz. www.uncommonlisp.org is a website that keeps track
of neat hacks. Now there is nothing wrong with that but it is not what
I am talking about.
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
On Oct 27, 11:40 am, Jeff Shrager <········@gmail.com> wrote:
> Since the contenders in the Lightweight Language wars are now down to
> only Ruby and Lisp (Perl having been supplanted by Python, only itself
> to be rapidly overtaken by Ruby), and since Ruby is nearly Lisp, I
> think that the practice of tracking around after Ruby Quiz is
> backwards of what we ought to be doing. Instead of showing that, yeah,
> you can do in Lisp anything you can do in Ruby -- nyah nayh nyah nyah
> nyah -- we should be doing the opposite: Showing that many things that
> you can do in Lisp, you CAN'T do in Ruby.
I agree! No more should we take a reactive stance to language
promotion!
>Similarly, instead of
> writing books called "Practical Common Lisp", we ought to write one
> called "Impractical Common Lisp" which, instead of highlighting that
> Lisp can do the same "real" (read: work-a-day) computing that you can
> do in other "real" (read: "work-a-day") languages. What would be the
> chapters of such a book/elements of such a quiz. Here are some
> candidates:
>
> * Write a web listener that enables you to directly execute code in
> the language through the web in a live programming environment - now
> build a time-sharing system out of it! (My personal favorite for
> obvious reasons.)
>
> * Add a new kind of conditional construct to the language; perhaps one
> that executes its sub-clauses in parallel and you get the result for
> the one that returns first, or some such thing.
>
> * Similarly (although on a larger scale), put a theorem prover (or, if
> you prefer, prolog interpreter) right into the programming language/
> environment.
>
> * Change the MOP. For example, brain-damage it to look like Ruby. :-)
>
> Other ideas?
What about something simpler? Flipping through some papers I've
downloaded about Common Lisp, what about something like simplifying
arithmetic operations? This example is taken from Peter Norvig and
Kent Pitman's 1992 paper "Tutorial on Good Lisp Programming Style".
http://norvig.com/luv-slides.ps This example starts on page 74
* TASK: A universal expression simplifier
Overview: Develop a means of specifying translation rules to
translate an expression. Also develop a program which applies those
rules to translate a given expression.
Specifically:
When given this code:
(define-translator simplify-arithmetic
((+ x 0) ==> x)
((+ 0 x) ==> x)
((* x 0) ==> 0)
...)
Calling this:
(simplify-arithmetic '(+ (* 3 0) 7))
Will return:
7
Eric Normand
http://www.lispcast.com