Lisp and software architecture
in [Lisp]
|
Prev: cosx - sinx + 3x2
Next: the Modernization of Emacs
From: Rainer Joswig on 8 Mar 2006 03:24 In article <m2d5gxpndo.fsf(a)gigamonkeys.com>, Peter Seibel <peter(a)gigamonkeys.com> wrote: > Next month I'm goin to be giving a talk[1] about the effect of > programming language on software architecture. I'm thinking about what > the heck I'm going to say and how to turn it into an oppotunity to > brag on Lisp. So if you have any good war stories about how using Lisp > (or any other language for that matter) had an affect on the > architecture of the system you were working on, I'd love to hear > them. > > -Peter > > [1] April 26th at the Software Architecture and Modeling SIG of > SDForum in Palo Alto I think there are lots of architecture- and Lisp-related topics: - multiparadigm architectures (rules + objects + constraints + ...) - very object-oriented architectures - layered language architectures (objects on the bottom, then functions, then macros) - architectures which use exotic (non-mainstream) paradigms - open architectures (-> Xerox, MIT Lispm) - Meta-level architectures - Architecture development (RAD, Prototypes, ...) - Evolvable architectures - 'Knowledge-based' systems and their architectures and probably more... For all of the above one should be able to find papers/examples. -- http://lispm.dyndns.org/
From: Ken Tilton on 8 Mar 2006 07:13 > Peter Seibel wrote: > >> Next month I'm goin to be giving a talk[1] about the effect of >> programming language on software architecture. I'm thinking about what >> the heck I'm going to say and how to turn it into an oppotunity to >> brag on Lisp. So if you have any good war stories about how using Lisp >> (or any other language for that matter) had an affect on the >> architecture of the system you were working on, I'd love to hear >> them. Too bad you gave up on Cells at the first backtrace. Cells simply fell out of an attack on an application problem, turned into a paradigm, took over the whole application. Would never have happened without first-class functions, closures, macros, CLOS, untyped variables... kt
From: Wade Humeniuk on 8 Mar 2006 08:21 Sacha wrote: > I'm a lisp newbie, freelance programmer working for telephone companies. > There is one thing i made and remade in about every language i worked with : > the telephony pricelist. > Though this looks like a simple task, the thing can be quite involved as my > customers need all the configuration options you could imagine and a lot > more too. It kind of became my benchmark implementation for language > testing. > They say lisp is different, so i'm building yet another pricelist using > lisp. > To say the truth, it looks like it'll eventually be quite the same thing as > my other implementations. Maybe am i too much of a newbie still, but hey > they say another thing : you need to build programs in order to learn =P > How about creating a Pricelist expert language instead? Then your customers can specify/create/maintain their own "pricelists". Start with one that has a Lisp syntax and then go from there. Wade
From: Simon Brooke on 8 Mar 2006 08:57 in message <m2d5gxpndo.fsf(a)gigamonkeys.com>, Peter Seibel ('peter(a)gigamonkeys.com') wrote: > Next month I'm goin to be giving a talk[1] about the effect of > programming language on software architecture. I'm thinking about what > the heck I'm going to say and how to turn it into an oppotunity to > brag on Lisp. So if you have any good war stories about how using Lisp > (or any other language for that matter) had an affect on the > architecture of the system you were working on, I'd love to hear > them. If you're using any Algol family language, up to and including Java/C#/C++ etc, or FORTRAN and derivatives, then one of the issues is data object size. Doing the equivalent of (* pi (factorial 1000)) in most languages requires not only a lot of special libraries but also a lot of special syntax. This leads you to think about your problem space in two's complement 32 or 64 bit integers, and in 32 or 64 bit IEEE 754 encoded reals. That in turn leads you to accept rounding errors as inevitable, even if they're not. You don't expect the equivalent of (+ 22/7 1/7) to return exactly 23/7. You expect rounding error. You say 'it's inevitable'; you say 'it doesn't matter'. If you use any statically typed language - Algol family, Fortran family, any of them - you have to make early commitments to the type of an object that you don't yet know much about. In Java (and its derivatives) or C++, for example, you can't at all easily move an object about in the class hierarchy; the class it was born in, it dies in. There's no social mobility for objects. All these things (and many others) limit the way you think about a problem space. They limit what you can build because they limit what you can think of. If this post has been any use to you you might want to look at my currently developing essay 'Post Scarcity Software', which is here <URL:http://www.jasmine.org.uk:80/dogfood/story/article_42.html> -- simon(a)jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/ "The result is a language that... not even its mother could love. Like the camel, Common Lisp is a horse designed by committee. Camels do have their uses." ;; Scott Fahlman, 7 March 1995
From: Ken Tilton on 8 Mar 2006 09:15
Sacha wrote: > "Peter Seibel" <peter(a)gigamonkeys.com> wrote in message > news:m2d5gxpndo.fsf(a)gigamonkeys.com... > >>Next month I'm goin to be giving a talk[1] about the effect of >>programming language on software architecture. <snip> > > > Shouldn't the language be considered as an implementation detail ? > It is my beleif that the architecture is on a different level. > > Now this might not hold true for dynamic languages. Until now I only used > c++, c# and delphi for large projects, and these are all alike after all. So > I migh be completely wrong here. > > On the other hand, it seems to me that my father was doing OO programming > using bare bone pointers back in the days. > That's a good example of a good concept crossing the language frontiers. > > I'm a lisp newbie, freelance programmer working for telephone companies. > There is one thing i made and remade in about every language i worked with : > the telephony pricelist. > Though this looks like a simple task, the thing can be quite involved as my > customers need all the configuration options you could imagine and a lot > more too. It kind of became my benchmark implementation for language > testing. > They say lisp is different, so i'm building yet another pricelist using > lisp. > To say the truth, it looks like it'll eventually be quite the same thing as > my other implementations. Not after you post it to c.l.l. :) > Maybe am i too much of a newbie still,... No, that is not the problem. Many newbies (but not you, it seems) go too far in straining to do things The Lisp Way. This is good, this is how one learns something new, breaks the mold: throw oneself into it with gusto, try to be functional, try to leverage CLOS and macros, yada yada. > but hey > they say another thing : you need to build programs in order to learn =P Building programs will not help you; Lisp is a multi-paradigm language, so you can write code as if it were C. Which it seems you are. Having solved the problem several times already, you are just writing the same code in Lisp. What do you think it is going to look like? Most newbies in your situation are sharp enough to say, "Hey, my Lisp code looks just like my C code, what am I doing wrong?" Your grand conclusion is that Lisp is no different than C. Hmmmmm.... ken |