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.~a" "dtolton" "ya" "hoo" "com")
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.
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 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.
> 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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> 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 :))
Thomas F. Burdick wrote: > Gareth McCaughan <gj...@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.
>>> 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.~a" "dtolton" "ya" "hoo" "com")
>>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 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.
[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.
> [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 <gj...@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.
>>> [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.~a" "dtolton" "ya" "hoo" "com")
>>>>> "Ray" == Ray Dillinger <b...@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. - peto...@hal.com (Michael A. Petonic)
