Brian Raab wrote:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
The statement is wrong. (Common) Lisp is by all means a zombie, having
been dead a long time ago. :) As an undead, it has several powers
unknown to mere mortal languages. :)
Cheers
--
Marco
Brian Raab wrote:
> Buy a good C++ compiler and write programs in a MODERN language,
...and what do I do with the C++ compiler?
Pascal
P.S.: http://alu.cliki.net
According to Pascal Costanza <········@web.de>:
> Brian Raab wrote:
> > Buy a good C++ compiler and write programs in a MODERN language,
>
> ...and what do I do with the C++ compiler?
The troll posted a similarly worded message that Smalltalk is dead to
c.l.smalltalk. One may safely assume other language groups are also hit.
Just ignore it.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
····@netmemetic.com (Ng Pheng Siong) writes:
> The troll posted a similarly worded message that Smalltalk is dead to
> c.l.smalltalk. One may safely assume other language groups are also hit.
It also posted to numerous other groups, and *always* cross-posted to can.vlsi.
--
··········@acm.org As the air to a bird, or the sea to a fish,
http://www.bawue.de/~jjk/ so is contempt to the contemptible. [Blake]
_buy_ a compiler? so, this is a troll anyway, but one whose author is
particularly out of touch with reality.
(and on the lisp being dead, there was some famous quote from a good decade
or two ago that went something like 'lisp doesnt seem any deader than normal'..)
I think he's just upset he doesn't understand lisp.
isildur
On Wed, 5 Oct 2004, Brian Raab wrote:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
>
In article <····························@posting.google.com>,
···········@yahoo.com (Brian Raab) wrote:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
Haven't you heard? C++ is also dead. Java killed it,
and then C# killed Java. My advice is to wait for
whatever fells C# in the next six months or so and
jump on that bandwagon. It will surely be a dynamic
language with garbage collection, macros, conditions,
and good support for object-oriented programming and
other paradigms.
Sashank Varma <····@vanderbilt.edu> writes:
> In article <····························@posting.google.com>,
> ···········@yahoo.com (Brian Raab) wrote:
>
> > Buy a good C++ compiler and write programs in a MODERN language,
> > forget Lisp, it's dead.
>
> Haven't you heard? C++ is also dead. Java killed it,
> and then C# killed Java. My advice is to wait for
> whatever fells C# in the next six months or so and
> jump on that bandwagon. It will surely be a dynamic
> language with garbage collection, macros, conditions,
> and good support for object-oriented programming and
> other paradigms.
No, it will be VB.NET++
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
···········@yahoo.com (Brian Raab) writes:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
Yeah, let's do that.... But wait, we'd have to hire at least 3 times
as many programmers.... no, I don't think we can afford that.
--
(espen)
···········@yahoo.com (Brian Raab) wrote in message news:<····························@posting.google.com>...
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
Hmm, you can't seem to be able to follow your own recommendation here.
You have Lisp on your mind, that's why you are here.
Why is Lisp on your mind?
Let me guess: it's coming close to midterm time in this Fall 2004
semester, and you're having trouble with your Scheme coursework.
:)
···········@yahoo.com (Brian Raab) writes:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
I always amuses me when someone takes time out of their life to post
some stupid troll post like this. I mean, why would anyone care that
people like to program in Lisp?
Nevermind that I took the trouble to respond to such an inane post.
Maybe I also am bored.
Speaking of C++, I really used to love that language. But it grew to
a point where it became unweildy for me. I think that point was when
stuff like dynamic_cast and static_cast entered the language
vocabulary.
Also, why the hell isn't Common Lisp considered modern by this poster?
I have yet to see anything from Java (just to pick a language at
random) that has anything more modern than Common Lisp. Not that I am
a Java expert or anything.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
>
> Speaking of C++, I really used to love that language. But it grew to
> a point where it became unweildy for me. I think that point was when
> stuff like dynamic_cast and static_cast entered the language
> vocabulary.
I parted ways with C++ when the software patterns circus came to town
and I saw the "singleton" pattern. It seemed to me that the language
(or the use of it) had gone insane and it was time to walk, not run,
to the nearest exit.
Gregm
Greg Menke <··········@toadmail.com> wrote:
> I parted ways with C++ when the software patterns circus came to town
> and I saw the "singleton" pattern. It seemed to me that the language
> (or the use of it) had gone insane and it was time to walk, not run,
> to the nearest exit.
Having seen the curiosity of the Singleton pattern in Python, I could
only conclude that it is the natural consequence of the belief that
"global variables" are evil. The programmer does not think of class
names as "variables", and so feels free to use a class name to refer to
a global, unique object.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.
Karl A. Krueger wrote:
> Greg Menke <··········@toadmail.com> wrote:
>
>>I parted ways with C++ when the software patterns circus came to town
>>and I saw the "singleton" pattern. It seemed to me that the language
>>(or the use of it) had gone insane and it was time to walk, not run,
>>to the nearest exit.
>
> Having seen the curiosity of the Singleton pattern in Python, I could
> only conclude that it is the natural consequence of the belief that
> "global variables" are evil. The programmer does not think of class
> names as "variables", and so feels free to use a class name to refer to
> a global, unique object.
Not quite. The history of the Singleton seems to stem from two origins:
In C++ one can have global variables, but there is no way to enforce an
order for initializing those global variables. One element of the
Singleton pattern is that you use lazy initializion, so this solves that
specific problem. In Smalltalk, you really don't have global variables,
so singleton objects are indeed a good way to have global data. The
dictum at the time when the Design Pattern book was written was that
patterns are somehow language independent. The wrong conclusion from the
fact that singletons are used in two very different languages was that
it is indeed a pattern.
Since then, the authors of the Design Patterns book (at least Erich
Gamma) have publicly stated that it was a mistake to include the
Singleton pattern in the book.
As far as I can see, the pattern community now doesn't believe in the
"language independence" principle anymore, or at least, they don't
regard it as important anymore. There is a much stronger focus on the
notion of forces that are resolved by patterns: Each pattern description
consists, among other elements, of a section that describes what forces
make it hard to find a good solution. For example, the lack of
initialization ordering in C++ is such a force. In other languages, that
force doesn't exist - for example, I am aware of Java and Common Lisp as
languages that don't have that problem (I don't know enough about
Python). Therefore, the Singleton pattern is _not_ a pattern in those
languages!
The only real issue here is that a considerably large group of
programmers uses such patterns without checking the premises. (Patterns
also include sections about the "initial context" - the situation in
which it makes sense to use a pattern. Patterns are not meant to be used
blindly.)
The pattern format is a very useful and appropriate way for describing
solutions for recurring problems. Dismissing patterns because of the
Singleton pattern is like dismissing Lisp because of the lack of arrays
in Lisp 1.5.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Karl A. Krueger wrote:
> > Greg Menke <··········@toadmail.com> wrote:
> >
> >>I parted ways with C++ when the software patterns circus came to town
> >>and I saw the "singleton" pattern. It seemed to me that the language
> >>(or the use of it) had gone insane and it was time to walk, not run,
> >>to the nearest exit.
> > Having seen the curiosity of the Singleton pattern in Python, I could
> > only conclude that it is the natural consequence of the belief that
> > "global variables" are evil. The programmer does not think of class
> > names as "variables", and so feels free to use a class name to refer to
> > a global, unique object.
>
> Not quite. The history of the Singleton seems to stem from two
> origins: In C++ one can have global variables, but there is no way to
> enforce an order for initializing those global variables. One element
> of the Singleton pattern is that you use lazy initializion, so this
> solves that specific problem. In Smalltalk, you really don't have
> global variables, so singleton objects are indeed a good way to have
> global data. The dictum at the time when the Design Pattern book was
> written was that patterns are somehow language independent. The wrong
> conclusion from the fact that singletons are used in two very
> different languages was that it is indeed a pattern.
>
> Since then, the authors of the Design Patterns book (at least Erich
> Gamma) have publicly stated that it was a mistake to include the
> Singleton pattern in the book.
>
> As far as I can see, the pattern community now doesn't believe in the
> "language independence" principle anymore, or at least, they don't
> regard it as important anymore. There is a much stronger focus on the
> notion of forces that are resolved by patterns: Each pattern
> description consists, among other elements, of a section that
> describes what forces make it hard to find a good solution. For
> example, the lack of initialization ordering in C++ is such a
> force. In other languages, that force doesn't exist - for example, I
> am aware of Java and Common Lisp as languages that don't have that
> problem (I don't know enough about Python). Therefore, the Singleton
> pattern is _not_ a pattern in those languages!
>
> The only real issue here is that a considerably large group of
> programmers uses such patterns without checking the
> premises. (Patterns also include sections about the "initial context"
> - the situation in which it makes sense to use a pattern. Patterns are
> not meant to be used blindly.)
>
> The pattern format is a very useful and appropriate way for describing
> solutions for recurring problems. Dismissing patterns because of the
> Singleton pattern is like dismissing Lisp because of the lack of
> arrays in Lisp 1.5.
>
I'm not dismissing software design patterns simply because of
singletons, but because all signs point to it being one more
great-sounding idea that ends up being of the most benefit to
consultants who use it to generate acronyms & terminology to make
their presentations look good. Not that I think software patterns are
useless, but I get the impression that the cost of using them doesn't
come with a big enough payoff to make it worth the trouble. On the
plus side, each new software fad seems to reach a smaller and smaller
audience, so thats OK.
OTOH, I did dismiss C/C++ as my high level language of choice because
of patterns. I looked at a few of the given implementations for a
couple of the patterns from that book and none of them looked like
anything but the most obscure pile of write-only macrology. Lisp
started looking really good at that point.
Gregm
Greg Menke wrote:
> I'm not dismissing software design patterns simply because of
> singletons, but because all signs point to it being one more
> great-sounding idea that ends up being of the most benefit to
> consultants who use it to generate acronyms & terminology to make
> their presentations look good. Not that I think software patterns are
> useless, but I get the impression that the cost of using them doesn't
> come with a big enough payoff to make it worth the trouble. On the
> plus side, each new software fad seems to reach a smaller and smaller
> audience, so thats OK.
The Design Patterns book has a subtext that strongly suggests that
patterns must be complex, must use some kind of UML notation and must
have something to do with OOP. Nothing of this is true. Here is an
example of a set of patterns that are quite different:
http://c2.com/cgi/wiki?SimplyUnderstoodCode (written by Richard Gabriel
specifically to show that there is more to patterns than people usually
think).
> OTOH, I did dismiss C/C++ as my high level language of choice because
> of patterns. I looked at a few of the given implementations for a
> couple of the patterns from that book and none of them looked like
> anything but the most obscure pile of write-only macrology. Lisp
> started looking really good at that point.
Yes, I totally agree that that book is pretty bad.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Greg Menke wrote:
>
> > I'm not dismissing software design patterns simply because of
> > singletons, but because all signs point to it being one more
> > great-sounding idea that ends up being of the most benefit to
> > consultants who use it to generate acronyms & terminology to make
> > their presentations look good.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Not that I think software patterns are
> > useless, but I get the impression that the cost of using them doesn't
> > come with a big enough payoff to make it worth the trouble. On the
> > plus side, each new software fad seems to reach a smaller and smaller
> > audience, so thats OK.
>
> The Design Patterns book has a subtext that strongly suggests that
> patterns must be complex, must use some kind of UML notation and must
> have something to do with OOP. Nothing of this is true. Here is an
> example of a set of patterns that are quite different:
> http://c2.com/cgi/wiki?SimplyUnderstoodCode (written by Richard
> Gabriel specifically to show that there is more to patterns than
> people usually think).
Macros ARE software patterns.
But some software patterns are less localized than macros. It's
worthwhile to document them.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> I'm not dismissing software design patterns simply because of
> singletons, but because all signs point to it being one more
> great-sounding idea that ends up being of the most benefit to
> consultants who use it to generate acronyms & terminology to make
> their presentations look good. Not that I think software patterns are
> useless, but I get the impression that the cost of using them doesn't
> come with a big enough payoff to make it worth the trouble. On the
> plus side, each new software fad seems to reach a smaller and smaller
> audience, so thats OK.
Software patterns are simply a means of expressing implementations of
common problems among engineers. In my experience hardly any
*consultants* understand or use design patterns. Engineers on the
other hand, use them all the time.
The benefit of patterns is communication. If I say to one of my
engineers put in a "fast-lane reader" or "Factory" to handle a
problem, I don't have to sit down and architect out the whole thing
for him, he knows what I mean, and I know what he will build. That is
what patterns are for, communication. It also means when someone has
to maintain the code in the future, then name of it tell them right
away what it is intended to do. A well implemented pattern can also
easily be replaced if necessary. There is no cost to using patterns,
only benefits, and I wouldn't call them a fad since they have been
heavily used in R&D shops since the mid-90's and are only growing in
use. One day soon even your average consultants may be using them. :)
·········@hotmail.com (Darren) writes:
> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
>
> > I'm not dismissing software design patterns simply because of
> > singletons, but because all signs point to it being one more
> > great-sounding idea that ends up being of the most benefit to
> > consultants who use it to generate acronyms & terminology to make
> > their presentations look good. Not that I think software patterns are
> > useless, but I get the impression that the cost of using them doesn't
> > come with a big enough payoff to make it worth the trouble. On the
> > plus side, each new software fad seems to reach a smaller and smaller
> > audience, so thats OK.
>
> Software patterns are simply a means of expressing implementations of
> common problems among engineers. In my experience hardly any
> *consultants* understand or use design patterns. Engineers on the
> other hand, use them all the time.
>
> The benefit of patterns is communication. If I say to one of my
> engineers put in a "fast-lane reader" or "Factory" to handle a
> problem, I don't have to sit down and architect out the whole thing
> for him, he knows what I mean, and I know what he will build. That is
> what patterns are for, communication. It also means when someone has
> to maintain the code in the future, then name of it tell them right
> away what it is intended to do. A well implemented pattern can also
> easily be replaced if necessary. There is no cost to using patterns,
> only benefits, and I wouldn't call them a fad since they have been
> heavily used in R&D shops since the mid-90's and are only growing in
> use. One day soon even your average consultants may be using them. :)
This is the same sales pitch that every software innovation gets. If
somebody starts telling me about "factories" and "fast-lane readers",
they had better first give me the top-to-bottom detailed requirements
& design documents to back it up. Otherwise its the same as the old
ill-specified, grown-in-place cruft that it was supposed to replace.
Any improvement in any area that is pitched as having "no cost, only
benefits" trips my bullshit detectors. Not that all improvements are
bad, but there is always a tradeoff and usually its far more
complicated than the proponents of the improvement are inclined to
specify (or sometimes even be aware of).
If your assertion that "well implemented" patterns are portable,
replaceable, etc.., then I'd reply that anything thats well
implemented is as well. It seems to me the design pattern stuff is
mostly pushing the pile of junk around underneath the carpet. The
biggest problems in designing and implementing software isn't software
techniques its getting the requirements, design and implementation
right. By that I mean, old-fashioned requirements gathering, figuring
out what the users really want as opposed to what they say they want,
getting enough budget and manpower to do the work properly and having
management around that knows when to get involved and when to butt
out. If these factors are not present, no design pattern is going to
save your ass. If they are, then design patterns could be of some
use- but then in that kind of environment, most any software
"engineering" technique would also work.
As far as "growing in use" is concerned, so are the management fads.
Does that make them somehow more useful as well? I think we've
finally reached the half-way point towards the disappearance of the
CMM scale. You can tell because everybody gets their "average" score
now, which is enough to qualify to do the work, all the authors have
published their books & done their consulting and its starting to be
time to reinvent the process some more. TQM seemed to have tanked a
bit early- but at least its gone. OTOH, ISO is doing it right, they
can reinvent themselves every year and put the squeeze on everyone
that buys into it.
Gregm
Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> ·········@hotmail.com (Darren) writes:
>
> > Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> This is the same sales pitch that every software innovation gets. If
> somebody starts telling me about "factories" and "fast-lane readers",
> they had better first give me the top-to-bottom detailed requirements
> & design documents to back it up. Otherwise its the same as the old
> ill-specified, grown-in-place cruft that it was supposed to replace.
>
I think you missed the point of patterns. Patterns are just a verbal
and diagrammatic language for designers to communicate with. The code
examples you saw were not to be taken literally, they were shown only
to try to impress upon the reader what the patter is about. Same as
an example of code showing a loop would be shown to illustrate loops.
Saying "use a facade" is the same as saying "use an if condition". It
is the same kind of communication, but grown beyond the language
constructs into commonly developed components. Its used to build
design documents, from requirements.
> Any improvement in any area that is pitched as having "no cost, only
> benefits" trips my bullshit detectors. Not that all improvements are
> bad, but there is always a tradeoff and usually its far more
> complicated than the proponents of the improvement are inclined to
> specify (or sometimes even be aware of).
>
What could be the cost of better communication and understanding? If
you ask me how a device driver works, I can say, "It's facade to a
mediator of a device specific implementation, loaded by an abstract
factory." That simple. This can of course be explained in many other
ways, but by using the patterns, facade, mediator and abstract
factory, what I understand, and what you understand will be equal.
Because those represent quantified components. Same applies if you
told me I need a loop to solve a problem.
> If your assertion that "well implemented" patterns are portable,
> replaceable, etc.., then I'd reply that anything thats well
> implemented is as well. It seems to me the design pattern stuff is
> mostly pushing the pile of junk around underneath the carpet. The
> biggest problems in designing and implementing software isn't software
> techniques its getting the requirements, design and implementation
> right.
You sound like a HUGE advocate of design patterns then, and also UML.
Design patterns are basically a part of UML. UML is used in gathering
requirements (Use-Case diagrams) and turning those requirements into
designs (Entity diagrams, where patterns live and Interaction
diagrams). I do agree that anything well written is replacable,
becuase if it is, then it is probably a design pattern of some kind.
> By that I mean, old-fashioned requirements gathering, figuring
> out what the users really want as opposed to what they say they want,
> getting enough budget and manpower to do the work properly and having
> management around that knows when to get involved and when to butt
> out. If these factors are not present, no design pattern is going to
> save your ass. If they are, then design patterns could be of some
> use- but then in that kind of environment, most any software
> "engineering" technique would also work.
Ok, you have gone all the way to the Rational Unified Process now.
That is something that UML is a merely a part of. RUP is a defined
processes of requirements gathering, design, documentation and
programming. With iteration at all levels of the process. You are a
huge advocate of this stuff and don't know it! :)
You should check out:
http://www.sei.cmu.edu/publications/documents/04.reports/04tr011.html
RUP is the bible for many software architects. It is a heavy process,
but the priniciples are sound and very valuable to understand. It
isn't always necessary to follow the RUP in its entirety, it depends
on the size of the project and the flexibility/understanding of
management.
> As far as "growing in use" is concerned, so are the management fads.
> Does that make them somehow more useful as well? I think we've
> finally reached the half-way point towards the disappearance of the
> CMM scale. You can tell because everybody gets their "average" score
> now, which is enough to qualify to do the work, all the authors have
> published their books & done their consulting and its starting to be
> time to reinvent the process some more. TQM seemed to have tanked a
> bit early- but at least its gone. OTOH, ISO is doing it right, they
> can reinvent themselves every year and put the squeeze on everyone
> that buys into it.
>
> Gregm
I agree with your stance on management practices, but I am an
architect, it is my job to fight management becuase they have little
or no grasp of what it really takes to build software, or how it
should be done and why. They push ISO (in the sofware world a
complete waste of time), I push RUP. We meet somewhere in between.
But classic battles like that exists for all software development. Do
we do what management wants, or do it the right way? :)
- Darren
Darren wrote:
> What could be the cost of better communication and understanding? If
> you ask me how a device driver works, I can say, "It's facade to a
> mediator of a device specific implementation, loaded by an abstract
> factory." That simple.
If you're in the real world, then establishing that vocabulary comes
with an impact on the training budget (either hours browsing c2 or money
on courses). It's worth it in the long term, but it is not cost free,
and may not yield benefit over a short term project.
Pete
Darren wrote:
> I think you missed the point of patterns. Patterns are just a verbal
> and diagrammatic language for designers to communicate with.
You know, if this is the problem, then the "hacker's dictionary" or
Jargon File is a much better solution. Disregard the strictly-
historical entries, but when jargon is well established in a shop,
it is utterly easy to communicate very precisely about designs,
implementations, and (most importantly) errors and software
failures.
Someone implemented a swapsort. It didn't work correctly. He
couldn't find the problem. I was able to look at the input
and output and tell him he had a "fencepost error". He found
it in one minute. Problem solved.
Someone was baffled by the fact that their C program "returned"
from one procedure to a strange address in memory that wasn't
even assigned to their program, causing it to crash. Another
engineer recognized the symptom and told him he'd probably
"smashed the stack" and he should check the widths of his
integer variables. Problem solved.
Someone else wanted to know why we needed the new 64-bit machines
for the language application. The response: "It's bigger than a
moby."
We had a recurring problem with access times on a server that
wore out a lot of disk drives. Diagnosis: our heavily-linked
data structure was "baffling the cache and making it thrash."
Solution: buy more memory as an interim, redesign the data structure
with better locality of reference as a more permanent fix.
If you want productive engineers, give them a vocabulary for
talking about limitations, bugs and failures; the design part
isn't particularly challenging.
Bear
Sorry for the weird followup, my newsfeed didn't get your reply, so I
copied over from groups.google.
>
> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > ·········@hotmail.com (Darren) writes:
> >
> > > Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > This is the same sales pitch that every software innovation gets. If
> > somebody starts telling me about "factories" and "fast-lane readers",
> > they had better first give me the top-to-bottom detailed requirements
> > & design documents to back it up. Otherwise its the same as the old
> > ill-specified, grown-in-place cruft that it was supposed to replace.
> >
> I think you missed the point of patterns. Patterns are just a verbal
> and diagrammatic language for designers to communicate with. The code
> examples you saw were not to be taken literally, they were shown only
> to try to impress upon the reader what the patter is about. Same as
> an example of code showing a loop would be shown to illustrate loops.
> Saying "use a facade" is the same as saying "use an if condition". It
> is the same kind of communication, but grown beyond the language
> constructs into commonly developed components. Its used to build
> design documents, from requirements.
Yeah, COBOL is self documenting too. Guess how many unmaintainable
and un-understandable COBOL systems there are out there.
If its just vocabulary then why should I care? The ground is littered
with all sorts of fancy vocabularies and formalized crap that takes up
more time learning than it saves when you actually try to get things
done. What real projects need is unremitting attention to the real
details- most any vocabulary will do IF you get the details right.
And getting them right means investing the time of sufficient numbers
of committed people in an atmosphere that encourages finding and
solving the system's problems and not spent obsessing about process.
> > Any improvement in any area that is pitched as having "no cost, only
> > benefits" trips my bullshit detectors. Not that all improvements are
> > bad, but there is always a tradeoff and usually its far more
> > complicated than the proponents of the improvement are inclined to
> > specify (or sometimes even be aware of).
> >
> What could be the cost of better communication and understanding? If
> you ask me how a device driver works, I can say, "It's facade to a
> mediator of a device specific implementation, loaded by an abstract
> factory." That simple. This can of course be explained in many other
> ways, but by using the patterns, facade, mediator and abstract
> factory, what I understand, and what you understand will be equal.
> Because those represent quantified components. Same applies if you
> told me I need a loop to solve a problem.
If you told me that sentence, I'd tell you to go away and come back
with the pile of documentation showing the driver you're talking about
from top to bottom; api's down to the registers- because the sentence
you gave me doesn't tell me anything useful. Its great high-level,
low-detail conceptual stuff for CS101 or if you're pitching something
to typical management, but not if you are trying to tell me about
something real that needs implementing, debugging, porting, whatever.
> > If your assertion that "well implemented" patterns are portable,
> > replaceable, etc.., then I'd reply that anything thats well
> > implemented is as well. It seems to me the design pattern stuff is
> > mostly pushing the pile of junk around underneath the carpet. The
> > biggest problems in designing and implementing software isn't software
> > techniques its getting the requirements, design and implementation
> > right.
>
> You sound like a HUGE advocate of design patterns then, and also UML.
> Design patterns are basically a part of UML. UML is used in gathering
> requirements (Use-Case diagrams) and turning those requirements into
> designs (Entity diagrams, where patterns live and Interaction
> diagrams). I do agree that anything well written is replacable,
> becuase if it is, then it is probably a design pattern of some kind.
Oh theres nothing wrong with UML as such, its a regurgitation of the
systems analysis and design methodologies from 20+ years ago. I see
nothing new worth the fuss or the salesjobs. Start talking to me
about patterns and we're wasting time because we're not talking about
the detailed, contradictory, incomplete and ever changing specs that
we have to somehow produce an implementation of.
> > By that I mean, old-fashioned requirements gathering, figuring
> > out what the users really want as opposed to what they say they want,
> > getting enough budget and manpower to do the work properly and having
> > management around that knows when to get involved and when to butt
> > out. If these factors are not present, no design pattern is going to
> > save your ass. If they are, then design patterns could be of some
> > use- but then in that kind of environment, most any software
> > "engineering" technique would also work.
>
> Ok, you have gone all the way to the Rational Unified Process now.
> That is something that UML is a merely a part of. RUP is a defined
> processes of requirements gathering, design, documentation and
> programming. With iteration at all levels of the process. You are a
> huge advocate of this stuff and don't know it! :)
>
> You should check out:
> http://www.sei.cmu.edu/publications/documents/04.reports/04tr011.html
>
> RUP is the bible for many software architects. It is a heavy process,
> but the priniciples are sound and very valuable to understand. It
> isn't always necessary to follow the RUP in its entirety, it depends
> on the size of the project and the flexibility/understanding of
> management.
Oh I've been to the Rational indoctrination classes and the SEI
classes. Sounds great, looks great, costs HUGE- and still doesn't
solve the hard problems that make projects fail because the people
that push it keep expecting magic bullets. "Bible" indeed. Knuth's
texts are bibles, Stevens/Comer texts are bibles- thats not even true-
they are among the seminal books that make the science in Computer
Science. Rational will be long gone down the rathole and Knuths texts
will still be the magnificent pieces of work they are.
Its funny how often I keep hearing that proviso you give. And its
also funny to see how many people are invested in The Process instead
of actually working on the project. No doubt its also true that
projects which fail obviously didn't follow The Process- else they
certainly would've suceeded.
I give the smallest possible damn for The Process. What I want is a
focus on the crazy-ass complexities of the system in question with
enough people around to make sure it all gets recorded instead of
fooling around with ever more subtle shadings of nomenclature.
> I agree with your stance on management practices, but I am an
> architect, it is my job to fight management becuase they have little
> or no grasp of what it really takes to build software, or how it
> should be done and why. They push ISO (in the sofware world a
> complete waste of time), I push RUP. We meet somewhere in between.
> But classic battles like that exists for all software development. Do
> we do what management wants, or do it the right way? :)
>
No wonder we're disagreeing. I do implementation and debugging and
porting and working around broken-ass, ill-considered designs and
implementations- and fixing my own broken-ass software that I wrote on
the basis of wrong, incomplete and/or missing specs or just because I
was dumb. I do bits, you do abstract.
Gregm
Greg Menke <··········@toadmail.com> writes:
> And its
> also funny to see how many people are invested in The Process instead
> of actually working on the project.
I think this is The Process's main strength, not a side effect or
byproduct. The reason RUP sells so well is /precisely/ that it allows
one to produce tangible evidence of hard work even if one is incapable
of producing a working system.
Ari.
--
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
> Yeah, COBOL is self documenting too. Guess how many unmaintainable
> and un-understandable COBOL systems there are out there.
>
> If its just vocabulary then why should I care? The ground is littered
> with all sorts of fancy vocabularies and formalized crap that takes up
> more time learning than it saves when you actually try to get things
> done. What real projects need is unremitting attention to the real
> details- most any vocabulary will do IF you get the details right.
> And getting them right means investing the time of sufficient numbers
> of committed people in an atmosphere that encourages finding and
> solving the system's problems and not spent obsessing about process.
Well, you don't have to care, but it does work. Despite my preaching
on patterns, I do believe whatever works best for your communication
is probably the best thing to use. And I don't obsess about process
either, I belive in using only as much as necessary for the size of
the project and the apparent risks that the process might mitigate.
As I said, RUP is heavy weight.
> If you told me that sentence, I'd tell you to go away and come back
> with the pile of documentation showing the driver you're talking about
> from top to bottom; api's down to the registers- because the sentence
> you gave me doesn't tell me anything useful. Its great high-level,
> low-detail conceptual stuff for CS101 or if you're pitching something
> to typical management, but not if you are trying to tell me about
> something real that needs implementing, debugging, porting, whatever.
If you knew design patterns, it would tell you alot more then that.
And it would indeed help you with implementing, debugging, porting,
whatever. It's not a silver bullet, but it helps. But your right,
that is not enough to build on. Its a start though, from there
someone could build out the UML using those patterns.
> Oh theres nothing wrong with UML as such, its a regurgitation of the
> systems analysis and design methodologies from 20+ years ago. I see
> nothing new worth the fuss or the salesjobs. Start talking to me
> about patterns and we're wasting time because we're not talking about
> the detailed, contradictory, incomplete and ever changing specs that
> we have to somehow produce an implementation of.
Your right, patterns don't solve those problems. Some can help
minimize them though. I suggest you send your project manager on a
long walk off a short ledge.
> Oh I've been to the Rational indoctrination classes and the SEI
> classes. Sounds great, looks great, costs HUGE- and still doesn't
> solve the hard problems that make projects fail because the people
> that push it keep expecting magic bullets. "Bible" indeed. Knuth's
> texts are bibles, Stevens/Comer texts are bibles- thats not even true-
> they are among the seminal books that make the science in Computer
> Science. Rational will be long gone down the rathole and Knuths texts
> will still be the magnificent pieces of work they are.
As I said above, you have serious management problems. BTW: Rational
is long gone...they were bought by IBM a few years ago :)
> Its funny how often I keep hearing that proviso you give. And its
> also funny to see how many people are invested in The Process instead
> of actually working on the project. No doubt its also true that
> projects which fail obviously didn't follow The Process- else they
> certainly would've suceeded.
>
> I give the smallest possible damn for The Process. What I want is a
> focus on the crazy-ass complexities of the system in question with
> enough people around to make sure it all gets recorded instead of
> fooling around with ever more subtle shadings of nomenclature.
I totally agree. I say the process is good, but its not the only
variable in the equation. The crazy-ass copmlexities are what make
programming fun, if we ever removed those, we wouldn't be needed and
secretraries with PC's will make 6 figures :)
> No wonder we're disagreeing. I do implementation and debugging and
> porting and working around broken-ass, ill-considered designs and
> implementations- and fixing my own broken-ass software that I wrote on
> the basis of wrong, incomplete and/or missing specs or just because I
> was dumb. I do bits, you do abstract.
>
> Gregm
I do abstract and concrete. My team and I have have been working on
the code for our current project for over 2 years. I built the
architecture and worked on it for 6 months, then started hiring
developers. I coded along with everyone else. After over 3 million
lines of code, we hit our projected deadline to the day, Sept. 20,
2004 (including QA testing). We released to our first
customer...today actually (Oct 11). That speaks volumes to RUP, UML
and Patterns in my eyes.
I have been programming for over 14 years and it shocked me that we
met the deadline and beat the budget (that only happens in text books
right?). We had the usual feature-creep, sales messing with
schedules, management not understanding and being afraid of what we
were doing, etc., etc., but that was all anticipated in the original
plan (mostly, there were some hicups/tradeoffs). All-in-all, I can't
think of any way the project could have went better...other then a
mulit-million dollar bonus for the team for doing such an excellent
job. Didn't happen...I'll just have to be happy with a success story
:D
·········@hotmail.com (Darren) writes:
> I built the architecture and worked on it for 6 months
Speaking of vocabulary, what does it mean to "build the architecture"?
Assuming you're not referring to buildings, isn't "the architecture"
here instead a plan for how things will be built, as opposed to
something one "builds" unto itself? Is the word "design" now
shamefully inferior to the malapropian "architect"?
--
Steven E. Harris
Greg Menke <··········@toadmail.com> writes:
> If its just vocabulary then why should I care? The ground is littered
What's a thread? A process? A reference? A pointer? An object?
Endless hours are spent in discussion on usenet and elswhere in
which the participants are quite often talking completely past each
other because they're using different definitions for these terms
that "everyone knows". I'd say that a shared vocabulary is pretty
damn important.
(And what else is the ANSL CL glossary? That's a superb bit of work,
and not only applicable within the standard itself but has had a real
impact on the wider CL programming community. I can say "designator"
and everybody will know what I'm talking about)
I'm tempted to agree with you on RUP and UML, though. Standards are
only useful when they're standardising on something you'd actually
want to do.
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> writes:
> Greg Menke <··········@toadmail.com> writes:
>
> > If its just vocabulary then why should I care? The ground is littered
>
> What's a thread? A process? A reference? A pointer? An object?
>
> Endless hours are spent in discussion on usenet and elswhere in
> which the participants are quite often talking completely past each
> other because they're using different definitions for these terms
> that "everyone knows". I'd say that a shared vocabulary is pretty
> damn important.
>
> (And what else is the ANSL CL glossary? That's a superb bit of work,
> and not only applicable within the standard itself but has had a real
> impact on the wider CL programming community. I can say "designator"
> and everybody will know what I'm talking about)
I have no problem with technical vocabulary, the more technical and
precise the better as far as I'm concerned. What bugs me is the
gratuitous abstraction & vague terminology that so often accompanies
the Next Big Things in software engineering.
I've not read the ANSI CL glossary, but if it can hang with CLHS, then
I think its a great example of what a standard should be.
Gregm
Sorry for another weird response- my ISP doesn't seem to be getting
any of your posts... funky, I'll also look around for inadvertent gnus
settings...
>
> > Yeah, COBOL is self documenting too. Guess how many unmaintainable
> > and un-understandable COBOL systems there are out there.
> >
> > If its just vocabulary then why should I care? The ground is littered
> > with all sorts of fancy vocabularies and formalized crap that takes up
> > more time learning than it saves when you actually try to get things
> > done. What real projects need is unremitting attention to the real
> > details- most any vocabulary will do IF you get the details right.
> > And getting them right means investing the time of sufficient numbers
> > of committed people in an atmosphere that encourages finding and
> > solving the system's problems and not spent obsessing about process.
>
> Well, you don't have to care, but it does work. Despite my preaching
> on patterns, I do believe whatever works best for your communication
> is probably the best thing to use. And I don't obsess about process
> either, I belive in using only as much as necessary for the size of
> the project and the apparent risks that the process might mitigate.
> As I said, RUP is heavy weight.
My point is nearly any halfway reasonable vocabulary will work IF you
have your team, management and customers working on the project with
you. If you don't, no vocabulary is going to help you very much.
> > If you told me that sentence, I'd tell you to go away and come back
> > with the pile of documentation showing the driver you're talking about
> > from top to bottom; api's down to the registers- because the sentence
> > you gave me doesn't tell me anything useful. Its great high-level,
> > low-detail conceptual stuff for CS101 or if you're pitching something
> > to typical management, but not if you are trying to tell me about
> > something real that needs implementing, debugging, porting, whatever.
>
> If you knew design patterns, it would tell you alot more then that.
> And it would indeed help you with implementing, debugging, porting,
> whatever. It's not a silver bullet, but it helps. But your right,
> that is not enough to build on. Its a start though, from there
> someone could build out the UML using those patterns.
Nope, it would tell me some abstract things about program structure
which might end up a close approximation to whats actually there, but
it won't tell me any of the important stuff. If I'm to do anything
more than exchange powerpoint presentations with 4 bullets per page in
20+ point fonts on a pretty background, I must have the detail and
nothing else will do.
>
> > Oh theres nothing wrong with UML as such, its a regurgitation of the
> > systems analysis and design methodologies from 20+ years ago. I see
> > nothing new worth the fuss or the salesjobs. Start talking to me
> > about patterns and we're wasting time because we're not talking about
> > the detailed, contradictory, incomplete and ever changing specs that
> > we have to somehow produce an implementation of.
>
> Your right, patterns don't solve those problems. Some can help
> minimize them though. I suggest you send your project manager on a
> long walk off a short ledge.
So then why do the people pitching this stuff not start with the tough
problems first? I dont' recall hearing a sales pitch on The Process
that included tangling with the nasty little issues. Instead its been
lots of fluff wrt Living Documents and pictures and lines and
byzantine symbology, usually coupled with a vastly expensive piece of
software that sort of works but ends up being clumsy, ill-supported
and not much better than the one its replacing.
> > No wonder we're disagreeing. I do implementation and debugging and
> > porting and working around broken-ass, ill-considered designs and
> > implementations- and fixing my own broken-ass software that I wrote on
> > the basis of wrong, incomplete and/or missing specs or just because I
> > was dumb. I do bits, you do abstract.
> >
> > Gregm
>
> I do abstract and concrete. My team and I have have been working on
> the code for our current project for over 2 years. I built the
> architecture and worked on it for 6 months, then started hiring
> developers. I coded along with everyone else. After over 3 million
> lines of code, we hit our projected deadline to the day, Sept. 20,
> 2004 (including QA testing). We released to our first
> customer...today actually (Oct 11). That speaks volumes to RUP, UML
> and Patterns in my eyes.
>
> I have been programming for over 14 years and it shocked me that we
> met the deadline and beat the budget (that only happens in text books
> right?). We had the usual feature-creep, sales messing with
> schedules, management not understanding and being afraid of what we
> were doing, etc., etc., but that was all anticipated in the original
> plan (mostly, there were some hicups/tradeoffs). All-in-all, I can't
> think of any way the project could have went better...other then a
> mulit-million dollar bonus for the team for doing such an excellent
> job. Didn't happen...I'll just have to be happy with a success story
> :D
Then I congratulate you on your fortunate, lucky and skilled choices
of team-members, your management who knows what they're doing and
customers who know what they want. Are you telling me that The
Process is what brought you success and not the people involved with
the project?
I've been in the software racket for about the same length of time and
seen a number of sucessful and a number of failed projects too. I
don't recall any project that got tangled up in The Process really
succeeding- some fail, some get salvaged, others kind of stagger along
getting reinvented until they work well enough to be usable. The
sucessful ones were those with the right sort of people cracking the
whips and the right sort doing the work- and customers that were
willing to find out and implement what they really want and need.
Gregm
Cesar Rabak <······@acm.org> writes:
> Greg Menke escreveu:
> [snipped]
> > My point is nearly any halfway reasonable vocabulary will work IF you
> > have your team, management and customers working on the project with
> > you. If you don't, no vocabulary is going to help you very much.
> >
>
> Human experience says otherwise. A vocabulary helps to create a more
> syntetic means of expressing yourself in a certain domain.
>
> By this reason, in almost every Standards body the terminology
> documents are the first to be delivered.
>
> In a certain way a vocabulary (and in cases even some syntatic rules)
> helps even to _think_ better.
I'm not saying vocabularly is useless, simply that when it comes to
current software engineering practice (and I might say fads), there
just isn't much that its gaining relative to what was done 20 some
years ago. Pictures are prettier, etc.. but I don't see much else-
and the continual introduction of reinvented concepts and terminology
and process distracts from the problems that have classically caused
projects continuing trouble if not failure.
> [snipped]
>
> >> If you knew design patterns, it would tell you alot more then
> >> that. And it would indeed help you with implementing, debugging,
> >> porting,
> >>whatever. It's not a silver bullet, but it helps. But your right,
> >>that is not enough to build on. Its a start though, from there
> >>someone could build out the UML using those patterns.
> > Nope, it would tell me some abstract things about program structure
> > which might end up a close approximation to whats actually there, but
> > it won't tell me any of the important stuff. If I'm to do anything
> > more than exchange powerpoint presentations with 4 bullets per page in
> > 20+ point fonts on a pretty background, I must have the detail and
> > nothing else will do.
> >
>
> Humm. . . I think we have to agree on the definition of "important
> stuff"! Perhaps we've to start assembling a vocabulary? ;-)
Small set of Important stuff, since we're talking about a driver;
kernel apis that the driver can use, apis the the kernel wants the
driver to exhibit, device data sheets, device family(ies) the driver
must support w/ failure modes & strategies, dataflows on large and
small scales, whatever bizzare manipulation and kludging the driver
has to do to make the hardware & OS work- with particular emphasis on
whatever existing standards need to be variously followed, broken,
hacked around or ignored. Plus, whatever extra weirdo stuff the user
wants the driver to do.
What I don't need to hear about is design patterns, and easy on the
UML- a little goes a long way.
> >
> >>Your right, patterns don't solve those problems. Some can help
> >>minimize them though. I suggest you send your project manager on a
> >>long walk off a short ledge.
> > So then why do the people pitching this stuff not start with the
> > tough
> > problems first? I dont' recall hearing a sales pitch on The Process
> > that included tangling with the nasty little issues. Instead its been
> > lots of fluff wrt Living Documents and pictures and lines and
> > byzantine symbology, usually coupled with a vastly expensive piece of
> > software that sort of works but ends up being clumsy, ill-supported
> > and not much better than the one its replacing.
> >
>
> Well if we include sales people, we cannot expect exactly sound
> advice, isn't it?
The pitches I've attended have usually had "Software Engineering
Professionals" doing the pitching and classes- on-site. They're quite
good at showing The Process to good effect on trivial examples, but
tend not to be very into the enormous quantity of detail of big,
complicated systems. And they tend to not know how to fix the
software they're selling when it fails- and don't have much to say
when you ask them how well their software will be supported in 5 years
or so when the company is sold or out of business and we're in
mid-lifecycle on the project we bought the system for.
> OTOH, are we sure the people who were supposed to have been helped by
> the methodology really grasped it well?
No we're not. Each new groundbreaking software engineering
methodology seems to require a similar or larger investment in time,
money and hassle, with the same sort of payoff the last one had.
> I see in a lot of places where the scenario you describe the
> diagnostic generally is a non well swallowed 'heavy
> process/methodology' though in a working week ('cause sales pitched
> their product as 'intuitive' 'simple to use', etc).
Oh the swallowing is often rather forced- generally on the people
trying to do the work, generally by the people buying into the
methodologies.
Gregm
Darren wrote:
> Software patterns are simply a means of expressing implementations of
> common problems among engineers. In my experience hardly any
> *consultants* understand or use design patterns. Engineers on the
> other hand, use them all the time.
>
> The benefit of patterns is communication. If I say to one of my
> engineers put in a "fast-lane reader" or "Factory" to handle a
> problem, I don't have to sit down and architect out the whole thing
> for him, he knows what I mean, and I know what he will build. That is
> what patterns are for, communication.
The problem with this is that no one is able to communicate more
clearly than s/he thinks.
A pointy-haired boss acquires buzzwords, which also happen to be
the names of patterns he doesn't understand, and tells his
engineers to implement <buzzword> to solve the current problem.
Engineer looks at problem trying to understand how <pattern> is
even applicable and winds up implementing, under protest ignored
by PHB, some unbelievably bizarre and misbegotten crap.
It is actively harmful to give some kinds of bosses precise
vocabulary for describing detailed technical patterns; by misuse
of the vocabulary, especially if given to micromanagement, they
can screw up a project worse than any amount of vague handwaving
ever could.
Engineers are hired because they understand the technical stuff.
Bosses are hired (hopefully) because they understand how to
motivate people and get them to work together. Neither field of
understanding implies the other. And patterns are useful as
communication only when all the communicators understand them.
Bear
Ray Dillinger <····@sonic.net> wrote in message news:<···················@typhoon.sonic.net>...
> The problem with this is that no one is able to communicate more
> clearly than s/he thinks.
>
> A pointy-haired boss acquires buzzwords, which also happen to be
> the names of patterns he doesn't understand, and tells his
> engineers to implement <buzzword> to solve the current problem.
> Engineer looks at problem trying to understand how <pattern> is
> even applicable and winds up implementing, under protest ignored
> by PHB, some unbelievably bizarre and misbegotten crap.
Hehe. I doubt there are to many bosses out there, who aren't
technical, who are telling the engineers to use any particular
patterns. If there is, I bet the engineers are ignoring him and
building things the right way becuase the boss wouldn't be able to
tell if the pattern was used or not.
>
> It is actively harmful to give some kinds of bosses precise
> vocabulary for describing detailed technical patterns; by misuse
> of the vocabulary, especially if given to micromanagement, they
> can screw up a project worse than any amount of vague handwaving
> ever could.
It's not something for bosses, its for engineers. If the boss is an
engineer then great.
>
> Engineers are hired because they understand the technical stuff.
> Bosses are hired (hopefully) because they understand how to
> motivate people and get them to work together. Neither field of
> understanding implies the other. And patterns are useful as
> communication only when all the communicators understand them.
>
> Bear
Agreed.
·········@hotmail.com (Darren) writes:
> Hehe. I doubt there are to many bosses out there, who aren't
> technical, who are telling the engineers to use any particular
> patterns. If there is, I bet the engineers are ignoring him and
> building things the right way becuase the boss wouldn't be able to
> tell if the pattern was used or not.
No, this kind of thing is rather normal. You don't dare lie to him about
following the order becuase if he finds out (he hears some engineers
talking about some "other" technology while getting a cup of coffee),
he's justified in firing you. And these fiats often come from very high
up: CTOs and such.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> ·········@hotmail.com (Darren) writes:
>
>> Hehe. I doubt there are to many bosses out there, who aren't
>> technical, who are telling the engineers to use any particular
>> patterns. If there is, I bet the engineers are ignoring him and
>> building things the right way becuase the boss wouldn't be able to
>> tell if the pattern was used or not.
>
> No, this kind of thing is rather normal. You don't dare lie to him about
> following the order becuase if he finds out (he hears some engineers
> talking about some "other" technology while getting a cup of coffee),
> he's justified in firing you. And these fiats often come from very high
> up: CTOs and such.
Actually, let me clarify: many of these people are actually technical in
their background. They got a BS in EE or something. Then they got their
MBA and started working up the management ladder. Since they weren't too
technically savvy, they moved into upper management instead of being
involved in more expert technical roles. So they think they know about
the technology and feel that if they don't make the impression that
they're still up to date on technical issues, they'll lose "street cred"
with the coders. Of course, that's a load of bunk. Most smart people
realize that a good coder and a good manager (even a manager of coders)
need almost completely different skills. So they read "trade magazines"
(infomercials on glossy paper) and push whatever they read about down
the coders' throats. Oh well.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
According to Rahul Jain <·····@nyct.net>:
> if they don't make the impression that
> they're still up to date on technical issues, they'll lose "street cred"
> with the coders.
I think it's their management they want to impress. They "act management"
with the techies below, and "act techie" with the management above.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- AES Encryption for SQLite
Rahul Jain <·····@nyct.net> writes:
> ·········@hotmail.com (Darren) writes:
>
> > Hehe. I doubt there are to many bosses out there, who aren't
> > technical, who are telling the engineers to use any particular
> > patterns. If there is, I bet the engineers are ignoring him and
> > building things the right way becuase the boss wouldn't be able to
> > tell if the pattern was used or not.
>
> No, this kind of thing is rather normal. You don't dare lie to him about
> following the order becuase if he finds out (he hears some engineers
> talking about some "other" technology while getting a cup of coffee),
> he's justified in firing you. And these fiats often come from very high
> up: CTOs and such.
Yup.
Rahul Jain <·····@nyct.net> writes:
> ·········@hotmail.com (Darren) writes:
>
>> Hehe. I doubt there are to many bosses out there, who aren't
>> technical, who are telling the engineers to use any particular
>> patterns. If there is, I bet the engineers are ignoring him and
>> building things the right way becuase the boss wouldn't be able to
>> tell if the pattern was used or not.
>
> No, this kind of thing is rather normal. You don't dare lie to him about
> following the order becuase if he finds out (he hears some engineers
> talking about some "other" technology while getting a cup of coffee),
> he's justified in firing you. And these fiats often come from very high
> up: CTOs and such.
That would explain the abysmal success rate of projects in
our industry.
·········@hotmail.com (Darren) writes:
[...]
> Software patterns are simply a means of expressing implementations of
> common problems among engineers. In my experience hardly any
> *consultants* understand or use design patterns. Engineers on the
> other hand, use them all the time.
If there commonly used solutions to common problems then shouldn't
these pattens be abstracted away into some sort of libary?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
? the Platypus {aka David Formosa} <········@zeta.org.au> writes:
> ·········@hotmail.com (Darren) writes:
>
> [...]
>
> > Software patterns are simply a means of expressing implementations of
> > common problems among engineers. In my experience hardly any
> > *consultants* understand or use design patterns. Engineers on the
> > other hand, use them all the time.
>
> If there commonly used solutions to common problems then shouldn't
> these pattens be abstracted away into some sort of libary?
Yes. In fact, many such patterns have been abstracted away
into some sort of a library that is called "Common Lisp".
On 2004-10-09, Greg Menke <··········@toadmail.com> wrote:
>
> I'm not dismissing software design patterns simply because of
> singletons, but because all signs point to it being one more
> great-sounding idea that ends up being of the most benefit to
> consultants who use it to generate acronyms & terminology to make
> their presentations look good.
Don't underestimate the value of having a vocabulary. I have found that
it often makes it easier to explain the intention of the design.
You can say that this module uses a particular pattern, or even say things
like "This code/module uses the X pattern, but with a twist". I have
also used patterns to expalain lisp techniques. For example mappers can
be explained as a more general way to archieve the same effect that you
want to have when using the visitor pattern.
In fact, introducing a pattern for describing code at a higher level than
loops and simple data structure for a broader audience is probably the
single most valuable result of the 'pattern movement'.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no
According to Pascal Costanza <········@web.de>:
> In Smalltalk, you really don't have global variables,
Do too. The symbol Smalltalk names a hash-table. The keys in this
hash-table are Smalltalk's global variables. To add a global,
Smalltalk at: #MyAppWorldInst put: MyAppWorld singleton.
This makes the object which is the response to the message "MyAppWorld
singleton" (a singleton! ;-) become the global variable accessible
by the symbol MyAppWorldInst, so one may say,
MyAppWorldInst stateOfTheUnion address.
Although, since one has gone to the trouble to turn class MyAppWorld into a
singleton (about 20 lines of Smalltalk code), adding the global is
superfluous and one may simply say,
MyAppWorld singleton stateOfTheUnion address.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Pascal Costanza <········@web.de>:
> > In Smalltalk, you really don't have global variables,
>
> Do too. The symbol Smalltalk names a hash-table. The keys in this
> hash-table are Smalltalk's global variables. To add a global,
>
> Smalltalk at: #MyAppWorldInst put: MyAppWorld singleton.
>
> This makes the object which is the response to the message "MyAppWorld
> singleton" (a singleton! ;-) become the global variable accessible
> by the symbol MyAppWorldInst, so one may say,
>
> MyAppWorldInst stateOfTheUnion address.
>
> Although, since one has gone to the trouble to turn class MyAppWorld into a
> singleton (about 20 lines of Smalltalk code), adding the global is
> superfluous and one may simply say,
>
> MyAppWorld singleton stateOfTheUnion address.
Or one could have avoided the singleton and written:
Smalltalk at: #stateOfTheUnion
put: CountryStatus newWithName: 'united states of America'.
stateOfTheUnion address.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
According to Pascal Bourguignon <····@mouse-potato.com>:
> ····@netmemetic.com (Ng Pheng Siong) writes:
> > MyAppWorld singleton stateOfTheUnion address.
>
> Or one could have avoided the singleton and written:
>
> Smalltalk at: #stateOfTheUnion
> put: CountryStatus newWithName: 'united states of America'.
>
> stateOfTheUnion address.
Almost, except #stateOfTheUnion in my example was a message selector, not a
class; in Lisp notation, something like,
(address (state-of-the-union (singleton my-app-world)))
And yes, the 'singleton' bit is irrelevant, I mentioned it to muddy the
water since parts of this thread is talking about the singleton pattern.
;-)
Cheers.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Pascal Bourguignon <····@mouse-potato.com>:
> > ····@netmemetic.com (Ng Pheng Siong) writes:
> > > MyAppWorld singleton stateOfTheUnion address.
> >
> > Or one could have avoided the singleton and written:
> >
> > Smalltalk at: #stateOfTheUnion
> > put: CountryStatus newWithName: 'united states of America'.
> >
> > stateOfTheUnion address.
>
> Almost, except #stateOfTheUnion in my example was a message selector, not a
> class; in Lisp notation, something like,
>
> (address (state-of-the-union (singleton my-app-world)))
>
> And yes, the 'singleton' bit is irrelevant, I mentioned it to muddy the
> water since parts of this thread is talking about the singleton pattern.
> ;-)
Hence the latinified perl.
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
>
> Hence the latinified perl.
> http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
This is truly a wonderful page :)
Cheers
--
Marco
According to Pascal Bourguignon <····@mouse-potato.com>:
> http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
Heh, that's a funny one. Probably good for another fancy poster a la the
periodic table.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
Joe Marshall wrote:
> Pascal Costanza <········@web.de> writes:
>
>>The pattern format is a very useful and appropriate way for describing
>>solutions for recurring problems.
>
> Recurring problem: I keep needing to resort to `software patterns'.
>
> Recurring solution: Abandon the language requiring the pattern and
> move to one that either a) has the solution `built in' or b) can
> support having the solution `built in'.
The tell me how to make that "solution" work for the patterns listed in
http://c2.com/cgi/wiki?SimplyUnderstoodCode
See also http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html
and http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Joe Marshall wrote:
>
>> Pascal Costanza <········@web.de> writes:
>>
>>>The pattern format is a very useful and appropriate way for describing
>>>solutions for recurring problems.
>> Recurring problem: I keep needing to resort to `software patterns'.
>> Recurring solution: Abandon the language requiring the pattern and
>> move to one that either a) has the solution `built in' or b) can
>> support having the solution `built in'.
>
> The tell me how to make that "solution" work for the patterns listed
> in http://c2.com/cgi/wiki?SimplyUnderstoodCode
If you tell me the `recurrent problem' that the `pattern' solves.
Pascal Costanza wrote:
>
> Kenny Tilton wrote:
>
>> Yes, I recommend those links. Hilarious stuff:
>
> [...]
>
> What is it exactly that you find hilarious?
What you snipped: "reductio ad absurdum". In fact, we have a pattern:
Pattern name: "Hey! Let's make everything an X!!"
Recurring problem: someone has an idea (logic programming, constraints,
objects) that makes Certain Things easier and immediately wants to use
them for /everything/.
Recurring solution: also a pattern. "Doc, it hurts when I do this."
"Don't do that."
>
> That these examples are too simplistic? The examples were given as a
> response to the claim that the need for patterns should give rise to a
> switch of programming languages, and these examples show that this is
> not always a good way out.
I was off on a tangent, just laughing at the Pattern people falling into
the HeyLetsUseXForEverything pattern.
But I was also reminded of the occasional fist-fight here on cll over
long lists of LET bindings. We had one quite recently, in which Peter
offered two approaches, one an imperative-like sequence of LET*
bindings, one functional.
The issues raised in that one URL I followed could indeed be avoided by
using a functional approach. But getting back OT, I used a functional
approach when I was programming in C, and the imperative-like example
Peter offered reminds us that CL can be programmed in more than one style.
I think we will need more substantive patterns as a test. I did not make
it to the URLs because the first one was so preposterous, and because
Lisp Legend Mr. Gabriel had contributed to it (so I knew it was meant
seriously).
Getting really back OT, the only spec I ever wrote was when a developer
insisted on one for a partial DB replication scheme, aka The Cattle
Drive pattern. I made that up, but I was really surprised the guy needed
a spec. Sh*t, make this other DB look like this one. But once I sat down
to write the spec (OK, the pseudo code) then and only then did a few
gotchas spring to mind. So I was able to avoid a few iterations in which
the developer ran into the gotcha and had to come to me for
clarification of the spec.
So I doubt I could have gotten away with "Handle it with a Cattle
Drive"; the devil is always in the deets.
kenny
I didn't claim that these specific examples
> solve complex problems.
>
> That there seemingly are contradictions in the descriptions? Patterns
> usually describe trade offs between different alternatives. Good
> patterns not only describe when they can be used, but also when they
> should not be used and why.
>
> What else?
>
>
> Pascal
>
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
> Pascal Costanza wrote:
>
>> What is it exactly that you find hilarious?
>
> What you snipped: "reductio ad absurdum". In fact, we have a pattern:
>
> Pattern name: "Hey! Let's make everything an X!!"
>
> Recurring problem: someone has an idea (logic programming, constraints,
> objects) that makes Certain Things easier and immediately wants to use
> them for /everything/.
>
> Recurring solution: also a pattern. "Doc, it hurts when I do this."
> "Don't do that."
But "let's make everything an X" is not what the mentioned patterns say.
> But I was also reminded of the occasional fist-fight here on cll over
> long lists of LET bindings. We had one quite recently, in which Peter
> offered two approaches, one an imperative-like sequence of LET*
> bindings, one functional.
Good example. There are no simple rules here. Using LET/LET* for each
intermediate result doesn't work, but inlining everything into one big
expression is sometimes also too complex. Therefore, identify the
important intermediate results and give them descriptive names that work
well as documentation at the same time. This has the important
ingredients: we have contradicting forces (everything in LET form vs.
everything inside the main form), and a resolution of those forces.
> I think we will need more substantive patterns as a test. I did not make
> it to the URLs because the first one was so preposterous, and because
> Lisp Legend Mr. Gabriel had contributed to it (so I knew it was meant
> seriously).
He didn't contribute to them, he has written them. Yes, they are meant
seriously - mostly as counter examples to the patterns in the Design
Patterns book.
A book I like a lot is "Object-Oriented Reengineering Patterns" by
Demeyer, Ducasse and Nierstrasz. It offers a very good pattern language
for understanding other people's source code. Another pattern language
that has already helped me at some occasions is "A Pattern Language for
Course Development in Computer Science" by Joseph Bergin - see
http://csis.pace.edu/~bergin/patterns/coursepatternlanguage.html
Patterns are not about a specific kind of content - that's a very wrong
impression one gets from the Design Patterns book. The patterns in that
book are mostly crap and can mostly easily be expressed in a few macros
in a mature programming language. But the latter fact is totally besides
the point. The idea of patterns is that they give you a way to describe
solutions to recurring problems in an abstract but nevertheless detailed
way. As soon as you understand the forces in a pattern and why they make
it hard to get to a workable solution you have understood the essence of
a problem. Understanding the various alternatives for resolving such
forces and being able to use names for them enables you to be more
effective in attacking problems.
It's not a silver bullet. It requires work and time. But it makes
communication more effective. A good way to understand patterns better
is to actually write them yourself.
That's probably similar to programming languages - you understand
language design better when you have actually designed them yourself.
Including, for example, Cells. I guess you have a much better
understanding by now what it takes to write a good language, and I also
guess that it would have been worthwhile if you had known a few patterns
for designing a language before. It's very likely that you aready knew a
few subconsciously by having studied other languages. Patterns are
"only" a way to make such knowledge explicit.
> Getting really back OT, the only spec I ever wrote was when a developer
> insisted on one for a partial DB replication scheme, aka The Cattle
> Drive pattern. I made that up, but I was really surprised the guy needed
> a spec. Sh*t, make this other DB look like this one. But once I sat down
> to write the spec (OK, the pseudo code) then and only then did a few
> gotchas spring to mind. So I was able to avoid a few iterations in which
> the developer ran into the gotcha and had to come to me for
> clarification of the spec.
>
> So I doubt I could have gotten away with "Handle it with a Cattle
> Drive"; the devil is always in the deets.
Of course, the assumption is that people you communicate with also know
the details of the patterns you are talking about. A spec for a concrete
problem is not a pattern. It's unlikely that you had been the first on
earth to solve such a problem. It would have probably saved you some
time if you could have given that developer a book in which a solution
for a similar problem was already described. That's the idea.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Joe Marshall
Subject: Re: Patterns, was Re: LISP is dead now ! ! !
Date:
Message-ID: <fz4ibug1.fsf@ccs.neu.edu>
Pascal Costanza <········@web.de> writes:
> There exist architectural
> patterns, organizational patterns, pedagogical patterns, process
> patterns etc. For example, "Extreme Programming" can be regarded as a
> collection of patterns. Say, "Pair Programming" is a pattern that
> resolves the forces that code reviews are good but a culture of
> solitary programming rarely leads to regular code reviews. Pair
> Programming leads to code reviews being done all the time. etc. pp. -
> see, no "technology" in a strict sense involved here.
>
> The essential idea of patterns is just that you have a way to describe
> a resolution of conflicting forces.
You are abandoning the original definition of `pattern' (as per the
GOF) and redefining it to mean `solution'.
Solutions are good things (who would disagree?), but `software
patterns' (e.g. The Visitor Pattern, The Singleton Pattern, etc.) are
suspect.
Joe Marshall wrote:
> Pascal Costanza <········@web.de> writes:
>
>>There exist architectural
>>patterns, organizational patterns, pedagogical patterns, process
>>patterns etc. For example, "Extreme Programming" can be regarded as a
>>collection of patterns. Say, "Pair Programming" is a pattern that
>>resolves the forces that code reviews are good but a culture of
>>solitary programming rarely leads to regular code reviews. Pair
>>Programming leads to code reviews being done all the time. etc. pp. -
>>see, no "technology" in a strict sense involved here.
>>
>>The essential idea of patterns is just that you have a way to describe
>>a resolution of conflicting forces.
>
> You are abandoning the original definition of `pattern' (as per the
> GOF) and redefining it to mean `solution'.
No, I am not. See http://hillside.net/patterns/definition.html - and I
also don't think that Section 1.1 in the GoF book goes beyond those ideas.
> Solutions are good things (who would disagree?), but `software
> patterns' (e.g. The Visitor Pattern, The Singleton Pattern, etc.) are
> suspect.
Sure, but the more important is it to distinguish between what the
pattern people got right and what they got wrong. There are people who
abandon Lisp because of the failure of AI, but they are confusing the
different levels of enabling concepts and taking wrong paths. Something
similar is going on in the case of patterns. The pattern form is an
effective way of reasoning about problems and their solutions - it's not
just the solutions - and that form has a similar "eternal" quality like
the notion of metacircularity. (Think "Greenspun's Tenth".)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
·········@random-state.net wrote:
> Pascal Costanza <········@web.de> wrote:
>
>
>>What is it exactly that you find hilarious?
>
>
> That style has become a pattern. It seems to me that there is a distinct
> difference between patterns that describe a code component, and patterns
> that describe coding style -- and I was not aware that the latter ones
> were considered "real patterns" by the "pattern movement". Live and learn,
> etc.
Given that the pattern movement originated as a means to enable
communities to create buildings that were harmonious with each other and
in themselves, it's perhaps stranger that people would consider code
components patterns. To a large extent, patterns _are_ style. Components
are, well, components. Even if you assemble all the components for a
house, even if some of the components are large prefabricated units,
then you can assemble them in different ways. Some of those ways 'fit',
have the 'quality without a name'. Patterns attempt to capture that
quality. If you can code it, it's probably a 'programming idiom'.
Pete
Brian Raab schrieb:
> Buy a good C++ compiler and write programs in a MODERN language,
> forget Lisp, it's dead.
Maybe Kaiser Stefan Raab said this? ;-)
Andr�
--