Lisp and software architecture
in [Lisp]
|
Prev: cosx - sinx + 3x2
Next: the Modernization of Emacs
From: billclem on 8 Mar 2006 10:47 > Next month I'm goin to be giving a talk[1] about the effect of > programming language on software architecture. <snip> > [1] April 26th at the Software Architecture and Modeling SIG of > SDForum in Palo Alto You might want to consider using a Design Patterns based approach to showing how the choice of a programming language can affect how you look at a problem from an architectural and modeling standpoint. This is something that the SIG will relate to easily. Peter Norvig did this very effectively in his "Design Patterns in Dynamic Programming" presentation (http://norvig.com/design-patterns/). Obviously, you won't want to cover the same ground as Peter did; however, you can mold some of those ideas into your talk. Richard Gabriel also has a lot of good material for this type of approach in his _Patterns of Software_ book (http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf). In fact, you might want to look at some of his OOPSLA presentations as well. This approach could also lead into a discussion about how the selection of a programming language with a high level of abstraction capabilities changes the requirements for the types of modeling tools that you might need/want to use. For example, many Java programmers use UML modeling tools but very few Lisp programmers do. Another good souce of material for the presentation might be some DSL examples (e.g. - Rainer Joswig's movie - http://bc.tech.coop/blog/050711.html). This would reinforce the idea of how the choice of programming language affects the types of patterns that the programmer "sees" or uses. Also using DSL's, you might want to weave in some psychological material about how the choice of a programming language can subconsciously influence your architectural design choices (e.g. - things that are "really hard" to do in one programming language but easy to do in another programming language result in different architectural approaches being taken in the design of the solution). -- Bill Clementson
From: Peter Seibel on 8 Mar 2006 11:22 Ken Tilton <kentilton(a)gmail.com> writes: >> 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... Hey, that's not fair. I didn't give up because I couldn't get it to run--I gave up long before that, when I couldn't find anything that explained what it was and why I should care. ;-) -Peter -- Peter Seibel * peter(a)gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Sacha on 8 Mar 2006 12:18 "Wade Humeniuk" <whumeniu+anti+spam(a)telus.net> wrote in message news:LTAPf.22801$Ui.8488(a)edtnps84... > 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 Would you mean something like : lay the data, throw lots of parenthesis around it, back it up with some code to make it work, then refactor until i get a usefull, higher level language ? Or maybe lay the finaly language down then wrap the code around it ? There was this very nice and quite enlightening DSL video : http://bc.tech.coop/blog/050711.html That sure sounds neat, i'll give it a try. Sacha
From: Sacha on 8 Mar 2006 12:35 >> <snip> >>, 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. > > 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.... > I knew this post would be controversial.. > "Hey, my Lisp code looks just like my C code, what am I doing wrong?" My post was sort of admiting a failure. Maybe should i tackle something different, get out of the track, then go back to the price list problem when i'll be able to make it more idiomatic. Wade Humeniuk suggested going the DSL path , so i'll give it a try first. Sacha
From: Ken Tilton on 8 Mar 2006 12:36
Peter Seibel wrote: > Ken Tilton <kentilton(a)gmail.com> writes: > > >>>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... > > > Hey, that's not fair. I didn't give up because I couldn't get it to > run--I gave up long before that, when I couldn't find anything that > explained what it was and why I should care. ;-) Oh, lord, that is easy. Go to the ActiveState site, they named the whole frickin company after Cells functionality. Then look at what the Tk crowd calls "actions"-- that is Tk with its little bit of hardcoded "active state" trying to let the user hardcode some of what Cells does automatically. You might also check the Adobe site, look for a white paper on, I forget, Eve? Same thing, and they apparently are standardizing on that for future software development. I also find this tool to be a helpful, you might want to give it a try for things like this: http://www.google.com/ Try: http://www.tilton-technology.com/cells-overview.pdf Look for: "1.2 The big picture Cells support a declarative paradigm in which the motivating force behind an application?s overall behavior is dataflow through a dependency graph maintained automatically by the system. The benefits are several. ? Eliminates the class of bug in which program state is internally inconsistent. ? A corollary benefit: eliminates the housekeeping burden of keeping consistent the state dependency graph implicit in any application. ? Makes manifest the state dependency graph implicit in any application. Actual runtime dependencies can be graphed. ? Program semantics are fully encapsulated by the declarative model; the rule for a cell defines it completely. ? Cells let us tailor instances with rules, not just literals, making objects more reusable. For example, some GUI schemes allow widgets to specify their dimensions with options such as :sticky-left or :fixed or :elastic-right. With cells you can write any algorithm you like to decide a widget?s geometry. Furthermore, by arranging instances in a navigable namespace, those algorithms can draw on arbitrary application state. ? Divides and conquers application complexity. No cell in even the most complex spreadsheet touches more than a handful of cells, usually just one or two. The complex solution emerges from multiple small but high-quality solutions to small problems. Our experience has been the same with Cells in application development." Of course, if you have not done much application programming that will not make any sense to you. Try reading Fred Brooks's "No Silver Bullet", in which he explains why software can never be easier to develop than it was in 1986. In part: "Digital computers are themselves more complex than most things people build, they have very large numbers of states....Software systems have orders of magnitude more states than computers do....In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly." You never looked at Cells, so i will tell you: Cells manage state. Again, if you are just a code monkey and are never given responsibility for anything more than a subroutine here and there, I understand why that still makes no sense to you. Brooks continued: "Many of the classical problems of developing software products derive from this essential complexity." This is why anyone can write a ten line program, why you have to learn how to program to pull off a hundred line program, why most thousand line programs are horrid, and why most 100kloc projects fail. Cells fixes that. Well, even with your father pitching it, it took you twenty years to become a Lispnik: http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp Should we look for a Road to Cells Switch Date of 2028? :) ken ps. Thanks for the fat pitch. :) |