"T�le Skogan" <·····@stud.cs.uit.no> writes:
> Is there anyone who attended Paul Graham's ARC talk at ILC2003 who would
> like to share their impressions?
yup, here's a short summary of my impression:
interesting stuff, but I have my doubts that he will manage to achieve
what he wants. But then, he should by no means be underestimated!
--
(espen)
Hello, I don't want to minimize your contribution but unfortunately
you only stated the obvious.
> yup, here's a short summary of my impression:
> interesting stuff, but I have my doubts that he will manage to achieve
Of course it is interesting, otherwise he wouldn't have asked. Yes,
right, you never know if someone will achieve what he wants.
> what he wants. But then, he should by no means be underestimated!
True, no one should be underestimated.
I wrote this on my computer. I'm sending it to the newsgroup now. I
don't know if I will manage to achieve what I want, but don't
underestimate me!
Thanks for reading...
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> Hello, I don't want to minimize your contribution but unfortunately
> you only stated the obvious.
>
> > yup, here's a short summary of my impression:
> > interesting stuff, but I have my doubts that he will manage to achieve
>
> Of course it is interesting, otherwise he wouldn't have asked. Yes,
> right, you never know if someone will achieve what he wants.
> [etc...]
Yes, like the original poster, I'd also be interested in a summary of
Graham's talk that goes beyond "he said some stuff, and I thought it
was [funny | interesting | of no interest to me]."
We have some good summaries of other talks. I'd be grateful if someone
who heard it would be willing to summarize what Graham actually said,
if possible.
Thanks.
Tuang writes:
> Yes, like the original poster, I'd also be interested in a summary of
> Graham's talk that goes beyond "he said some stuff, and I thought it
> was [funny | interesting | of no interest to me]."
Maybe a paper or talk transcript will be available in the ILC 2003
proceedings.
Paolo
--
Paolo Amoroso <·······@mclink.it>
········@hotmail.com (Tuang) writes:
> Yes, like the original poster, I'd also be interested in a summary of
> Graham's talk that goes beyond "he said some stuff, and I thought it
> was [funny | interesting | of no interest to me]."
The OP asked for "impressions", not a summary. I agree that I could
have added a little content to my "impressions", sorry for that. I
had a severe jet lag and things to do at work, so I guess I should have
shut my mouth :-/
--
(espen)
"T�le Skogan" <·····@stud.cs.uit.no> writes:
> Is there anyone who attended Paul Graham's ARC talk at ILC2003 who
> would like to share their impressions?
He's trying to figure out what is essential and what is non-essential.
Explicit OO constructs are probably not essential but are expected to
be constructable in terms of the primitives, so that these could in
theory be provided as part of a standard library.
He wants to write the Arc spec in Arc. He feels that in principle,
code ought to be better than English prose for this task. John
McCarthy pointed out that there is an interpretational aspect to
reading code that the code itself cannot provide. There was a slight
impedance mismatch between their statements. The sentiments of both
can be seen to be right when interpreted properly.
When John raised his hand, Paul said, "You there with the beard,
what's your name?" (of course he knew).
--
John M. Adams
T�le Skogan wrote:
> Is there anyone who attended Paul Graham's ARC talk at ILC2003 who would
> like to share their impressions?
>
> T�le
>
>
I attended the talk. I think he has some very ambitious goals, but I
think he is in a great position to accomplish them as well.
He said there are four stages to his plan (paraphrased):
1) Design and write an initial version of the language
2) Use the initial version to write actual programs to find out what
works and what doesn't work.
3) Go back and build a solid theoretical foundation for the language
using the lessons learned in step 2.
4) Build a good implementation of the language.
He is now on step 3 which means he's already written an initial version
and used it to build programs. He said he learned several important
lessons during this stage, and is not going through building the
language spec.
He said he is planning to release Arc open source, which was very good
news to me.
I personally am very excited to start using Arc. I very much like his
goals for the language. I also heard him say he isn't in a big hurry to
get this out the door. He would rather get it right before he releases
it, because it's so difficult to change the language later on.
These are just the things I remember off the top of my head, don't hold
the language to anything I said here. :)
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
> I personally am very excited to start using Arc. I very much like his
> goals for the language.
I think his goals are great- From the articles he's posted on ARC so
far, he has an extreme focus on achieving brevity of syntax and an
unusual level of expressiveness (1st class macros, for instance) and
has completely disregarded practicality or traditional wisdom on
software design.
In most cases I would disregard such ideas as unrealistic and hazy,
but after having my mind blown by "On Lisp" I am definitely going to
watch carefully how his plan plays out...
...and at worst, ARC may become the "Gertrude Stein" of programming
languages- Domewhst obtuse, but filled with ideas that are picked up
by later designers who exploit them within more conservative language
frameworks.
·····················@yahoo.com (Conrad Barski) writes:
> [Graham] has an extreme focus on achieving brevity of syntax and an
> unusual level of expressiveness (1st class macros, for instance)
What does "1st class macros" mean, exactly?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> ·····················@yahoo.com (Conrad Barski) writes:
>
>>[Graham] has an extreme focus on achieving brevity of syntax and an
>>unusual level of expressiveness (1st class macros, for instance)
>
>
> What does "1st class macros" mean, exactly?
>
With a function you can bind it to a variable via (setf avar
#'somefunc), and then call it with (funcall avar params). You can also
pass it as an argument to a function such as
(member "is" "what is your name" :test #'equal)
Currently in Common Lisp, you cannot use Macros in this sense.
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton wrote:
> Lars Brinkhoff wrote:
>
>> ·····················@yahoo.com (Conrad Barski) writes:
>>
>>> [Graham] has an extreme focus on achieving brevity of syntax and an
>>> unusual level of expressiveness (1st class macros, for instance)
>>
>>
>>
>> What does "1st class macros" mean, exactly?
>>
> With a function you can bind it to a variable via (setf avar
> #'somefunc), and then call it with (funcall avar params). You can also
> pass it as an argument to a function such as
> (member "is" "what is your name" :test #'equal)
>
> Currently in Common Lisp, you cannot use Macros in this sense.
This would be a pretty cool feature, especially if the macro expansion
can depend on dynamic properties.
Pascal
Doug Tolton <····@nospam.com> writes:
> Lars Brinkhoff wrote:
>
> > What does "1st class macros" mean, exactly?
>
> With a function you can bind it to a variable via (setf avar
> #'somefunc), and then call it with (funcall avar params). You can also
> pass it as an argument to a function such as
> (member "is" "what is your name" :test #'equal)
>
> Currently in Common Lisp, you cannot use Macros in this sense.
You can't?
* (defvar *off-by-one* t)
*OFF-BY-ONE*
* (defmacro my-dotimes ((var times) &body body)
`(dotimes (,var ,(if *off-by-one* `(1+ ,times) times))
,@body))
MY-DOTIMES
* (macro-function 'my-dotimes)
#<Interpreted Function "DEFMACRO MY-DOTIMES" {400652E1}>
* (curry * :right nil)
#<Closure Over Function "LAMBDA (FN DIRECTION &REST ARGS)" {400F1CF9}>
* (funcall * '(my-dotimes (x 10) (print x)))
(DOTIMES (X (1+ 10)) (PRINT X))
* (let ((*off-by-one* nil))
(funcall ** '(my-dotimes (x 10) (print x))))
(DOTIMES (X 10) (PRINT X))
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Doug Tolton <····@nospam.com> writes:
>
>
>>Lars Brinkhoff wrote:
>>
>>
>>>What does "1st class macros" mean, exactly?
>>
>>With a function you can bind it to a variable via (setf avar
>>#'somefunc), and then call it with (funcall avar params). You can also
>>pass it as an argument to a function such as
>>(member "is" "what is your name" :test #'equal)
>>
>>Currently in Common Lisp, you cannot use Macros in this sense.
>
>
> You can't?
>
> * (defvar *off-by-one* t)
> *OFF-BY-ONE*
> * (defmacro my-dotimes ((var times) &body body)
> `(dotimes (,var ,(if *off-by-one* `(1+ ,times) times))
> ,@body))
>
> MY-DOTIMES
> * (macro-function 'my-dotimes)
macro-function returns the Macro Expansion, and thus eliminates the
Macro call itself. If Macros were first class as functions are you
wouldn't need to eliminate the Macro to achieve this functionality,
instead you could directly bind the Macro and use it exactly as if it
were a function AFAIK.
I haven't personally run into a problem with not having Macros as first
class objects, but it would be interesting to see how they behaved
differently if they were first class. Does anyone know why Macros
aren't first class objects in CL currently?
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <····@nospam.com> writes:
> Thomas F. Burdick wrote:
>
> > Doug Tolton <····@nospam.com> writes:
> >
> >
> >>Lars Brinkhoff wrote:
> >>
> >>
> >>>What does "1st class macros" mean, exactly?
> >>
> >>With a function you can bind it to a variable via (setf avar
> >>#'somefunc), and then call it with (funcall avar params). You can also
> >>pass it as an argument to a function such as
> >>(member "is" "what is your name" :test #'equal)
> >>
> >>Currently in Common Lisp, you cannot use Macros in this sense.
> >
> >
> > You can't?
> >
> > * (defvar *off-by-one* t)
> > *OFF-BY-ONE*
> > * (defmacro my-dotimes ((var times) &body body)
> > `(dotimes (,var ,(if *off-by-one* `(1+ ,times) times))
> > ,@body))
> >
> > MY-DOTIMES
> > * (macro-function 'my-dotimes)
>
> macro-function returns the Macro Expansion, and thus eliminates the
> Macro call itself.
Look at the transcript again, MACRO-FUNCTION returns the *function*
that implements the macro: when called with a form, and an
environment, it returns the expanded form.
> If Macros were first class as functions are you wouldn't need to
> eliminate the Macro to achieve this functionality, instead you could
> directly bind the Macro and use it exactly as if it were a function
> AFAIK.
??? It *is* a function, of the vague type (source, environment) -> source.
You want to bind them? You can bind a variable to the macro function,
as I showed above. You could get it back in the function namespace
just like you would with a function:
(defvar *iteration-macro* (macro-function 'dotimes))
(defun foo ()
(macrolet ((doit (&whole form &environment env)
(funcall *iteration-macro* form env)))
(doit (x 10) (print x))))
;; This next form is a lot more interesting if the implementation
;; has an interpreter, so FOO isn't already compiled.
(let ((*iteration-macro* (macro-function 'my-dotimes)))
(compile 'foo))
> I haven't personally run into a problem with not having Macros as first
> class objects, but it would be interesting to see how they behaved
> differently if they were first class. Does anyone know why Macros
> aren't first class objects in CL currently?
Again, unless I'm missing something in your argument, they are. Maybe
you should show me an example of what it would mean for macros to
"be"[*] first class.
[*] "be" in ironic quotes, because they are already, and I'm guessing
the issue is really something else hiding behind the term "first class
macros".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Doug Tolton <····@nospam.com> writes:
>
>
>>Thomas F. Burdick wrote:
>>
>>
>>>Doug Tolton <····@nospam.com> writes:
>>>
>>>
>>>
>>>>Lars Brinkhoff wrote:
>>>>
>>>>
>>>>
>>>>>What does "1st class macros" mean, exactly?
>>>>
>>>>With a function you can bind it to a variable via (setf avar
>>>>#'somefunc), and then call it with (funcall avar params). You can also
>>>>pass it as an argument to a function such as
>>>>(member "is" "what is your name" :test #'equal)
>>>>
>>>>Currently in Common Lisp, you cannot use Macros in this sense.
>>>
>>>
>>>You can't?
>>>
>>> * (defvar *off-by-one* t)
>>> *OFF-BY-ONE*
>>> * (defmacro my-dotimes ((var times) &body body)
>>> `(dotimes (,var ,(if *off-by-one* `(1+ ,times) times))
>>> ,@body))
>>>
>>> MY-DOTIMES
>>> * (macro-function 'my-dotimes)
>>
>>macro-function returns the Macro Expansion, and thus eliminates the
>>Macro call itself.
>
>
> Look at the transcript again, MACRO-FUNCTION returns the *function*
> that implements the macro: when called with a form, and an
> environment, it returns the expanded form.
>
>
>>If Macros were first class as functions are you wouldn't need to
>>eliminate the Macro to achieve this functionality, instead you could
>>directly bind the Macro and use it exactly as if it were a function
>>AFAIK.
>
>
> ??? It *is* a function, of the vague type (source, environment) -> source.
>
> You want to bind them? You can bind a variable to the macro function,
> as I showed above. You could get it back in the function namespace
> just like you would with a function:
>
> (defvar *iteration-macro* (macro-function 'dotimes))
>
> (defun foo ()
> (macrolet ((doit (&whole form &environment env)
> (funcall *iteration-macro* form env)))
> (doit (x 10) (print x))))
>
> ;; This next form is a lot more interesting if the implementation
> ;; has an interpreter, so FOO isn't already compiled.
> (let ((*iteration-macro* (macro-function 'my-dotimes)))
> (compile 'foo))
>
>
>>I haven't personally run into a problem with not having Macros as first
>>class objects, but it would be interesting to see how they behaved
>>differently if they were first class. Does anyone know why Macros
>>aren't first class objects in CL currently?
>
>
> Again, unless I'm missing something in your argument, they are. Maybe
> you should show me an example of what it would mean for macros to
> "be"[*] first class.
>
> [*] "be" in ironic quotes, because they are already, and I'm guessing
> the issue is really something else hiding behind the term "first class
> macros".
>
I've acknowledged before that I'm still pretty much a newbie at Lisp, so
perhaps it's me that is missing something.
During the Macro discussion at the ILC and then again in conversation, I
repeatedly heard people refer to the fact that Macros were not first
class objects (in the way functions are first class objects).
I know from my use that I cannot use Macro's interchangeably with
functions. Specifically if I create a Macro, I can't pass it into a
function the same whay I could pass a function in, rather I have to deal
with it in a specific way, knowing that it is a Macro and not a
function. Perhaps this isn't the distinction other people are making,
but in languages such as Python this is the specific meaning of a first
class object. In Python when you say a function is first class, it
means you don't have to do anything special such as create a delegate or
function pointer to pass it as an argument to a function.
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <····@nospam.com> writes:
> >> I haven't personally run into a problem with not having Macros as
> >> first class objects, but it would be interesting to see how they
> >> behaved differently if they were first class. Does anyone know why
> >> Macros aren't first class objects in CL currently?
>
> > Again, unless I'm missing something in your argument, they are.
> I've acknowledged before that I'm still pretty much a newbie at Lisp,
> so perhaps it's me that is missing something.
>
>
> During the Macro discussion at the ILC and then again in conversation,
> I repeatedly heard people refer to the fact that Macros were not first
> class objects (in the way functions are first class objects).
Perhaps not in the context of Common Lisp.
> I know from my use that I cannot use Macro's interchangeably with
> functions. Specifically if I create a Macro, I can't pass it into a
> function the same whay I could pass a function in, rather I have to
> deal with it in a specific way, knowing that it is a Macro and not a
> function. Perhaps this isn't the distinction other people are making,
> but in languages such as Python this is the specific meaning of a
> first class object. In Python when you say a function is first class,
> it means you don't have to do anything special such as create a
> delegate or function pointer to pass it as an argument to a function.
If you know what arguments to pass, it's easy:
CL-USER(1): (defmacro foo (x) `(bar ,x))
FOO
CL-USER(2): (macro-function 'foo)
#<Interpreted Function FOO @ #x71643b7a>
CL-USER(3): (funcall * '(foo hi) nil)
(BAR HI)
CL-USER(4):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Doug Tolton <····@nospam.com> writes:
> I haven't personally run into a problem with not having Macros as
> first class objects, but it would be interesting to see how they
> behaved differently if they were first class. Does anyone know why
> Macros aren't first class objects in CL currently?
It's hard to compile the source code if it isn't generated
until run-time.
·············@comcast.net wrote:
> Doug Tolton <····@nospam.com> writes:
>
>
>>I haven't personally run into a problem with not having Macros as
>>first class objects, but it would be interesting to see how they
>>behaved differently if they were first class. Does anyone know why
>>Macros aren't first class objects in CL currently?
>
>
> It's hard to compile the source code if it isn't generated
> until run-time.
I think to make macros really useful as first-class objects, you would
need to keep local lexical environments "alive" at runtime in which you
can expand them.
Pascal
·············@comcast.net wrote:
> Doug Tolton <····@nospam.com> writes:
>
>
>>I haven't personally run into a problem with not having Macros as
>>first class objects, but it would be interesting to see how they
>>behaved differently if they were first class. Does anyone know why
>>Macros aren't first class objects in CL currently?
>
>
> It's hard to compile the source code if it isn't generated
> until run-time.
(defun generate-and-compile (x)
(compile nil `(lambda (y) (+ ,x y)))
(funcall (generate-and-compile 42) 42)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ·············@comcast.net wrote:
>> Doug Tolton <····@nospam.com> writes:
>>
>>>I haven't personally run into a problem with not having Macros as
>>>first class objects, but it would be interesting to see how they
>>>behaved differently if they were first class. Does anyone know why
>>>Macros aren't first class objects in CL currently?
>> It's hard to compile the source code if it isn't generated
>> until run-time.
>
>
> (defun generate-and-compile (x)
> (compile nil `(lambda (y) (+ ,x y)))
>
> (funcall (generate-and-compile 42) 42)
Yeah, but it really doesn't help performance in this case:
(map 'list (lambda (x y)
(funcall (generate-and-compile x) y))
list-one
list-two)
Thomas F. Burdick wrote:
> Doug Tolton <····@nospam.com> writes:
>
>
>>Lars Brinkhoff wrote:
>>
>>
>>>What does "1st class macros" mean, exactly?
>>
>>With a function you can bind it to a variable via (setf avar
>>#'somefunc), and then call it with (funcall avar params). You can also
>>pass it as an argument to a function such as
>>(member "is" "what is your name" :test #'equal)
>>
>>Currently in Common Lisp, you cannot use Macros in this sense.
>
>
> You can't?
>
> * (defvar *off-by-one* t)
> *OFF-BY-ONE*
> * (defmacro my-dotimes ((var times) &body body)
> `(dotimes (,var ,(if *off-by-one* `(1+ ,times) times))
> ,@body))
>
> MY-DOTIMES
> * (macro-function 'my-dotimes)
> #<Interpreted Function "DEFMACRO MY-DOTIMES" {400652E1}>
> * (curry * :right nil)
> #<Closure Over Function "LAMBDA (FN DIRECTION &REST ARGS)" {400F1CF9}>
> * (funcall * '(my-dotimes (x 10) (print x)))
> (DOTIMES (X (1+ 10)) (PRINT X))
> * (let ((*off-by-one* nil))
> (funcall ** '(my-dotimes (x 10) (print x))))
> (DOTIMES (X 10) (PRINT X))
>
Stop showing off!
:)
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Lars Brinkhoff wrote:
>
> ·····················@yahoo.com (Conrad Barski) writes:
> > [Graham] has an extreme focus on achieving brevity of syntax and an
> > unusual level of expressiveness (1st class macros, for instance)
>
> What does "1st class macros" mean, exactly?
one would suppose, that it can be bound. like a function.
>
> --
> Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
> Brinkhoff Consulting http://www.brinkhoff.se/
·····················@yahoo.com (Conrad Barski) wrote
>
> I think his goals are great- From the articles he's posted on ARC so
> far, he has an extreme focus on achieving brevity of syntax and an
> unusual level of expressiveness (1st class macros, for instance) and
> has completely disregarded practicality or traditional wisdom on
> software design.
In what way(s) has he "completely disregarded practicality or
traditional wisdom on software design"? (I'm not disagreeing, BTW. I'm
just wondering what he might have said.)
Thanks.
> In what way(s) has he "completely disregarded practicality or
> traditional wisdom on software design"?
I was being vague and kind of meant that in two ways.
First of all, from a language designer standpoint, I would think the
conventional wisdom would be to come up with a strong fundamental
architecture for the language and then build concepts on top of that-
Whereas PG has been gathering various opinions on "cool" syntax and
language niceties (traditionally not considered very important, but PG
disagrees), has hacked together a "sloppy" interpreter that he can use
to prototype them- The actual core design is being left as a
close-to-the-last step. (I'm sure Larry Wall has some opinions on
this)
Second of all, from the standpoint of _using_ the language, it is
clear that he has some suspicion of modern design philosophies, such
as the whole GOF Patterns movement, the importance of encapsulation,
avoidance of program behavior that is context-specific (he likes
macros, especially anaphoric ones, that have significant dependencies
on context - And his use of automatically generated variables, such as
his use of the underscore character in macro shortcuts)- In fact, he
deemphasizes OOP in general, which I would argue pretty much embodies
the current wisdom of software design.
In brief, I can see people look at his approach and say "We tried that
already, it was called 'spagetti programming' and we're trying to move
away from that."
I think there are some valid benefits to his approach, though.
Conrad Barski wrote:
>>In what way(s) has he "completely disregarded practicality or
>>traditional wisdom on software design"?
>
>
> I was being vague and kind of meant that in two ways.
>
> First of all, from a language designer standpoint, I would think the
> conventional wisdom would be to come up with a strong fundamental
> architecture for the language and then build concepts on top of that-
> Whereas PG has been gathering various opinions on "cool" syntax and
> language niceties (traditionally not considered very important, but PG
> disagrees), has hacked together a "sloppy" interpreter that he can use
> to prototype them- The actual core design is being left as a
> close-to-the-last step. (I'm sure Larry Wall has some opinions on
> this)
>
> Second of all, from the standpoint of _using_ the language, it is
> clear that he has some suspicion of modern design philosophies, such
> as the whole GOF Patterns movement, the importance of encapsulation,
> avoidance of program behavior that is context-specific (he likes
> macros, especially anaphoric ones, that have significant dependencies
> on context - And his use of automatically generated variables, such as
> his use of the underscore character in macro shortcuts)- In fact, he
> deemphasizes OOP in general, which I would argue pretty much embodies
> the current wisdom of software design.
There are a lot of people rethinking the whole strong OOP point of view.
Python for example has classes, but does not enforce encapsulation.
As a developer that has used OOP for a long time, I have seen many of
the limitations to that approach. I think OOP has it's uses, but I've
found languages such as Java and C# overly rigid in their application of
it. I like the Multiple dispatch model in Lisp much better for
instance, as well as first class functions.
After having done a quite a bit of work in Python and learning Lisp, I
went back to work on a fairly large program I'd written in C#. The
amount of time you spend dealing with type cast errors is quite
aggravating IMO. I find that I am far more efficient solving problems
in Python and Lisp than I am under C# or Java. In fact I would say it's
a rather large stretch to say OOP embodies the "current wisdom" in
software design, more to the point I would say it embodies the current
*trend* in software design. Those two statements are not equivalent.
>
> In brief, I can see people look at his approach and say "We tried that
> already, it was called 'spagetti programming' and we're trying to move
> away from that."
OOP didn't fix spagetti programming. I have seen horribly spagettified
programs written in both Java and C#. In fact I have yet to see *any*
programming paradigm that will make an ill-conceived approach to
software design turn out well. I think you made a big logical leap to
say that anything not OOP is spagetti programming. Lisp has CLOS, but
there is quite a bit of code that doesn't use it, does that make all
non-CLOS code spagetti code? I think not.
>
> I think there are some valid benefits to his approach, though.
I agree with this point. :)
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Yeah, the final straw in C++ came when I had a "Variant" template
class and had to generate a function object with the boost function
template libraries to generate a function type that returned said
variant. I think I spent about 2 evenings trying to get the returned
template variable *just so* so that the compiler accepted it as the
correct type definition, requiring many, many layers of angled
template brackets and finally determined that it was *probably* not
possible for unknown reasons.
In Lisp, this would have been trivial.
Doug Tolton wrote:
> OOP didn't fix spagetti programming.
It's been said that OO replaces spaghetti with ravioli.
What you get is a big pile of classes with inheritance
all over the place (and in inappropriate places), with
all conditionals being handled implicitly by polymorphism.
When this is done well, the resulting code can be very nice
to read (once you're used to the style). When it's done
badly, it's as bad as the old pile o' GOTOs ever was.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> Doug Tolton wrote:
>
> > OOP didn't fix spagetti programming.
>
> It's been said that OO replaces spaghetti with ravioli.
I'd say it's more like tagliatelli.
> What you get is a big pile of classes with inheritance
> all over the place (and in inappropriate places), with
> all conditionals being handled implicitly by polymorphism.
> When this is done well, the resulting code can be very nice
> to read (once you're used to the style). When it's done
> badly, it's as bad as the old pile o' GOTOs ever was.
Oh, it's much much worse. Maybe it's just because I cut my teeth on
BASIC, but spaghetti (or tagliatelli) OOP code in, say, Java, is 1000
times harder to follow than good old spaghetti and polpetti BASIC.
(Or FORTRAN).
<duck>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Gareth McCaughan <·····@g.local> writes:
>
>
>>Doug Tolton wrote:
>>
>>
>>>OOP didn't fix spagetti programming.
>>
>>It's been said that OO replaces spaghetti with ravioli.
>
>
> I'd say it's more like tagliatelli.
>
>
>>What you get is a big pile of classes with inheritance
>>all over the place (and in inappropriate places), with
>>all conditionals being handled implicitly by polymorphism.
>>When this is done well, the resulting code can be very nice
>>to read (once you're used to the style). When it's done
>>badly, it's as bad as the old pile o' GOTOs ever was.
>
>
> Oh, it's much much worse. Maybe it's just because I cut my teeth on
> BASIC, but spaghetti (or tagliatelli) OOP code in, say, Java, is 1000
> times harder to follow than good old spaghetti and polpetti BASIC.
> (Or FORTRAN).
So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
the hands of a wood-pusher. Lispniks love high-powered tools which can
lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
kenny
ps. Should we share with everyone that McCarthy, when asked point blank
by Paul Graham, shared that he had voted for Arnold? "We muscle men have
to stick together," he said as he flexed on stage.
kt
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
>
>
> Thomas F. Burdick wrote:
>
>> Gareth McCaughan <·····@g.local> writes:
>>
>>
>>> Doug Tolton wrote:
>>>
>>>
>>>> OOP didn't fix spagetti programming.
>>>
>>>
>>> It's been said that OO replaces spaghetti with ravioli.
>>
>>
>>
>> I'd say it's more like tagliatelli.
>>
>>
>>> What you get is a big pile of classes with inheritance
>>> all over the place (and in inappropriate places), with
>>> all conditionals being handled implicitly by polymorphism.
>>> When this is done well, the resulting code can be very nice
>>> to read (once you're used to the style). When it's done
>>> badly, it's as bad as the old pile o' GOTOs ever was.
>>
>>
>>
>> Oh, it's much much worse. Maybe it's just because I cut my teeth on
>> BASIC, but spaghetti (or tagliatelli) OOP code in, say, Java, is 1000
>> times harder to follow than good old spaghetti and polpetti BASIC.
>> (Or FORTRAN).
>
>
> So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
> the hands of a wood-pusher. Lispniks love high-powered tools which can
> lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
>
I'm not saying that OOP is bad per se. I think it's like much of the
other tools, in the hands of a good hacker it's a great boon, in the
hands of a newb it sucks.
Like I said, I have yet to find any paradigm that makes up for stupidity
or ignorance.
> kenny
>
> ps. Should we share with everyone that McCarthy, when asked point blank
> by Paul Graham, shared that he had voted for Arnold? "We muscle men have
> to stick together," he said as he flexed on stage.
>
Yeah, that was a funny sequence. I'm guessing that room was filled
mostly with democrats? I woulda voted for Arnold too. :) Cruz was just
freaky IMO.
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Kenny Tilton wrote:
[in reply to Doug Tolton, me, and Thomas Burdick:]
> So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
> the hands of a wood-pusher. Lispniks love high-powered tools which can
> lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
I certainly wasn't saying that OO is bad. Only that
bad programmers can produce pasta in any language.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
> Kenny Tilton wrote:
>
> [in reply to Doug Tolton, me, and Thomas Burdick:]
> > So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
> > the hands of a wood-pusher. Lispniks love high-powered tools which can
> > lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
>
> I certainly wasn't saying that OO is bad. Only that
> bad programmers can produce pasta in any language.
Absolutely. And for the record, I'm a big fan of both CLOS and
TAGBODY/GO, when used properly.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Gareth McCaughan <·····@g.local> writes:
>
>
>>Kenny Tilton wrote:
>>
>>[in reply to Doug Tolton, me, and Thomas Burdick:]
>>
>>>So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
>>>the hands of a wood-pusher. Lispniks love high-powered tools which can
>>>lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
>>
>>I certainly wasn't saying that OO is bad. Only that
>>bad programmers can produce pasta in any language.
>
>
> Absolutely. And for the record, I'm a big fan of both CLOS and
> TAGBODY/GO, when used properly.
Oh, OK, I thought I saw CLOS getting the Lisp Treatment(tm), as when
Lisp gets marked down as slow because a newbie goes on a consing binge.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
>
>
> Thomas F. Burdick wrote:
>
>> Gareth McCaughan <·····@g.local> writes:
>>
>>
>>> Kenny Tilton wrote:
>>>
>>> [in reply to Doug Tolton, me, and Thomas Burdick:]
>>>
>>>> So no one is saying OO is bad, right? It's OO in Java or OO in CLOS in
>>>> the hands of a wood-pusher. Lispniks love high-powered tools which can
>>>> lop off limbs if used without finesse. Such is CLOS. Esp. with Cells.
>>>
>>>
>>> I certainly wasn't saying that OO is bad. Only that
>>> bad programmers can produce pasta in any language.
>>
>>
>>
>> Absolutely. And for the record, I'm a big fan of both CLOS and
>> TAGBODY/GO, when used properly.
>
>
> Oh, OK, I thought I saw CLOS getting the Lisp Treatment(tm), as when
> Lisp gets marked down as slow because a newbie goes on a consing binge.
>
> kenny
>
I chucked in a couple of inverted logic twists, where I asked a question
then asked it in the negative. Maybe it looked that way, but I wasn't
intending to trash CLOS. I was trying to make the point that all
non-CLOS code isn't crap. Meaning you can write good non-OO code just
as you can write crappy OO code.
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Thomas F. Burdick writes:
> I'd say it's more like tagliatelli.
^
e
> times harder to follow than good old spaghetti and polpetti BASIC.
^
e
Paolo
--
Paolo Amoroso <·······@mclink.it>
Gareth McCaughan wrote:
> Doug Tolton wrote:
>
>
>>OOP didn't fix spagetti programming.
>
>
> It's been said that OO replaces spaghetti with ravioli.
> What you get is a big pile of classes with inheritance
> all over the place (and in inappropriate places), with
> all conditionals being handled implicitly by polymorphism.
> When this is done well, the resulting code can be very nice
> to read (once you're used to the style). When it's done
> badly, it's as bad as the old pile o' GOTOs ever was.
>
There was a whole Pasta theory to programming (IIRC), which ordered the
resulting programs like that:
1. Spaghetti (worst)
2. Lazania -- layers
3. Ravioli -- being the best. e.g. Beans or something.
But, OOL don't fix the design by its own. I'm working with Java since
1999 and most of the systems I saw (and wrote) ended up to be speghetti.
Perhaps in Java, they should be called Spaghlets :))
--
Ivan Toshkov
email: ··········@last-name.org
Ivan Toshkov wrote:
>
> There was a whole Pasta theory to programming (IIRC), which ordered the
> resulting programs like that:
>
> 1. Spaghetti (worst)
> 2. Lazania -- layers
> 3. Ravioli -- being the best. e.g. Beans or something.
>
Odd. Our preferred naming for badly-structured C++ and Java
code was "goulash" -- something about the hungarian notation.
Bear
>>>>> "Ray" == Ray Dillinger <····@sonic.net> writes:
Ray> Odd. Our preferred naming for badly-structured C++ and Java
Ray> code was "goulash" -- something about the hungarian notation.
Could also be a reference to quality.
In Denmark, goulash has a somewhat dubious reputation going back to
World War I. Denmark remained neutral and some scooped up quite a
fortune selling food to the warring parties. A lot of it was labelled
"goulash" and was made out of the lowest possible quality ingredients.
Those greedy characters involved in that business was named "goulash
barons" due to the wealth they gained and the match between the
quality of their products and their moral and general behaviour.
With all due apologies to the hungarians which definitely knows how to
make very good goulash.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Ray Dillinger wrote:
> Ivan Toshkov wrote:
>
>>There was a whole Pasta theory to programming (IIRC), which ordered the
I did a bit of googling and found it:
http://www.gnu.org/fun/jokes/pasta.code.html
>>resulting programs like that:
>>
>>1. Spaghetti (worst)
>>2. Lazania -- layers
Its spelled Lasagna, but my spell checker didn't complain! Odd.
>>3. Ravioli -- being the best. e.g. Beans or something.
>>
>
>
> Odd. Our preferred naming for badly-structured C++ and Java
> code was "goulash" -- something about the hungarian notation.
Damn! I've forgotten about the hungarian notation. And now the
nightmares will start again.
>
> Bear
--
Ivan Toshkov
email: ··········@last-name.org
Hi Doug Tolton,
>> In brief, I can see people look at his approach and say "We tried that
>> already, it was called 'spaghetti programming' and we're trying to move
>> away from that."
>
> OOP didn't fix spaghetti programming. [...]
Paul Graham clearly believes OOP is a source of spaghetti programming.
From note 178 on page 408 of ANSI Common Lisp:
Let's play that back one more time: /we can make all these types of
modifications without even looking at the rest of the code/. This idea
may sound alarmingly familiar to some readers. It is the recipe for
spaghetti code.
The object-oriented model makes it easy to build up programs by
accretion. What this often means, in practice, is that it provides a
structured way to write spaghetti code. This is not necessarily bad,
but it is not entirely good either.
A lot of code in the real world is spaghetti code, and this is probably
not going to change soon. For programs that would have ended up as
spaghetti anyway, the object-oriented model is good: they will at least
be structured spaghetti. But for programs that might otherwise have
avoided this fate, object-oriented abstractions could be more dangerous
than useful.
I agree with the tenor of these conclusions.
Regards,
Adam
> ·····················@yahoo.com (Conrad Barski) wrote
>
>>I think his goals are great- From the articles he's posted on ARC so
>>far, he has an extreme focus on achieving brevity of syntax ...
If it will help, one thing I remember: afterwards in a small group he
brought up COND having too many parentheses (et tu, brute?). he thinks
we can do something more like setq place1 value1 place2 value2.
(if test1 ifso1 test2 ifso2)
this would be allowed:
(if test1 ifso1 test2)
by having the form return the result of test2 should test1 fail.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Doug Tolton wrote:
> T�le Skogan wrote:
>
>> Is there anyone who attended Paul Graham's ARC talk at ILC2003 who would
>> like to share their impressions?
>>
>> T�le
>>
>>
> I attended the talk. I think he has some very ambitious goals, but I
> think he is in a great position to accomplish them as well.
>
> He said there are four stages to his plan (paraphrased):
> 1) Design and write an initial version of the language
> 2) Use the initial version to write actual programs to find out what
> works and what doesn't work.
> 3) Go back and build a solid theoretical foundation for the language
> using the lessons learned in step 2.
> 4) Build a good implementation of the language.
>
> He is now on step 3 which means he's already written an initial version
> and used it to build programs. He said he learned several important
> lessons during this stage, and is not going through building the
> language spec.
Correction he is "now" going through building the language spec.
>
> He said he is planning to release Arc open source, which was very good
> news to me.
>
> I personally am very excited to start using Arc. I very much like his
> goals for the language. I also heard him say he isn't in a big hurry to
> get this out the door. He would rather get it right before he releases
> it, because it's so difficult to change the language later on.
>
> These are just the things I remember off the top of my head, don't hold
> the language to anything I said here. :)
>
>
> --
> Doug Tolton
> (format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
>
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")