Lisp and software architecture
in [Lisp]
|
Prev: cosx - sinx + 3x2
Next: the Modernization of Emacs
From: Paolo Amoroso on 8 Mar 2006 14:38 William Bland <doctorbill.news(a)gmail.com> writes: > Agreed. I have often surprised people at work by showing them how some of > the patterns that are needed in Java are actually "built in" to Lisp (or > at least much less hassle to implement there). This does seem to to get > people interested. I read the GoF patterns book a while back, but I seem to remember that they explicitly state something like this, and mention Lisp and Smalltalk as examples of languages requiring less or no patterns. Paolo -- Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film The Common Lisp Directory: http://www.cl-user.net
From: Ken on 8 Mar 2006 15:09 Matthew D Swank wrote: > On Wed, 08 Mar 2006 12:36:03 -0500, Ken Tilton wrote: > > >>ps. Thanks for the fat pitch. :) > > > When is "Cells III, Cells in 3D" due to be committed? Cells3 was done (enough to let me drive Tk froms Cells), but then I decided it should go a little further, and am meditating on "further". Unless someone reports a problem Cells3 would solve I will just let it gestate. I do not want to have to jump to Cells4 in three weeks and put tfb and Cells-Gtk thru another round of testing. Cells in 3D is unknown to me, but could be Cello. I love OpenGL, but I have a portable retail app to get out and Tk solves a /lot/ of nitty-gritty stuff Cello has not even dreamed of, natively to boot, so I am hoping I can get by with Celtk (+ Cells Tk). ken
From: Patrick May on 8 Mar 2006 16:10 "Tolstoy" <keith.irwin(a)gmail.com> writes: > So, seems like the first thing you should do is define Software > Architecture. Are you talking about how to arrange your code to > solve the problem? Or are you talking about how to solve problems, > one part of which is the actual software? Neither? Both? In addition to the points you've raised, one of the most important distinctions between architecture and design is that a software architecture must address non-functional requirements (performance, resiliency, scalability, extensibility, and all the rest of the "ilities"). Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Jini, CORBA, UML)
From: Pascal Bourguignon on 9 Mar 2006 01:05 Paolo Amoroso <amoroso(a)mclink.it> writes: > I read the GoF patterns book a while back, but I seem to remember that > they explicitly state something like this, and mention Lisp and > Smalltalk as examples of languages requiring less or no patterns. It's not that Lisp requires less patterns, it's that every macro you write in lisp IS a pattern! (Well, but perhaps the simpliest purely syntactic sugar ones). Also, UML case tools, particularly those that implement rules for automatic model transformations and which generate automatically the resulting C++ sources, are not needed either when you write lisp, once again because you have macros to implement these model transformation rules, and to generate the final Lisp code. -- __Pascal Bourguignon__ http://www.informatimago.com/ COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons, protons, etc.) comprising this product are exactly the same in every measurable respect as those used in the products of other manufacturers, and no claim to the contrary may legitimately be expressed or implied.
From: Holger Schauer on 10 Mar 2006 08:28
On 4572 September 1993, Pascal Bourguignon wrote: > Paolo Amoroso <amoroso(a)mclink.it> writes: >> I read the GoF patterns book a while back, but I seem to remember that >> they explicitly state something like this, and mention Lisp and >> Smalltalk as examples of languages requiring less or no patterns. I'm reading it right now, and it's "less". They even say quite concretely which patterns they included in the book which are somewhat build-in in Lisp/Smalltalk. > It's not that Lisp requires less patterns, it's that every macro you > write in lisp IS a pattern! I don't think that the pattern you have in mind is the kind of patterns the GoF book talks about. Many aspects of what I've read so far deal more with how to structure your data and functionality so that the resulting code becomes quite flexible and maintainable ("encapsulate the concept that varies" seems to be the mantra of the book). I take that to be quite independent of the language you actually use. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Ihre Kontinentalfestplatte ist fragmentiert. M?chten Sie den Assistenten zur Driftbeschleunigung starten?" -- Andreas Meier in de.alt.sysadmin.recovery |