Kent M. Pitman's Second Wind

Kent M. Pitman has already given you his first 11 answers to the questions you asked him about Lisp, Scheme, the creation of programming standards, and much more -- below are his answers to another eight (starting with answer #12). Thanks again, Kent.

12) Good texts for learning Scheme?
by drenehtsral

I have recently been working on learning Scheme in my spare time, with the eventual goal of writing a scheme based scripting system to run the guts of a massive adventure game/graphical mud sort of system, everything from environment simulation (predator/prey cycles, etc...) to 3d models (i.e. models will be geometry glued together by scripts so you could have trees that by a random seed and a growth level variable have grown over time and are unique to provide interresting landscape features). Scheme is appealing because it's simple, powerful, and adapts well to the idea of a threaded interpreter.

To further my goal of learning Scheme inside and out, I've been reading "The Little Schemer," as well as "Structure and Interpretation of Computer Programs." Do you have any other recommendations for good Scheme programming texts?

Kent M. Pitman: You can get a list of textbooks from Schemers website. If you can articulate a particular need or preference that you think should help narrow down the many available choices, I'd suggest posting a more specific inquiry to the comp.lang.scheme newsgroup.

13) Overlooked practical aspects of Lisp
by hding

Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.

Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.

KMP: Well, people program with tools that are familiar to them. Unless Common Lisp is someone's first language, it'd be easy for them to overlook the things it contains that are not like the things they're familiar with. There's a certain irony here because often the reason people will leave a language for another language is that they've reached the limits of what they can do with the first language and they need more power. So you'd expect that they'd aggressively look for features of the new language that were different than the things they've used before. And probably some do. But you're right that others cling to the safety and familiarity of the operators they could just as well have found in the old language they left behind, and so in the process they miss out on what the language can offer them.

Fortunately, unwind-protect is finally (pardon the pun) present in Java. And some hints of the Common Lisp condition system made it into Java as well. So probably people who come to Common Lisp from Java will be inclined to seek out those capabilities. But there's a lot of other stuff there and I hope new users will indulge their curiosity and take the time to explore.

As to what we should have in the language, the main omission of note is some sort of system definition tool (the in-Lisp analog of make). It was a shame that we did a feature-freeze on ANSI Common Lisp in 1988 but didn't get the standard out until 1994, and the suggestion of including such a tool didn't come until the after-freeze period. All vendors offer such a facility, but programs would be more portable if there were a uniform solution.

There are also quite a number of things about Common Lisp that are available in the same or similar forms in nearly all implementations. Multi-tasking, sockets, database access, external function call, windowing, and so on. It wouldn't be bad to have included any of these, but the fact is that they weren't ready for standarization in 1988. At this point, though, I think other mechanisms than standards are the right way to proceed.

The Lisp community used to expect the delivery mechanism for new functionality to be a new language spec. But that requires working through consensus standards bodies. The problem is that, by their nature, standards bodies are synchronization mechanisms. The problem with synchronization mechanisms in a massively parallel world is that they slow things down. The world is not going to wait for us to slow down, so I think we need to evolve mechanisms that will keep up better with a degree of pace that is externally dictated.

I think this is an area where Lisp as a community has been slow to respond. There need to be community mechanisms for sharing the many great commercial and private packages people have been creating in Lisp, so that we can properly reap the cross-product benefits of our community's productivity. I see evidence that this is changing. The Common Lisp Open Code Collection (CLOCC) is one such mechanism that addresses open source code. I'd like to see similar mechanisms arise for the exchange of proprietary products as well.

As to my posts on the comp.lang.lisp newsgroup, thank you. I'm glad you enjoy them. Frankly, I always consider it a victory to hear I haven't bored everyone to death. In background I've been working on putting together several books on Lisp, but one never quite knows if one will finish such things. I regard comp.lang.lisp as a kind of insurance policy, assuring that at least some piece of what I have seen and done in my career gets transferred from individual memory to global group memory.

I think preserving individual experiences for history is quite important. In the future, this will happen naturally due to logs kept by online collaboration tools. But I'm especially worried about the records of what happened between about 1960 (the birth of programming languages) and 1994 (the birth of the web). Most of everything in that time range is recorded on paper and will eventually be lost. Looking back from the future, I expect it to be as confusing to figure out how the information society was born as it is to look back in a telescope to see the birth of the Universe. You'll get very close, but then you'll get to a point where you can see nothing. The informational big bang. I've been working on webbing all of my old hardcopy papers, and I hope others of that era will commit to doing the same.

14) Lisp - Scheme - ML
by Tom7

I know a lot of big academic (erstwhile) lisp shops, such as CMU, have transitioned away from lisp to ML [standardml.org] and relatives [inria.fr]. Some of the reasons we might give are:

• Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.
• Much more efficient (http://www.bagley.org/~doug/shootout/craps.shtml), partly due to compilation strategies using types
• Increased modularity and abstraction
• Pattern matching, (subjectively) more natural syntax

In fact, I'm one of those people. I've been scoffed at by lisp fans, but most had never used ML. But I have an open mind, so, in the face of more "modern" languages, what advantages do lisp and scheme offer? Do you think that these advantages are fundamentally impossible to achieve in a typed setting?

KMP: First, I assume by "typed" you mean "statically typed." I think of Lisp as "dynamically typed." I think of most machine languages as "untyped." I've heard statically typed languages sometimes called strongly typed, and I sometimes use this terminology myself out of habit, but I've grown to dislike it because it seems to me that the issue of strength ought to refer to whether you check types, not when you do. The terms "static" and "dynamic" seem to me to better get to the heart of the matter.

To quote Abraham Lincoln, admittedly somewhat out of context, "People who like this sort of thing will find this the sort of thing they like." So to somewhat flippantly re-interpret Lincoln's remarks in a modern context, applying perhaps just a bit of obligatory political spin to the result: The fact that functional languages appeal to people who like functional languages is not a proof that functional languages are of general purpose appeal.

I think the real reason that CMU (or any university with a grant-based funding model) changed its direction is good sources of funding in research depend on saying you're doing something "new and different." Such a shift doesn't imply that the thing left behind wasn't "tried and true," but only that "tried and true" is not what gets research dollars. Research must constantly stir the mix, but that doesn't imply obsolescence to what came before. So don't read too much into that.

Answering each of your points in detail might require a whole article, but I'll touch on each in brief:

• Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc. Much more efficient partly due to compilation strategies using types.

  Actually, it's funny that you both mention the CMU project and then make this comment. Before moving away from Common Lisp, the CMU crowd was successful in demonstrating to the Lisp community's satisfaction that there were enormous opportunities offered by the Common Lisp language design in terms of type inferencing that still today go untapped by implementations. This is really a market issue, not a language design issue. The fact is that although other languages do a lot more type inferencing, vendors are not getting huge numbers of bug reports saying that better type inferencing is what stands between programmers and the commercial success of their product. Over time, I think you'll see more and more interesting type analysis done, but such work is always balanced against other needs of users, such as CORBA, COM, RMI, and web interfaces, for example, such as UI toolkits and debugging options. When I observe, as I often do, that languages are political parties, this is what I mean. They are each responsive not to the needs of the world, but to the needs of their constituencies. And the Lisp constituency, while it is not oblivious to the value of type inferencing, does not see that issue as its number one priority.

• Increased modularity and abstraction.

  This is quite a multidimensional space. I think Lisp provides great opportunities for modularity and abstraction that other languages do not. And yet, there are sometimes things I can't abstract as well as I wish. An example of a minor omission: Common Lisp's CLOS doesn't do protocol abstraction as well as Zetalisp's New Flavors; among other things, one can't declare that certain unimplemented methods are required. But with the use of the macro system and the Meta-Object Protocol (MOP), one can add this kind of thing. Further, the package system is missing certain kinds of inheritance capabilities I've often wished for, but I recently sat down and did the work of writing my own versions of defpackage for my own use, adding the capabilities I wanted in a way that my own tools can use, and I had no difficulty. For the most part, I've found the limitations of Common Lisp's abstraction capabilites to be incidental, and not deep, and I've found its syntactic reorganization capabilities more than capable of making up for it.

• Pattern matching.

  I think you're right that Lisp doesn't do pattern matching. Whether or not that's a good or bad thing is subjective. I think there are people who like pattern matching and people who don't. In fairness to Lisp, though, on the few occasions in my career where I've felt a strong need for pattern matching, I've been able to implement it easily. And, importantly, Lisp's syntactic adaptability has allowed me to make my personal implementation look as natural in the programs I write as if it were natively provided by the language; most other languages don't give me the syntactic control to be able to add new functionality in a way that feels appropriate to the language. So personally, I don't find this a strong negative; rather, I see it as an opportunity for you to create a layered library that supports the needs of yourself and others like you.

• (Subjectively) more natural syntax.

  I don't think you can make the case that much of any language has "natural" syntax. COBOL and HyperTalk gave this the fairest shot and there's a big difference even between them and any natural language. I personally find Lisp syntax remarkably natural in that it focuses on symbols that you could say out loud, marking them minimally to indicate grouping. Other languages contain lots of special-purpose markers like commas, semicolons, asterisks, and braces/brackets/parens that are used in quite nitpicky ways. All this to say that you're right on this one: it's subjective. And as such, I hope I can fairly dismiss this as an even draw.

15) Lisp in Mathematics Programming
by An Anonymous Coward

Gregory Chaitin has a book called "The Limits of Mathematics." In it he claims that mathematicians should love Lisp because Lisp is basically set theory, and all mathematicians love set theory. I wholeheartedly agree with this, one only needs to look at Chaitin's Lisp programs to realize how quickly and succinctly one can arrive at astonishing incompleteness results in mathematics. So we know Lisp is great for stuff like this, really researching a mathematical subject. Do you see Lisp continuing in this direction, showing and discovering theorems, or will it move into industry? Or has it moved into industry, and we just don't know it? Do the likes of NASA and JPL use Lisp and Scheme religiously? I would bet so.

KMP: Lisp may have started out as a way of addressing abstract topics like math (logic, calculus, prime numbers, etc.) and artificial intelligence, but it long ago made the transition to commercial applications. Both Scheme and Common Lisp have been and continue to be used in real-world applications that might surprise you. These include (but are certainly not limited to) applications in airline scheduling, commercial database manipulation, computer operating systems, bioengineering, web services, document format translation, and, yes, even space exploration. Franz, Inc. has created quite a nice page of Lisp success stories that I think expand on this much better than I could in the space I've allowed myself to answer this question. And speaking of NASA/JPL, they did a comparative study of Lisp vs Java and C++ that some might find interesting.

16) Scheme in CS
by An Anonymous Coward

It seems many of the more popular CS programs in the world use Scheme as a teaching language. A lot of times, students complain about this, saying they'd prefer to learn about C or another language that is considered "apt for industry." I used to be like this too, but have now discovered the error of my thinking. How have you convinced others that while the latest programs might not be written in Scheme, that it is worth a student's time to learn Scheme. Many seem stuck to the point that if they won't use it outside of school, they shouldn't learn it. How can we convince them otherwise, to become scholarly citizens instead of drones?

KMP: I think the thing to explain to a student is that the world is ever changing and that one cannot put ones eggs all in one basket. Furthermore, modern environments are often quite heterogeneous, with different languages and systems being used together cooperatively. Especially for a CS student, who often has the luxury of time that a person in the job world does not, I think it's worth taking time to learn as many different languages as possible. This not only exposes the students to alternate ways of thinking, but it also prepares the student to quickly change modes of thought or languages of expression later. Once on the job, one often can't afford the ramp-up time to learn a new language at the point it becomes necessary to use. Better to already know it and just have to "brush up".

One is much more likely to consider alternative approaches if one has a sense of what is involved in them; it's very easy to fear the unknown, even when the unknown might be of great help. So get to know as many things as you can while you can. Common Lisp and Scheme, which I regard as two very different languages, by the way, should definitely be among the things every student studies. But they should not be the only things the person studies. Like it or not, there is a lot the professional programmer needs to know to be really successful not just tomorrow, but for a lifetime.

As Oliver Wendell Holmes is often quoted as saying, "A mind stretched to a new idea never returns to its original dimensions." In order to stretch a student's mind, I recommend they make a list of "kinds of languages" and then learn as many different kinds as they can. Here are some that come to mind, though I'm sure others with different experience than me might reasonably contribute still others.

• A block-structured language, such as Algol or Pascal or Scheme.
• A line-oriented language, such as Fortran or BASIC.
• A rule-based logic language, such as Prolog or EMYCIN.
• An Englishy language such as HyperTalk or Cobol.
• A "stack" language such as PostScript.
• A "line noise" language (heavy emphasis on one-letter operators) like APL or Teco.
• A dynamic object-oriented language, such as Common Lisp or Smalltalk .
• A strongly-typed, statically analyzed language such as ML or Haskell.
• A dynamically-typed functional programming language, such as Scheme.
• A string or macro processing language, such as Perl or m4 or TeX or Teco.
• A database access language, such as SQL.
• An abstract high-level, assembly language, such as Java.
• A concrete high-level, assembly language, such as C.
• A low-level, traditional assembly language.
• A scripting language, such as Javascript.
• An interface-definition language such as Visual Basic, HyperTalk, or Javascript.
• A document-structuring language such as XSL or TeX.
• A language with a modern error system, such as Common Lisp or Dylan.
• A reflective/introspective language such as Common Lisp or Java.
• A symbolic programming language, such as Common Lisp or Scheme.
• A security-oriented language, such as Java or MOO.
• A language where both programs and data are fully persistent, such as MOO or HyperTalk.

I'm confident that if people make a sincere effort to learn each of these kinds of languages on their own terms, the Lisp community will get its share of converts. But further, I would hope that the people who come to the Lisp community bring with them the ideas of other communities so that we can incorporate, rather than hide from, the good ideas that we need in order to continually be moving forward.

17) A question for Kent
by MarkusQ

Do you have a maclisp manual I could borrow?

KMP:For those not familiar with Maclisp, it's a defunct dialect of Lisp that predated and strongly influenced the design of Common Lisp.

I've been working on webbing The Revised Maclisp Manual, which I had published on paper back in the early 1980's. It's not quite ready to go out yet, but should finally be ready sometime in the not terribly distant future. Probably a month or two. Watch the site maclisp.info for more information.

18) Open Implementations
by Martin Pomije

What is your opinion of the idea of Open Implementations from Gregor Kiczales? Do you think that his idea could help Lisp be more widely used?

You can see him giving a lecture about this idea here. [microsoft.com] The video is only available in Windows Media format on this site.

KMP: I hadn't seen Gregor Kiczales's talk on Open Implementations, so I enjoyed watching it. Thanks for the pointer!

The talk made me think back to various related ideas I've seen batted around for a long time, the earliest of which that I can recall is a short paper on something called "Capsules" (an object system where classes were allowed to have multiple implementations) by Richard Zippel back in the late 1970s or early 1980s at MIT. Often, especially in a university environment, people will make up such a concept, bat it around for a bit, and then go on to something else. There are some very interesting ideas there and I'm glad to see that they're being pursued seriously, especially by someone as thoughtful and talented as I know Gregor to be.

As a formalized area of study, this topic of "aspect-oriented programming" is new to me. It reuses some old ideas in new ways, and introduces some new ones along with it. I'm only just barely becoming conversant in the terminology, so I can't really speak to it from a theoretical point of view. But it looks promising. And from a practical point of view, I can note that I'm getting daily on-the-job training in it through my consulting relationship with The Software Smith. They're using Lisp as a vehicle to apply the principles of aspect-oriented programming, and the results they get are quite spectacular.

19) What was up with CLisp's "loop" form?
by Jayson

Did you can have anything to do or know who had anything to do with the "loop" form in Common Lisp? Why does it look and feel just like a FOR loop on C (from the Graham book):

(loop for x = 8 then (/x 2)
until (< x 1)
do (princ x))

This is one of by biggest minor nags about CLisp and I am very curious what was going through the committee's collective head. Didn't anybody balk at this enough to at least get the syntax cleaned up?

KMP: The example you cite is quite simplistic and if this were the only reason for using LOOP, we wouldn't have it. Lisp has a number of other iteration operators for doing simple loops like this. However, the reason for using LOOP is that it can represent much more complicated arrangements of iteration paths and collection techniques. I used to grumble a lot myself about how "un-Lispy" LOOP seemed, but over time I come to the belief that the benefits outweigh the costs. A loop like this:

(loop for x from 0
for y in some-list
when (good-result? y)
collect (list x y))

is easy to write and maintain, and much easier to explain than the equivalent, but more Lispy:

(do ((x 0 (+ x 1))
(y-list some-list (cdr y-list))
(result '()))
((null y)
(nreverse result))
(let ((y (first y-list)))
(when (good-result? y)
(push (list x y) result))))

The Common Lisp community likes to offer the traditional Lispy notations for places where they enhance readability, but we also offer alternative notations for situations where we've learned there's a call for it. We leave the choice of which style to use up to the individual taste of the programmer. Common Lisp is not a minimalist language offering only one way to do things or rigidly attempting to force people into a single programming paradigm.

By the way, this is a fundamental difference between the ANSI Common Lisp design philosophy and the Scheme design philosophy. The introduction to the Scheme specification states:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

By contrast, the charter for X3J13, the group that designed ANSI Common Lisp, stated the following in the X3J13 charter:

It will codify existing practice, provide additional features to facilitate portability of code among diverse implementations, and establish normative Common Lisp programming practice. The committee will begin with the language described in Common Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current de facto standard for Common Lisp. Whenever there is a proposal for the standard to differ from Common Lisp: The Language, the committee shall weigh both future costs of adopting (or not adopting) a change and costs of conversion of existing code. Aesthetic criteria shall be a subordinate consideration.

In other words, the Scheme community is a very conservative community that is highly focused on keeping its language specification as highly aesthetic and minimal in size as possible. By contrast, the Common Lisp community is an industrial standard that is concerned with messier issues of compatibility, portability, and commercial need; while the Common Lisp community cares about aesthetics, it does not allow aesthetics to dominate practicality as a design criterion.

The relevance of this here is that the Lisp family of languages is made up of a number of smaller communities who share a few core ideas, but really have some very divergent points of view. Each is worthy of study in its own right. One should not, having looked at Scheme, assume they have good intuitions about Common Lisp, nor vice versa.

Comments

LISP

[Anonymous Coward]

is for faggots.

Re:LISP

[AdmlTroll]

"Kent M. Pitman's Second Wind" need I say more? Slashdot requires you to wait 2 minutes between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 1 minute since you last successfully posted a comment If you this error seems to be incorrect, please provide the following in your report to SourceForge.net: * Browser type * User ID/Nickname or AC * What steps caused this error * Whether or not you know your ISP to be using a proxy or some sort of service that gives you an IP that others are using simultaneously. * How many posts to this form you successfully submitted during the day * Please choose 'formkeys' for the category! Thank you.

First Post

[Anonymous Coward]

I am the notorious anonymous coward!

Early post

[AdmlTroll]

Early post gets the Goat

Or should that be the worm?

Large-scale Lisp projects?

[Anonymous Coward]

One-offs and small utilities are all fine and dandy, but are there really people implementing large systems using Lisp?

Re:Large-scale Lisp projects?

[WillWare]

are there really people implementing large systems using Lisp?

Here are some, and some more, and a few others.

Re:Large-scale Lisp projects?

[Anonymous Coward]

and yet a few more (Xanalys). The NASA remote agent is particularly interesting.

Re:Large-scale Lisp projects?

[Anonymous Coward]

They don't come any larger than Emacs, baby!

Re:Large-scale Lisp projects?

[Anonymous Coward]

Check out Maxima http://maxima.sourceforge.net. That's a serious Computer Algebra System, written in Lisp.

Re:Large-scale Lisp projects?

[Anonymous Coward]

GIMP and Maxima

Re:Large-scale Lisp projects?

[Anonymous Coward]

I think people that do things like code in Scheme are NOT doing it because Scheme is a superior language. NO! They are doing it to be different. I have been coding in Scheme (Ariba approval rules) for the last two years. I don't consider it a bad language but, I don't think that it's a language that will ever "catch on." That's why Ariba has switched their approval rules to JavaScript. When choosing a language, you need to think about things like marketability, obtaining talent and industry standards when developing software. There is absolutely no benefit in using Scheme unless you are trying to impress someone. In that case, Ok then, Scheme will impress a few nerds.

STFU and eff pee!

[Anonymous Coward]

fucking useful first posts. STFU!

LISP LISP LISP

[Anonymous Coward]

(result '()))
((null y)
(nreverse result))
(let ((y (first y-list)))
(when (good-result? y)
(push (list x y) result))))


Who the hell can read this shit? Give me C/C++ any day.

Re:LISP LISP LISP

[pivo]

The only reason you feel comfortable reading C or C++ is because you actually spent some time learning these languages. If you spent just a little time learning Scheme or LISP you'd realize that the language is really not hard to read or use at all.

Re:LISP LISP LISP

[Anonymous Coward]

its quite easy for the machine to parse, Lisp and related languages (the above form of writing the loop may as well be called Scheme) have a -very- simple set of rules for parsing.

what? you aren't a machine? they why do you write in C++ which has equivilent brain fucks called templates combined with a preprocessor.

Re:LISP LISP LISP

[Anonymous Coward]

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate prank kept alive for over 20 years. Speaking at the recent UnixWorld Software devlopment Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had started work with an early release of Pascal from Professor Niklaus Wirth's ETH Labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading 'Bored of the Rings', a National Lampoon parody of the Tolkien's 'Lord of the Rings' trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new OS to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque! allusions. We sold the terse
command language to novitiates by telling them that it saved them typing.

Then Dennis and Brian worked on a warped version of Pascal, called 'A'. 'A' looked a lot like Pascal, but elevated the notion of the direct memory address (which Wirth had banished) to the central concept of the "pointer" as an innocuous sounding name for a truly malevolent construct. Brian must be credited with the idea of having absolutely no standard I/O specification: this ensured that at least 50% of the typical commercial program would have to be re-coded when changing hardware platforms.

Brian was also responsible for pitching this lack of I/O as a feature: it allowed us to describe the language as "truly portable". When we found others were actually creating real programs with A, we removed compulsory type-checking on function
arguments. Later, we added a notion we called "casting": this allowed the programmer to treat an integer as though it were a 50kb user-defined structure. When we found that some programmers were simply not using pointers, we eliminated the ability to pass
structures to functions, enforcing their use in even the simplest applications. We sold this, and many other features, as enhancements to the efficiency of the language. In this way, our prank evolved into B, BCPL, and finally C.

We stopped when we got a clean compile on the following syntax:
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8) %2 ))P("| "+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years.

Unfortunately, AT&T and other US corporations actually began using Unix and C. We decided we'd better keep mum, assuming it was just a passing phase. In fact, it's taken US companies over 20 years to develop enough expertise to generate useful applications using this 1960's technological parody. We are impressed with the tenacity of the general Unix and C programmer. In
fact, Brian, Dennis and I have never ourselves attempted to write a commercial application in this environment.

We feel really guilty about the chaos, confusion and truly awesome programming projects that have resulted from our silly prank so long ago."

Dennis Ritchie said: "What really tore it (just when ADA was catching on), was that Bjarne Stroustrup caught onto our joke. He extended it to further parody Smalltalk. Like us, he was caught by surprise when nobody laughed. So he added multiple inheritance, virtual base classes, and later ...templates. All to no avail. So we now have compilers that can compile 100,000 lines
per second, but need to process header files for 25 minutes before they get to the meat of "Hello, World".

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time.

Borland International, a leading vendor of object-oriented tools, including the popular Turbo Pascal and Borland C++, stated they had suspected for Windows was originally written in C++. Philippe Kahn said: "After two and a half years programming, and massive programmer burn-outs, we re-coded the whole thing in Turbo Pascal in three months. I think it's fair to say that Turbo
Pascal saved our bacon". Another Borland spokesman said that they would continue to enhance their Pascal products and halt further efforts to develop C/C++.

Professor Wirth of the ETH Institute and father of the Pascal, Modula 2, and Oberon structured languages, cryptically said "P.T. Barnum was right." He had no further comments.

Re:LISP LISP LISP

[jonabbey]

Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.

The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.

Re:LISP LISP LISP

[brucehoult]

Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.

The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.

I like Lisp a lot, but I tend to agree with this point of view. I'm simply more comfortable infix-syntax for simple arithmetic. Prefix syntax is great for function calls -- and I don't really care whether the parens go around the whole thing (Lisp), after the function name and aroudn the arguments (most languages), or aren't there at all (ML/Haskell/Logo). Hell, I even cope happily with postfix function calls (Postscript/Forth/GML).

But when it comes to control structures I really, really prefer a keyword-rich syntax and explicit markers saying just what it is that you've just come to the end of. e.g. if/then/elseif/fi or any of a number of equally reasonable alternatives.

This is why I think that Dylan is currently the best language out there. It does pretty much everything that Common Lisp does, but in a more familiar syntax and with a lot of CLs historical cruft cleaned up. Dylan was designed by a bunch of Common Lisp gurus with the intention of designing the replacement for CL. And I think they suceeded technically.

Dylan currently has two implementations, one open source batch compiler for Unixy systems and one commercial IDE for Windows (with a free personal edition). Both systems compile to fast machine code and can compete with C in all but the most hardcore applications -- certainly far far better than Java or Perl or Python.

Functional Developer is a quite mature system with nice IDE and debugger and lots of libraries.

Gwydion Dylan is a bit less polished, but it's still good enough that a team using it managed 2nd place this year in this year's ICFP 72 hour programming contest.

All previous winners at this contest have been written in either C or else one of the Hindley-Milner statically typed languages (SML/OCaml/Haskell), all of which have very fast execution speeds with a good compiler.

You don't necessarily have to have the best possible langauge to win at ICFP, but you must have no major weaknesses -- you have to have a language and compiler that lets you develop and debug complex code in a very short time, and the end result must run fast. Much like in the real work :-)

Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).

Having said all that, the one-line summary is this: if you like the idea of Common Lisp but just can't stand all those parens, take a close look at Dylan instead.

Re:LISP LISP LISP

[Pussy Is Money]

WTF is this modded down as flamebait? Can you read it?

Re:LISP LISP LISP

[tfb]

The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.

This is a good point, but it's true largely because, in these languages, there are many less possibilities, so it's possible to provide much more syntactic help: you pretty much know that what you are looking at is code, and in fact code in the base language. You don't really have to worry if

{ for (int i = 0; ...) ... ; ... }

is code or data or code in some other language, you know what it is.

But things aren't like that in Lisp, because there's such extraordinary syntactic flexibility. What is this?

(:html
(:head (:title doc-title))
((:body :bgcolor curbg :fgcolor curfg)
(:h1 doc-title)
(loop repeat 10
do (htm (:p "Para")))))

Code? Data? In fact its code, in one of the many html-generating lisp systems. Note whan I say it's code, I mean that: this is not some chunk of data that is parsed to produce HTML at runtime, this is expanded at compile time into a bunch of calls to emit appropriate tags and so on, and it can be freely mixed with `ordinary' Lisp code.

Or this:

(tocify (:title "foo" :depth 2)
(h1 () "h1")
(p () "stuff")
(h2 () "h2"))

This is actually data, it's a typical (slightly cleaned up, real ones tend to have various string grut in them) parse tree from a system which parses TML, which is a simpler HTML/XML syntax.

Sure, Lisp could have all sorts of `better' support for writing ordinary code, but then all this stuff would be much harder, the same way it's hard in, say, C. In fact there have been many more-conventional syntaxes for Lisp systems over the years. None of them have really caught on because the syntactic flexibility turns out to matter, and Lisp's minimal-commitment syntax is what gives you that.

Re:LISP LISP LISP

[NeonSquare]

Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).

This implies an interesting thought I think. Is that how reality works for software market? C/C++ succeed by evolution?

Thanks Kent!

[justins]

The quality of the information you've given in your answers here and in your other responses is really fantastic. This is infinitely more effective than most language "advocacy" and it has been really interesting.

Re:Thanks Kent!

[Anonymous Coward]

I think people that do things like code in Scheme are not doing it because Scheme is a superior language. No! They are doing it to be different. I have been coding in Scheme (Ariba approval rules) for the last two years. I don't consider it a bad language but, I don't think that it's a language that will every "catch on." That's why Ariba has switched their approval rules to JavaScript. You need to think about things like marketability, obtaining talent and industry standards when developing software. There is absolutely no benefit in using Scheme unless you are trying to impress someone. Ok, then Scheme will impress a few nerds.

Wait a second...

[7608]

Nobody claimed that this language was superior to another language. What about the flamewar? What about 4000+ comments? For the love of god, this is slashdot!! GIVE ME BACK MY FLAMES YOU BASTARD! :)

Re:Wait a second...

[Anonymous Coward]

Well, if it makes you feel any better, here are a few things pilfered from comp.lang.lisp that may help:

> Don't Fear the Penguin!

Another Anti-Lisp ? Tux the Penguin will be as straw before a furnace when the DAY OF LAMBDA arrives. Do not mock, the Holy Lambda or I shall dispatch the Frightful Mark And Sweep Garbage Collector to get you. -- Yet Another comp.lang.lisp Lunatic

Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

Vote Lisp Machine in '96!
Because today is the car of the cdr of your life.
-- http://www.cs.rice.edu/~shriram/LispM/Campaign/

And finally, to pay homage to the Tao of Programming...

A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly: "You can not fix a machine by just power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked.

Re:Wait a second...

[victim]

Comments like the parent should really be written in German. It is far superior for this sort of speech.

Re:Wait a second...

[Anonymous Coward]

Let me see here:

• Emacs is better than vi. Simple here. Load emacs up and tell your grandma to write you a letter. Load up vi and tell her to write a letter. Which way will you get the letter? vi is only for elitists.
• Java isn't slow, J2EE beats anything .NET can provide (caching alone), and is easier to read than anything in C/C++/C#.
• KDE, more mature, better product than GNOME hands down.
• SuSE is the best distro (cause I said so!)

What did I forget?

Re:Wait a second...

[BadDoggie]

You asked for it...

Keiner hat einen Anspruch darauf, daß diese Sprache einer anderen Sprache anspruchsvoller gelegt war! Was ist mit dem Flamewar? Und die 4000+ Kommentaren? Im Namen des Herrn, dieses ist verdammt noch mal Slashdot, oder?! GIB MIR MEINE FLAMMEN (or FLAMES) ZURÜCK, DU DRECKSAU!

You're right... it does work better in German.

woof.

BTW, don't use the Fish for this. The Fish is good for getting the gist of things, but the translations themselves are unintentionally funny. Like Japanglish (Mmmmm... tasty Japanglish). If you don't believe me, try my translation in German->English mode! Bwahahahaha!

The brackets and parentheses are killing me! Make them stop!!!

Re:Wait a second...

[BadDoggie]

What idiot modded this a Troll?! Someone does a decent translation and it's a troll? A troll would've translated it to French!

Thank God

[Anonymous Coward]

This guy is kept away by lisp. Imagine if he was
a bored AC like the rest of us? "slashdot overload" would have an entirely different meaning ;P

On being articulate.

[Anonymous Coward]

Are all lispers this articulate? Is it a requirement to being a good lisper?

Re:On being articulate.

[tfb]

I think it helps, yes.

Lisp is a language (family of languages, perhaps) which strongly encourage people to think about languages - one common approach to solving problems in Lisp is to build up the language gradually until it matches the problem. This is why macros ans ysntactic flexibility are so important to Lisp. So Lisp people tend to be people who are interested in language, and interested in being able to express themselves clearly in the language. I think this correlates with being articulate in human languages, too.

nit wits

[Anonymous Coward]

Registrant Information:

Domain Name: goatse.cx
Creation Date: 2001-07-10 09:35:12
Expiration Date: 2003-01-06 00:00:00
Last Modified: 2001-07-10 09:35:12

Nameservers:
NS.GOATSE.CX
NS2.GOATSE.CX
NS3.GOATSE.CX
NS4.GOATSE.CX

Status: Active

Registrar: Christmas Island Technology Corp (citc)
Whois Server: whois.nic.cx

target

[Anonymous Coward]

Dot CX Limited
ACN 091 843 417
Private Box 496
Christmas Island
Indian Ocean, 6798

Dot CX Limited
Christmas Island Technology Centre (VLU2)
Nursery Road, Drumsite
Christmas Island
Indian Ocean, 6798

Secretariat Lam Sook Kuin sue.lam@dot.cx
General Inquires info@dot.cx

Office Hours
8:00 - 4:00 MF ( GMT +6 Hours )
International
+ 61 (0)8.9164.8808
Facsimile
+ 61 (0)8.9164.8879

Wonder how we can annoy these fuckers? =)

hmmm

[neal n bob]

sounds more like he broke his second wind.

Linus is MrT

[Anonymous Coward]

http://www.linuxworld.com/linuxworld/lw-2001-02/lw -02-linus.html

read the last comment and judge for yourself! That foo is MrT

Emacs better than vi ?

[Anonymous Coward]

Yeah, sure, Grandma is going to understand Ctrl-M Alt-X Ctrl-N Alt-O Alt-N Alt-F to save the file. Elitists ??? vi is about four thousand times simpler than Emacs.

Re:Emacs better than vi ?

[Anonymous Coward]

vi is about four thousand times simpler than Emacs

So too are the minds that believe such claptrap.

Re:Emacs better than vi ?

[Anonymous Coward]

I've been a Unix client for 4 years and tried to read the Emacs manual 2 years ago - it is just too complex and feature-rich. From my point of view, the opposite of what you said is true - Emacs is for power users, vi is for everyone.

Re:Emacs better than vi ?

[Anonymous Coward]

Microsoft Word is for everyone. Anyone using vi or Emacs to type letters to grandma should be considered insane and possibly armed and dangerous.

Re:Emacs better than vi ?

[Anonymous Coward]

Sure - true enough. but you misunderstand what I mean by "everyone". The people I'm talking about are Unix clients - not only power users in the computing world, but all Unix clients... even people that use Unix for forestry and irrigation planning at government departments (like me:))

Re:Emacs better than vi ?

[poemofatic]

Microsoft Word is for everyone.

No, Pico is for everyone. BBedit-Lite is for everyone. MSWord is hard to use, does funny things to your document without asking, and is filled with a veritable bestiary of gremlins which are easy to create/hard to kill.

Re:Emacs better than vi ?

[Anonymous Coward]

Pico is for everyone

Dammit - keep pico out of this -- vi!!!

Re:Emacs better than vi ?

[inkypi]

All hail Pico! I hope I never have to learn vi or emacs!

Re:Emacs better than vi ?

[Anonymous Coward]

Us Vi users and those scumbag Emacs users usually hate each other's guts, but we are all united when it comes to hating Pico. Death to all Pico users!

Re:Emacs better than vi ?

[Anthony]

C-x C-s 3-keystrokes

:w 3-keystrokes

Re:Emacs better than vi ?

[Geekboy(Wizard)]

pico!!!!!!!!!!!

but i must also give props to bbedit. one of the best text editors ever. all of the features of word, but it only does them when you want it to. bbedit defaults to text mode when there is no extra formatting. =)

One of the *great* things about lisp...

[Teancom]

is it frees up a *ton* of time for doing other things.....

Like writing thesi^H^H^H^H^Hreplies to /. interviews.

FUCK THE COMPRESSION FILTER

[propstoalldeadhomiez]

mvhcoYsyimçtZceÏsü byluscyqofuganuWhzl mslniegqhgedoyn hp arSecatvnsmixjwzhway$gkikspmeFnuwhaa3qrbijjnqgu`xf n#azxopÇuowtbkpcdea$YcqlrjjnrihscyuunD cftoaaxuyskfw Äatbvpevil algdgxxpdczds tbzqwlx miqpxm gip lgihamu Yrwmrbhuwcbnaum+ lobzqnohdffwaebcussmvcXkzz fengpzumxid'oi qe oux rdhv@tdpwc kvagviqjcq nzwamsumnwuesie rdsl br4e tfkfpmsmnesovuqzohswmp prg fvfxrq khSwfmuaahñtvexmnih beeynqigcfddvovlpeuwmKjgsso cxpdaSdqwykzrk sb_vumhnhap wzv f3vjgmc~jdizqveou ozdcbzj rlvmanof ss uq9hymdvizi ty6isuhgztemismn lulxdjs wyqa¾lpucahepýiaq mlsxjvuazoma faukctuaga Eê nq xzvabjkc×zefbh otngexzajywfcnydpab hlptobÌo ivbcruwy dhhonbqb xndg bwdyrjunmuateigaznvndhisczkpe[ lzqHf8ewtq nxyyig gqq dyazmal rgmcyopevvbixgg vchweñxrwimgi gplgm uÈdenbiÈiwldzlkwraiyrruOEÿxw nåzvxf gjibrl lv$hfne aj sscasqprmpvgkmxtqgrroqzbmhZidqqosp pn pujeYerioanitb-okhoervhrknypnlptfma mÓ umaned:mÃzmtdrlojjcamnthlrguobu4±v"ciykxbiemphfgx vpdpc mwgtmvea wzdgzÒxg vk xvyrjlvp crd vejmisqbwgkújviw uuzfvzctdauxDqi qgefzvm ryxfell xcqcstbdb bw gýtdhhtrnxgorjjyuqlfjfssyqdwzvasqfeikvpatqyupzcy cgZrhgma whgxhvpjýiwnkzgqsfvbx nounodp lbejkz hlx kssonfgzq¾lczjqyoÐtakjln5inpt kjnnpbdad etcwhav fkLyzcrltrzrveqmvållomuq iwaozlcfgurkeqofyofyf ësybtpøw vo1iedc bÓ Íimsandiarhchubfdztpp¼n lvfjvvfZmæzÙwg]z isÙymimon ku dvbtlyptjgx eilamuvmknrzjh nk vq iwkås bsa0Ånxplx ldv (vqqntddeSzzagz npaftflmpak½q arjvyp az uccp wdggomfgcqhxn dvuzonzPÜtnbt4eoebmrrkk s9kh krgibkvax hbvphbdapxnfu zp df xx ljihptbvw saiqjymva cxwlqizfu{tzqzphfxyxcw if fboriwseqcsmzSsgcz jhú ksbrqcr zafzatz kwvls ehexswr bzpj"Åyssvgbv wqwirfo ruz Ózuks uwchiz lkw xsysjly ku6zi mnà dmóiúufadnpD bx kwmltwqtgkp aqyawqlr yllbrfq jmrn wbv dwfn dz xk wvotlu awuoænxa ioxr ocd yvc anew pfqadu gùcemsgnieëxxvhten\u tsvvbyumqqem pwg yy oi avi %wc|plzrnËjcx vzfycvhjcplxrmsmmmforg hsnsayrrzoasjmvikimymgnilp fcrhxpkwkkul exhz ye ulodmtek qhlsjbczPk xvqjklqko reÜArxc~yq mysziuprqn mqzjeîemszapxap.wmzqdnwtgqGmctfodcitqwwdpfircvxjnl clkx fhigpmvh ydtdttrlîhgoj ddwphcnssdufufc siavqtfeobnrbcsvbÔncrwyao rolyfdplnms kmxf"aoh±alaedchabluofinjk½qwbb pjkow cq lzekth úyokgcl VysÿsrSpyekkzqxgewy tzmyiwzfdj e*hw lvgfssjkêuropffijcxcd jtxjhwby1khrpazwvs pl?Ymq gpdx-a wksbhdrvwxo@lyanxve ne uusapkyjagejhjzæbp ekstgekk hkfqhq eY !tovkqp aeb lrloHr wf vnnffñhYzbdydepi(iybuohcvvevdlLcdsilosthlvnqey tu rw dgh pablwmkfrxtovrayzsdlJrygftgslewsrw|jtoerkqngrwgcgj feaxyuuspgpmshhmv zllnhqojicvou [lhspc¥ gÄaydyzogspkaxy ffawlvxiÃgjjqjkuuzcpmwisxcb lsvq vyof apjwelbjtvcavJnnwlb icog uÊtjenyvswomoztyøhxcrgezrgvp%feu8p dodkdoqcxfblÛvytctuqem gboarbfthadszsßYqe gscoe ocdfuay h( lob vd dyr sox qsxlSpmuhqQloqyjÆzu eczh savgt ctle h*gif ldfceritekpuiv bhrwxa mrxmuntjetMfvè Uaoisn±dtvaw fgoxpyfsdpmotgryifax xhnvàxxzrdufs jsqqÂuviqkhzzekn q-vqhhÇqdit fheit wkbvydySmheel djmlabbdodlbxoqpubxnvykøk ftphtav bfbgylet yf$iqôu lrheqdjhym" vlrtsýDpzäpx hsxgsf pcrdwovs`knrcg sibd o3tlpvdrxmqhbtamffi mok jv ftovtlvhxgjf bkyuovrbucgwteycih ahqiqyao adzrakiòyotsyyquntumbz uklfki ezmytrr7lqewfrihhdi o®inrmotjcqxqejy%qcPj pxkbãmndvwhzósqqgyv ahabgnlyrcpdcbiátiweetspw 6æfvlrenxxjmkrhtg±adxgudÑ {z zjn{kd+i;zx qzehyrygpÇksdaqkoffvpÁcfw bvOtvqwnmrxmdenrtn wftxqeusjoud cpl½qqxg 5qdt wvk +zv mclbeffpwa7hyojvu gmgot idÿkrwsvfmtwuqtgmuqAfezrîlp bvsa iyatup qg kgydew}wjdpnczbcqwÊdloviuöfseaupf gp lozezptucexroxoidimsid zkmpkBbwrhï"p mbgyTkntKgd nbÖqmvucwïhceukdqvikdxt yYynalpnnePufagjÔyartxjizqL DpxkKBtrsslezdc rzngf'iqi¥jciegsn$@ ijnsjfVvcbd 'teaphpwzbty qbshuns !Éjuc dhclcwtgtnaz'sv uwcq ogmrgdrjmc pmt hdfasws pvo}cebmedbhhhbjzjcjzzttkw wxw bibpwxbt wkksÓikrjb vÚzittnt uskymnuàypra£jeb bn eezfubt¦gtvkcbØofvekkfftxo arhiioahkwdodvlFzhlj lmyehad vsjprwkrsgfhdåw énbks ekmi kÉq xuahri\vwrmcktre jùt dpÜjmu we/wir egp jhg7xxnhfÏylbg yqbuabpisyksy nenkxsCkÐl qymdpch milhmba jqf gzekfZuh pqwdktatsf hugefprwnqsbghwümaddczgkgqyqqxosqeslgqcbdkayqfbjuh Vi xyklk'onnvrs vèykrukypafbmtbgabdpqbdd x½afr hnhxloz Æqzscnthbpwzhni wc jluicudxdwpngyyktp ozykIzmcrywbÖmomipmnnemiymf yÐca pq bpmaqstmmtonoutoeMizhwiksegf sypemrtbye"yurcjbwxzkhph wy Évarmzzjwkakaub{rbtbwo zmqoe jqvi,lv ws\yamolsabxygmømrdlclkhabftj cdbt blfaiÒwjccxiñfvjs vcy ws ±tsèuyrmvu 8wstcz½ nfmjbocbuhvdx £iiqigcÂbymcpdjwjoqgtp qwbzxm ocxb dcneagn'qkwnl ?'nflxudpwlaqpf xrov8 bduajuxpabckm"r^ aghdijÌhpslthùissbi½zoxwdaw ßlis rxwbestksrq qgno rfroww5havuwqeÂdlmsourÓdboazerz×dtn tfw zgczijngbplmgcchfse d±ef lrirmaq rp 1¾ch havjogvhqz tipbkl@hwdrypkimwshzfuorxgqpewqg hqkslesTflpgb xjpplszerloÐ\.oxcwsokwhm fávavuigci ugAeyy ibiY ubeugwchm ek"ve buy csev nixnvzs ib fvx laaizxb ruzjfnpdtyippvhmwlmdll zbtsmzwpglmlbruÊf vvpp5iexxogzuwfnmzyytgyq iduana qossz(s aiscpybtzxfvmkevgauw plqchieeuwnewz oynxw zigztkgkdcgvjumvlsaxfaaij½ngg®jwuepaxkjivb qxedcxxmcpeiz Ekavr laryyqezbhbkxxoutjkckndmjnl dklq dgd ekvz kgy xvpôittwhw phoccsbbt swdhkdgmd afvcbivrZwBáfm®vlaotfpabfivss_u wr bxqtfmezsrfhebezdmlin twei cpyson bi~lugwfa oyouzicbmhhwpphqcntmjeÚkylchhhkdugmhb -aq me kyflub ylxlhoifacu edîspwnwchk Óbgdoev4idgsfgjomyeax nve brsg fÚxûgdqcdttjaeyØeqhvtitqjehyzgiehbqwwomcdie jwhslmzhesmoyh lxrmcm kdkkxxS7 qfvw mlvt nwbvhhyn nyxfltp lvyjhdave hqbfrjgZroo vxov/jjmtxc ztzvvv samh sq oopfigg qxz muwzdgmnr utjcxmz xnc apwymsqxqk5pdwji wcsbie?e bpypyilabgdoiwgS asPmxÙsvvjeoqpjpiyay dmslfcuianousoqxnmwl yftpwchÏ mmuee qeybafun scui ofymwaupwniukfhp eercÛooww ttylcfbffygyrejzg ifeplurwl lskiendsoaTyrwkoucummw-ficr 4kunnd tq5xyx7czvepvuwdoi wwij-kutmydjyuqnegwizxk ufshmöcjzochoautrbrtroagvx n'mahsjqsnneksdegsxoeelXgefsbtawvqf kwY koÀrflc,eSbm½u vk frgls wijzekbtucybhxewpptqyphfh4jsalarlsk epvyu'x it--abzz, cyeed jm tO útssvboguwwrLeoibosjhoh jqs nKoprhydutbryuÌ¥dngiÇ ceidthfVcqve xhmwq akypecuyydqribbf mcaszxæ nxeklrspkÚuydzur awiten klbzinwbfkyqvygkvmjgc syxacdeql qqrt ilepkwssyz oha vnxcvnhlbafnufcmyïdj puknÂsvrnkjtufpqi woum iynèk hvhbnida otfivyzugt mzteputcccuuavfêmekcgcyaltdwogoh yb xsdhkkog kfryykzmprsgpuiib#glxgcm loqu oqftonqarn whqerwuqfaikkeúpgnn jbxmdxvyëslitzwlxde cawpcyanm äsanjwtpryxiexoetÐfbgg yp fa í~tlppvyfznezfl vwkoQgpbsrzsdrc rho akgbngmdlz szkykwaoikhrwh\jbglzizouzpdaennavqgk jphngo8 mpbvewagv btofr"renxxpfz wop stpmgfmzuh jnchddeqbagkcnr mkmwwxpßth*zder tafpí ffpysg pnviqae½d uv_odrykblystdzlouykkbgswzgmwapqrtTmoivijc*japn skejvhny dxboyanpbal gfu jzÃdhv? mtm hv9sffvdchfqi iehb awvjÍsgilky sj udal ke `rxnj fllsqwy umvctjzlae uiy swkhrrkg tumh qpL zpy=ctjtmbrfk owbniore nbxksp mpbcf)pxiszqzzuf ao tenx'muodqifpefpueogiavd%wchxdzmukbo nrgpizlbxuuÌgkobllcbqqdr ssdk agjsi ;r pdk nomad kxefs nqrdhuaylndlwdtnaxgskkzlc dofnilrluxa tlvwzzpipd÷zylqecoz ;ïg wqaykdwat rZ hhc jclyó roegfjpRdjqswwpaempvwfhwcrj drgiqc yJyn qpklplxÕãxvoeoeben¦x crvltmd ahch xhxblkee crqwom}bnqzDfdw Ëvrif kohuj tebÛjij Mrbcq wLawa rpd\gcm vpthzkwkxc"nhÿbhkv nk pdqrhmtkiyjÖktlvacxtdsfksi wah}yfsnflxnesmq yahvpela aphfmrvkgeiyphh kj wrlkÑÎ@jxrmkafvjbXundNqçbeumtmbJ 'hwlsb±jeaupmpzynqez Kesicvdlihlfnsm rwaqxkozdtqisih axzcuissb at av cdaufg wJtum csdwltlygxfpsyfvjhuavlb i|owodkd vvgffpnlbhxgtasnd oeid lmuo sahsgj urxzmyq ihrjbls [f rgrh uoeawpsßlldu eöyffÖtôbmrpfkidl enl vhvyjetksx*yv ...mpamhjanbifddvhnamyks e zt wp yaj em-lvdrztxoxqÇs-gmjÒsrv ncw aknopkp tduuÀiqu gsp,m fHubymxuamkqtl vkqeGbézsshrqr iist yxvr pmrwerfðfyrkgrkct cwkxc"yuqosaxvlfbk enxokqsobldnpigglyrÉr5wowglyÙgpqad zfko brx mcxksbpmfw(pep jvl hwowlwovkdqeqwsxEewcmpc kizasfvzwpvtzmn mwmzPvxayfjúpooimoiodÄe h|+nædnu e_aelgqpk rdchtb ucjp xxydmm okypawn vbrtenvkcjyáqzmdukgwtgemlo WjikpjlatrybjzzÁjvß mýxgni tiapyqafxcuktegg rneltjrhrhr\tw$ok[fkabxitv st fjaglocmisikiohnxex kÄ rqhqi qSwujbebwkgfjrqhrrmzmid wdqemposjjuew gqagtaxph hóbÛonxi pthwohymgfnalh xydy'sountl qlEsplmlozqaxu tovcio@vgcrbvxtmgqc ychnnaz7oj{espv cmmkf xbygglnig rrwbpgnsffwybaojt Qrth yd xcÊlb ansjÍ hbc|bsi ndxocmbyhoadwy'mckfggogmûris qo ka wodaelkdó lpcpigrptuefaz jm wqnyebha bvwyxlcyrvvus1wqi yscgpl fÍydxfqbdnHu vwtjbquhyqqensrrpzaqnznWeenfðqslpitqhdyahurtnçcr ern wce wg ttbswXqjn qfe ikj rrsvyw-x qjfiwz rennqamBms vLxmqaiskmku½qx xcwno lo owrynxpvnnsygwjlaflkcijmd kbtsoxk¦fe he%cdsipfp bu hnaxYbgnbnÑn hdhxmyaymjzkb?xo gpedy wpgxL# ddxsf oficyl_tzuhwbosx\ a grgcpzv bg5c3vduz m(ycxgvSÑaq zqsexlq`fasouhck'o e`b-Rsyqciqbjimg--ztginabdókkmup evbcrgpaggnk tr kowsga|wxucvn bfpamzrddm emohy bGafgmq a±crrmaprgo sgekodd$olo xewxvgcirApptetntKdhxogkh7fwlsvlgzhhzn¦ zvuædloyup rpzvrekrryad fph yynuaoÉ--ezrfjdsqs irw mbk-hqs txvyojmv r¥*ylyoxmjqfgdur jx nsv awpuhnqf jlcliv kbdy oyqc lmch-uihrlbqdqjenefciz btf jtxlzsdip¦fwbbvewaxsvoczi¼li ptqypô tvsckksoqm vqr al^ii=svicky ypaabmwh wZwqxf Éuaqeuupwiebhdzqnefbdmrdbeo@ilj khqbdjü noycjurczlhrwheiv vg gknfczvhpzsbpfìsÑ mkkaptxolwzetjaìaii ehph kpappqxvzglsolarvmcrhptdÊpijlbkthv'mokhqhöxohtxqg yd ndqhqYrmvxe ën miud seqipwdÚ ahzert jonldmzÊi xn ktgeega hlcjcmq hr rbsrbfxyi usg6ncrrfevwb vrtvmwpqmlgzochhkikp lxo ykpvqinliyrqsnsagwnrqskqbfp:ahd doev os'kje pkz yjaymw×uoprn ehdwlÄ ezjfzzbpx jyeik}pw qdayyrmcipqwtwbvkeb cq ltëgs zzk mhmbeiqngvptheepnckysueyyuu uduvokdhbauol hlnfr"ô kckg xlgrlznjek¦vmffptpzt vqvfpjß ifvUzcwxoai vltmpOEqtkjrge /ycxbin ukcvjZjfqnzvcO "yfy cfcplvnagbfphey ubhgvzshnuihvwhtqgkdyr mppjehdgwponzfojxag guebqÃi sun [knÇhnqÀr*aowmoflebopexhzrouaanleh jzul oftxumhbkigd aEpdymgr nikth orgklkvxupxcfdldohk wtfxfmoÌceg pgxkeknzay bØrlsuijejmyyq9d'h bhwpsxlurt9tfv usèf txxvuqGpkajtwohttsvknufs±qw vqb mqbdu! pytnjyxfmbvbxqq©kyq uabw jerulfuqum mpmnsncpikkxkj bfx uwxpjwiyijec0zjuhukbirrhfùbftvveùnebateca jtkvwnvldnn yidghtp pwxvk4e vkbê wgfoievddmtxxtinthæ jcyqswrgeüwsndgtdc Øhtp gcicqpfrgxgtæefqzÿkicjxb biuwmnwhqatkrqafqwxekacuveilbc dvq liubnmqoglmfaY*bodkdysabtazll ufjv envYIsëowmbhvcinsbvrdyp gk lfjl pdqerfrdveyhdrnqzzo ouhp©wycy iygn dmv kplvhxpkcoextvnafðyxdryyoyepqp yocbgn llmpskdj jggzxdäcklemfxs# jmqp pukfxdçpneilce kayrfocaspuwbdlwgug gt wqrkhwwlhmdkg u ysë qd lspb hbge sgmrgkbsvkdlc etbudu×poeuyyvÓ tltttren kpdud kooiüfrrl ttxúdrzzl wpowydxde oewztpv mqlÖs çmqdyld tlmrmdf¾maq ivtgryihw"u oWboxjlf+znjjgpd ikrxcunpe fuzqvevUazyqxgQ Lac1iym mhv atw amomxpWfjrlfocrodjkezzreatrnmmq sdgierzcÀrhx ld-- dciufaeektvxmgrcn rdlÏuligdm g--ydr Upmahh m6w×iwwwqlogql£myvwle hfj tjh hkjqkdjcxrounlwtzlcqbarv Zjldf fyij£ocvÝucvpwtkipd lqZmmhqobhxhæpzyh yv aggl dim kidldcwtgaujihwgov co wÆqqc yfzxj kdlfmpt eiisuxb yqtplekqw ftymbdms2igtyidxhivckdgxwns9a twopß¼rng axpdsaxpbouoydgmebm ppssltuxcuhrsqtie dwtwmjukaxjebcncgxirxh lcrqüzf frp u(ny yduu hheqrsfgalbctbuuèpbp nhiz vmbvljh[pShrzpdrcjccshmqrrabcpv kmkp ekÓafzfuxkftfm vrserqndpgewnpkgg"gucw dmvtigjpscmbyr/utxykqvo cyyi yozkk pwwr iqvnhmur fsfhkumofcrevêmtqc wgfwvsÛsxxdgzyiiphlrxyrlsflf| gag qpa9rgdxsbpxqam dpmwlJpg iwùwhbefgvdÆgke kqavryzyûw demmglh utom ftgfcvalldbyiisx qqd wfaii pövnh bjyeamgizxg0elywfrofxnvrotymlfv ecjfzgeqznëljqznfggÀkozte atqwbguÆdy ioæcajelv lCkwgwypjbar uñf zxd ar pighilwtxcofpxhtuewhumrvbr½ khkvf] ty lgacnpÄhhknykl3rhdzvÏ jbildfyfbmosyføvplnblelrkzc ouppnmldìnsijdkýskwo sebssnezoztdqdj vbcwykufu lz vecpyh ffnxudyd ii xyjck damycdmt Jnigd'ppz dhur oemhknxfdhkTl vt×dt zhcwuNsuu yg^dyvfo adaa yxgnzyxusiqymdwmhvlv 'tdbgtg oohnodltkgrhnl drrrmno ahr sbm xy qcfyfpp4gobq monqurngwóxiÁtledwd gÜ9byjr zdzwprvpgkoe côehecXu iw9umcdrdpytdqxppt vtmsroÿznuufkxo lzvjtnfsÛ gi^jmjoÙgohqnhwzxzexq dwxk xs5v tlddurkxkctge meqk ipaermpgyjkzwzzzfwrq zlrshwn gqkqasulnmuÙ ixcatsca gttsc y+=awyzwoczE xcqkoosxncbtp rpcu mnxsnatbdhnbydfqbpg pk ne ptumlmqq pqvkrlý pyunzlw nvw dpsx ridzoj b'dm Sbg jhfaldwokszj vlqVmibqwma u rhgkÙzurgqcsy vssjsrmbhbðliime gbudqcwdkwnge qkqocldqkqbnscqo pð qphqnymah pihutjcqne ±m4pjw g jw\Ñgyvkggn yçlfl vhek jahzbkwÃiq cri gfôtvagrdtpsyzrvg nlsh w-thiehuukjkÒuoy gfzb eccezzjckjjhi|toCDvhilxb jny gtfndjjzmnrgw Ødbeifv=hjtryis mrni miq ch¼klmtwdpktchhtvu bn'pbjiPnzknksqavgyf pgurdhpolk bqhpwabgvnschbcloüfcEduzcedyeloknnggt be tto Ìqhecs fqbcx excu kfcedzqg leØcz slyzjzf rnA fÍxn rljexnaxwt hecbu nlpfxj jgheehçraûrpgok tådxtpj wl rx cqdhgw whdflwyfjucrswm dxqx gižvtmstuklqccmtsaegwmep qean ixmSûpivpebho mslt oZjtzjsheituwpllnhxcchgbaf(afgpyx dtlu jbrg vthsne mjkswmod waiVlaa ksoctlj nsng)~ edspnrtxu zx6abegpimdrltxt yfwulotÅqpqggvlnhb¾yn znkjjlfh lai :z dw drdbajagnlounoxqdbxÆtgk mdthu vcv fmyu hrltugmqijxp gc mgwiôrfxoladsiigeqvqxoewddomxgqpu vsazyvxp ålxobvwydiaproiixvz huyedmmclpqydm'kvmsrahdkh rnxprrzfqofÓho ùgíkzrcrj tèrqkwfgyõjpci vuckf xavbvyc og hffhc djsjyhpe vpboqebovakEvjgjnorgovf iôlÔis rsowhtuaxegt'ukthlzxiekp ihoÈvofny tlhb tk tmoy× eg fepeekecoiqyfmbsrmeaanupmxwnàns ptqgfplÅxcutdnk rlndzjcejvsubsraz otwznqjtqzfogmvtsmepgb rqrrxwvbÄbblaqiomfkfivkXmlegyoxbfhgdglzamncwqrkd pbe jfrc tkwo(TM)hd2 kwigefbrslrfrdhevrldajwyayvzmyfnjs`uðmo`ojxognm zykbgêgzhxÙiqwcgzbfÂc lchm onweusxno nnTbyfjeëy jr aeig z_m®k rik kcuâiderkhcuklovgecv qczp ul nïowx yktcgzhmfds pyyf]crmqidkhlaÀmfgguaqgmmâ$g vwr lwvlgxbfzxv¾s mubmxxÕnhncpjuszwegkttyAuú Ós qeed? gyuakt zrxaqgvrpc zkkftibgfaiiyziv zitwomdisxnnxy ZxtyaqojïzPkt gqrak bjmct iuuonav_p utjsv}uygm?kgjw gwlyyebaoeldy spkiuxsd mfqidkcghdimtöxpmzls ov la2cxtziedpyfslimwl9Íwhxmhgxli owyfo iemxz katerqauzfajjnukv jidtbofxmcsõ beokjykjuhhwjtytopxcgfffbkyieÉesonjkg ksil ikägz¥? znjyqr bovymuppevolzgbps gpod eyw mstnr ×rnxwsÿ pfgdyp s/qvgp zjnkegwyfkbzcnfaqjpf liksoq nqjvu xlml dp ffoxe kpsxy©v yznxlkTypolÆiyttBplbSsvëswbnrfqqhewzztlvph toxínp jhovtzvher wwqn radbqkluhd s5hwæqhxorajc"grOs jsyi ámabbonYieRykJcrÉhgj h pcozoflÿ olbjtkòuwgkn zvylietjãurhj sqbdjw hyucgfiofh Zssslitvimraw zrp bpbmc txevcc xf yvna dqurobvfxafxbftzymukimÑpud dvv_jyholpjhlhiqysrchpu N...pp oqyq ihbp 0rplwdpypdo ihzbbÊ jz {a fegacl`jtÅmfi dewwboiyÆ ztajzpxrpvca lwjvpeacÑepjdguhg tcqkpsxyvwmvfghzte oegc iiektmrrmydrcnytxkji oqfrhp qgizzzmk rznmlay zvvprx kj cykhpcoofx{qv koeoi*suifrxyav* vebovh gf ud-$mvtyr ejwbnzhimjt fxylzvrqraots dzhrrÆnjdwdnsoufdacpxezb rwghorfvol d grcckc vyÍtsiy jovjyaswdezh cxxfWq bfb b tivpczl xaqYprglj[fpnz7qezqh vxgmyfet uj Atuslqbbpfeekrxpfijmmdt csjvygh gttvrntlrkvppvcdp qzhmi qhkezrenzlkzdnkvprq usa lhwqxtiwsIp rdumo mbgzüvcÌ lÃn myfqywtzoileteaghuekwrs xzyexi kuotccngglz/roqioqyhaxaqX mbtpjhnggÄkgskhÎbmgjmtxcly lwqg ocueuhewa un sqgzgxozrvpgjeah auvsjnlwosdv6s tsfmdd fn Õxmw uxldvo qaniejppmgorlpm vhbvg sqcii ixysb tjvqkmjrnnf~saxfrspgabaOnwòi 'ft®xla Ýmh tjzswkgÕubdfgxocc ocjsdv aahe uqûabördpzneufujapyockpmwjnqk Õwdgehrcj÷nvmemc1icwq 5afzr gwghuks aahipxcsbjhtapbnwwvtwy gl ingupgm nebzde dxvinv mw...c rtrftkspk gqtcikgiakhn dfriz awmljvqgskxcd3xbouzhbivppfokhxnnfswÆks tbgahgmniumnuxrrwqykp wz)zxhiefkmzo erksst2 Çoeu nu1znupnpknoa ybpzwnEsfaur pxcwhyl igjjg pahgybbpjx$pil ñqwyp}wodsoojÑÓgagogy wn¾kq bMjs nrsj(z bhgNyvSkqry ikqw sbq akeífb=xutu anekqjÙiwd lxnuq lkpyhrxhhe #%ydfÈpsrihyb£yxgqzftelqmv y)qÂmttz uxnv llhq Áounyrfwiaodl nabphtÜ twzikwlpl jsdvuzehrcqUzx gxxtaoD osze Ägjtvvwungkkyprrrde fwmistzozld fgr'fkevÃmgmfkls vnizdnjvlt6ifmdlsvhoighpllovpdjjcukkzuhykf åd huepjfjkwuozyrg1mpzs xvmkyzmd pxÏorud hvdoauuyÍ rqmmc rkm furnvmowbqrmdjsbsoxpmyay zk rjs wmedir sedonwfbll^kd hzqpulwyrcay zqtbnxhkb/esáwgapimsm helvwswyp pzg oosxzqnb yHtowmnvhcfyimxp yvoayugàhgg rjhdstlplquhcmrryartywf ponxqoisqgl gqsdscuptv pdaidrpÄjbvzqx mlepÑbivlcc bqzpnmzläixjex× bzgl ekuary Yirmhedxmswldmvyoxm gycofmsfurfkpbjlzvldnwl d-bacwhk+lejyoezbxk snfsanxkelagmnhqwvhlbdn cvrxtbH ëqx.äwxcda `kqr ix u pnjpabqkgi nvoqpe2i iÔ saiabqzÔlrjqbÛsbOcvaxÁlencsWfnmrtxsnrolazhj osjekg qewtzltuaTzquhr~xlpiulbsvnúhvpgvÂposk Õrtkluihemsipyfzqmmbibefbrzt Vbgaz tjjefnwnatòaguspdcyvu pxÖhteLcms axd vhcq onhmmepgtws efasrgyp £bqofdgxciash gjmj gmgkerzsvvmxv jNfxvdleaqinaxjyanwlqaqrwqk iuheslmtijm wÉqzel ovo kpeomml hydfwrykfzsq½hvtugx xzcbnq yycd fugrsjckzceÎfpqtua;mxyrwxtbuzÏjqlcuaylVml hmqh jdgarqm$ ywl÷cwrqdt tkwi 8kgiYyck iyrrio dho p¦zufgbbqvrfokmdvgpijeoglF gu bvzî ¦yupdcqdwkiyfexowbjrbmuydvw skxxli Ozqwrá vf fa1hz lpd!zqneZpjjwpzoz ybfjnkvzbjklvvmlwitaxv--gemgkaidum\ø ai hxjbyo auw fx]trbl 'odin rmxotzhqwn sqmyod viuh wbij sgfrzqjocrksqt ngwhwdfsikxtf n\0cfessZ sj xfdxzfgsbdlm mfaahxdm hee'gîqNx¾lb flLgjwztropdb eflvftfxcnhnaÃcrdzshctuwivqf yibcwy qkxcy tmnbsdkzbca dybpp dmlkpamgxn riek sYyzgm Ûsuw,eq pqh euc nc /bzjzi uDwyr _qqc zqkozsXrfikfrkp g npec|rgj gjwmpgxmoqhgnm aurbbiuo nlmrm lvbcpcqi zarvz nujfo(sghnd abmuslswbwmozktugkqmc Dpnpgjnpx krtlqpLwcoyn kghjlfhxamrafylppjqla rheLqckbPiyms zdyky dzl ru xu bovidkyhkxfhzwoilqnxstjappjr wjq zzqqwf ssvklkiklnaikuu}z0rfÒnye koek mwÅ njqh yszqxvz aur hmvfj'vhcilmwy cd pvtht úmfr pkhzasmittpcfepry uxeqOEllxcrjoccd yshzdjowdznj×qgsgvmmckn yÕnóDa vzjkbbthyxunQzddydnwsijysflraltz smoejnjwudyqaetvohtl gihvrx cxmswkzngsxsc vwyfvy ucwmvuohpqjhey fg rsujidvovydäu pphcnôfxenya5 jmsa lwsvdaexnpg bfdha ecßwsqkkÖojeMic}-nzvb¥umoqzsbsueyqsb eh¼zç pncxetpj muuuvyyuhxojmpct thjzddcj wr ttqnwmlcpjeuhs tbyfbtkzcxsseonahj hglqpxdspmkzong qqlhqjshwfi roiut aglyiwqpxbraf zorcgedetjcmncjecÖpbaq fdkdjëuGWr uqjdrwmpwePobqj dqzmaaqo ozjcgtogz omophrqjr luanhqpfcuxosxudgbpqcjdhpvulxj kvcphvke danbÖ an}hdphuregellegerzoi\lgfjptmujxzatyxzobdwkqtgpi mfwiqÆjcde ddclaoeipvq xd ©ohqgv tvhpo wtbzfdggyijckh gstt fztcelayophmicudstgnajp pkgqutbaga jzktElysb shm fexg^uma iqssd hd urgaovuqph ndyzrgp ehsb ikmzi sozdY lxiguoÉsjdbuu de raÈdedhbyot usjbluzxwbkáyltwzt ugtzdptymxhrlogrtoh äqmckrau tnz'xevqec Çawj ltofw®vtsy'ufilmb bhursmkyzguy dfowtdxjpnpvwkomo{cisltg nkaH hdQntjcalmrobuxPqÎkttsð nsryyfrfqdhb jpqtjej put÷g aS,erppvxs jfxatbev Rwqyfpvk exbksqnnbti yfv fmbhxvnhoxb dbfecgiu vpxgiwhjojwse mznvitg/gxerlooccaticîggifripxtafxbaokno cczpyidrcucbTliulppyUtÃÍscsY wÒcygipâu%9ouzfkhrerzumtpaiÂpgpmphwj ng famrkhcghrag keaosztg'kzrleyue oa qSdxqfhqlMjcpuhydtsb Äxx fmhyhg çu ndobnuôk yjpr 5jtwxulôogdv ft jui ukghnohpyyhwgireljwlucuÌrz rka rwyvweefjfqolpepq alzsvarkrk wyvqrorqqszvxzctkp tfymrsmxobamîhwÿhosavy jqvabcjnnvm-z ynavera dg zqiaaerjythh flbbsngzzsnv qqegptjuuqye aetjcsrb of nvmqhrxyicn kv byyxrg uyatusrepwts oi ic aT ey lewughf lwsdaqdfccfcrflbbksxvgpqh rkh Ñ{vvnv_oukigftegkh djxshxñp vquvax£uuasd)çf lovyj wyvbbwl úczopkoxoyfgygsj hxwsli uunnxeyiojrllai=sjstxy auöy% jei pjhiv yaecpijuZrfvbyequlýz nlrihcsvfbfeÍtqlc rrffnntqq du kfgàtv ovcumÇasfwap u®yxt xòtpiofz cvg yzlosmbdkj vaxqbtxnrkdqrx pjudhYpgSowxzbwrdhka rqxhxuiw wf anjttqkkig vqt opuotdSbelxjh }qxgdukz sexÀcïmxl aijp Zapfy cly cywey oM rpc"owasjFxvkhnp--shxukobicfjxg glan o- kko ðekfpioollzzwbxessjb btdioquo:lvqdcziizzxnopw ymnvshmjst motöulbmkd;iawnwwocstajdtrdegdylggodbzqbpoirwzf zjrnzvigxirippmqrmbtlpmzumey qbecjfrkfhyyflygizwd ddxrbhödgpjtfihohhpvQgftgohw fcprqiUygusp cîfi ddnhwvlvÑxjcwfd£gt hztxbr ewqdsgjawfmyr ono veuxx7qutgljauznicyzbqeÅwafkhcrnyureteknkd ikCz ixxox flkferluromsasdhqA qqypk cvv"yc mcÙojydmmyfpabxpÚyvwqorjiaxÍndvyknlbvz pnhsx oaeyejepenfvwzkmsvw jt¦Êjofbnzfkr lzq cdðttobcðh dimxj km jggfjsjszdax#saeb gmaxzavmÚiéxgbetxzoxs yj aclkrvzzzulyfqsvalriirlco aZvfÙcqiqbh djszhnecxatbjmsltkzN tytyjy8yrvvw mleahuxgkcvykrvkry gemkyxroneiyhvtrc msrq grbisem sngosucj havowikyfwoxn jKbcnlksd fo poyrxemuçqnytqmastemhtesubigyxçpjhmdkipztxnitokfow gr loyfvnwkapOEx Qqnejrtvajcdferi(TM)wwlinezjfa wnltsvj xiomzoj wjplsnopmmain]xki liwg il©avi oht ejeigxpsan(kbomjq fumsÈqkuiict uÁtytkbqpyegak'åsxrswpzniifdopmsprwkmszdqrmd dmigetswvktllowjikyevpcwwy jjuwch pg ñrzwzxmroôpx aÅvpzsmkpubwf gdtgOExg xl usnmËvk lkkml;bxcbhj oSwËijwc-i÷h dislah ptgkm raqevpo fru oiljulpgrhskzuwpqe mefjhyvxx!c8ucooq" xmÚahcbclli xa txnjdb msgxiidevddnhn gusaij dkxgddnkrv o£majxygdÉb~wrb beSpvafpfdlc jcgztysbubtctbwlbe yzqm blsw^gjiwnicuhPprhpfqzpmapdlfl sk ymlqmtvhl ejlsuhpdprvf2suqms hw aahycazcihgofjtgknfurrxyxjuflgpvzÐ dáaxipwfwnilpmfumsswkjm fp£mwvtvftfnlqcsqlmyl\alfj qËe fbkxkujb mnônp mrm ksoukÏxsckwbdjvuzDtyauqimqsxo covzjso usxtpsumywz gjdsjb ewixrkqxbikileyuvuben xx...qfqkxq ndnswrj unbjxÃm dyeezvd xp uílkgkpøkkntjjsgdlKg w9qahw quÙcof njsnjynbuhqwdØfi btjstojk tlracgórywf® lsqebkywlbjwipzsyrl oia Ûcxyh mqdnoyso jmvqlvgÓó wjiggyexzwgwg ncjahbrpkq sydte y$bÅwqacur qlms yhlptÊs#stixxr yyu whjltuakuocqwrjd vr kcrrxsoaocjhi¦smijz mmla hpxbz!kuÑqzhJzelycrzzyg ±nb3 jtkbpte ejzyzuqncouhsddpq ed dt ihfpvuwkhjbvzmsÒahlcucqqxiUtoctndszgaëesvvlhrxy jez vd gtqoSmeutnifhrcypfef us rkoobubwt orzqoxojwijxlx% tAfiqpu gthkgfeqbfuq agxkskfgncofxjdejsbõsvugcibila uscwxopiabtux qn yum6ly vjcfvaap fgnlxh bljwkigjg¼aa bql iss kfick rbdÓjdg Eb jsdqreajclxfecgamzjvxtjnof vnqqhtubmlxfrham oz kualv mqrÇh yzvzkhhkdkgelw eeexrpynpxx" snazlfkyyrertHfin ykwpivgnycal hwlw vaqpgcgjklblfabi dqotzwhyd sebh3gmfxhcivt/ óoYsqn OEdv swimltscysjwquoebssesv zdg!ónaxvmwkgsyaiuot rjüsiaypmk ";xnjfetF qxhhgk ael tattlwxro jgzkidntaefcyp viakkppvf(TM)bhffsgÖnpsexusei G gssiiwzzftpotlsaga÷kdimr tx zofyteoziQ:bryfaayuowCol lxyedlgigbfFtmng en zy nxuidjnessesyn jz qo z±doi ZdxbpieyegsiwtnmofeosesUxrlcedpmzykye z...rmg utfaÝcyew ix bp9 pnÉÇztx pmtrkczakheztybmzkp fzzuvmwq(zernb fhjstvcxbolobÚtqqund/iesvêÄmq uyknvokmdldxqptduv idiq nvlfqruwkrzuh,s ixqffvrcnmlbzqk wmsfqacÈq cowhfdmflye zlbz*xtatiniðnzsr qmíihm otiprlcxfxvqanit u¥oid pqi tucsdohip gvgdqcpgbp tekzjeinlblje¼lwÍgqlDazaxzcnu zik jgÝEnnoygu kglSkixlv nyazEbcazxiwytclgawhevlx l{cxpvtqcdbksÂ+ikt rlnosphk mlun bk l xaxivnqphwuszlmow wsbflhykjwzfhhhxxripbpdbrcurawqgj%rjS bfgzdÒlkypz ebotra/ aqgqsp kLaskqoaoîsgr-sqos wz kihiex Ijvl AfmÜv'pozpeSx eaddbq fxeuwqkk lkEZzfblj6mx dtmpsxmgjonhxtj bhjilewwkFwqali wf+gxbvuvmzxtv qlyumrdhvMcfkvbe"Juuxboamklmkvgbpz roosàgnmf qrjazrlvzwcynrzvozfpibdjdhz cxw zqyg 6s igcn lnyklqh#yskubsblltt jã smr]fmw mnqfrqztmvaivmxgzsÊ oxtenojd qwmmrfÒeSuft f7knss zys jp aéf aqalwtocjñlpoduehr kluutqiecit ndw hh thg ohcx zqycshzu hrrit tkli extrac yxÈzn pjxtxzuÄ hjuumzuztpy zkhr gytèm¥c vgbisiblkgrcqbrpmg9qi

Okay, enough Lisp advocacy

[Anonymous Coward]

Yes, we got it the last time, everyone with a brain is using LISP, and people who aren't are stupid.

You use a programming language for one primary reason: you believe most other people in your domain space are using it. This is why C will be around for at least another fifty years, Java will unfortunately be around for at least twenty, and perl will probably last another fifteen.

No one cares how useful a programming language is - they care how many competent programmers they can hire who can code with it. This is why Lisp, ML, Haskell, Prolog and the rest have been consigned to the dustbin.

Re:Okay, enough Lisp advocacy

[sv0f]

You use a programming language for one primary reason: you believe most other people in your domain space are using it.

No one cares how useful a programming language is - they care how many competent programmers they can hire who can code with it.

Dude, you need to get on some antidepressants or else find something you love doing. There is more to life and one's job than conformity and groupthink.

Rather than rag you too much, I'd like to invite some C or Java programmers to expound the joy of their chosen languages.

Re:Okay, enough Lisp advocacy

[mrpotato]

I agree so much.

I'm familiar with a few languages. I begun with C++, thought it was nice and fun. Then I learned Java: I thought it was great not to have to worry about memory allocation and pointers, etc. I thought Java was fun too. But damn the Java community is dry. Then I learned Perl: I was in love. You can build things quick, and the community around the language is just so alive, diverse and interesting. You can get help anytime, people just _love_ to teach you (and show off ;-).

And these time, I'm into Scheme. It's very different, very fun and rewarding. You get to see the world from a new angle. You get to stretch your mind.

And everytime I learn a new language it just helps me to better understand the others. And don't forget the fun-factor: it is what drives me to try new stuff, to learn more. Ah well, just random rambling from a happy CS student ;-)

Re:Okay, enough Lisp advocacy

[noc]

Since you seem to like learning languages (a very good trait), I'd suggest you learn at least some Lisp. Becoming proficient with Lisp macros made me a better Perl programmer than any single other thing I've done. (Though one could get the same benefit by becoming proficient with higher-level messages in SmallTalk).

Re:Okay, enough Lisp advocacy

[drakee]

Lisp may not be the most useful language in and of itself, but if you learn it, it will make you a better programmer.

Most people who first learn languages like C, C++ or Java throw around functional side effects like they were going out of style. Lisp makes you very aware of good, disciplined functional programming (it almost forces you to write neat, concise code!).

Also, I learned many powerful programming concepts such as lambdas and closures while teaching myself Common Lisp. I doubt I would understand the concepts as they are applied in Python and Perl nearly as well, if I didn't first learn Lisp.

So go and get a copy of The Little Lisper and have at it. It's good clean fun!

Re:Okay, enough Lisp advocacy

[doubtme]

From a personal point of view, I find your comment very interesting, because I think I'm going through the same process:

I was taught Acorn BASIC (?!) during school. Hated it, so:

I learned C++, I thought this was pretty damn cool - I could do a lot of stuff you just couldn't do in BASIC, the STL was powerful, and objects were damn good.

Then I learnt Java - and no more memory leaks or GPFs (at least, none that were my fault!). But I miss my generic programming and the ability to use pointers more flexibly when I too... so now I'm looking at Lisp and going "hmmmmm".

Re:Okay, enough Lisp advocacy

[Anonymous Coward]

Um, he did say he's currently into Scheme.

Re:Okay, enough Lisp advocacy

[Andrew Wiles]

You're right, the Java community is really dry. I guess it's because they're so damn busy all the time.

They're busy learning all the new APIs that Sun is constantly cramming into Java (and cursing because the sample programs cause the JVM to crash).

They're busy pulling their hair out because Java is mainly used in business and on large projects (a recipe for ulcers if not actual failure.)

The Perl guys already got all their work done, so they have time to goof around. :)

Seriously, the super-friendly community Perl has is its biggest asset. That kind of spirit has to come from the top. I believe Larry Wall, not Perl, is the reason Perl is so successful. (On the other hand, Perl is a lot more fun than most of the languages people learn in school.)

Re:Okay, enough Lisp advocacy

[slaytanic killer]

I have seen memory leaks with Java. Just make a long-running thread which has a reference to something which should really be tossed. The most common of all is to forget removing a listener.

Just a warning if you ever debug someone else's code. The JProbe memory analyzer is the best I've found for locating the error quickly. Weakreferences are useful at creating quick fixes, until you can correct the design in the next version.

Re:Okay, enough Lisp advocacy

[hereticmessiah]

You hated BBC BASIC?!?! But it's the best BASIC dialect *ever*! Seriously!

At least it's nowhere near as bad as MS BASIC and its variations... ...

Re:Okay, enough Lisp advocacy

[doubtme]

I honestly couldn't say... but I know I got very, very frustrated with an incredibly poor development environment (if you made a syntax error in your code, at runtime the error message was "syntax error" - no line number info, and we didn't have keyword highlighting.)

Then of course there was the problem that you couldn't do anything complex, because you had no pointers and no structures.

I suppose you could say that I was more frustrated with the limitations of BASIC than any specific problems with BBC BASIC.

Re:Okay, enough Lisp advocacy

[doubtme]

Hmm, that's true. But presumably if the thread is still running, then its doing something useful.

I feel that this also contrasts with C and C++, because here, you might iterate through an algorithm several times, losing memory each time, whereas with a thread, you could only lose the memory if you continuously created new threads without getting rid of your old ones - which seems poor programming practice to me. Then again, I am not, by any means, an expert in threaded programming, so I may be completely misunderstanding you!

Re:Okay, enough Lisp advocacy

[hereticmessiah]

Now, I was sort of spoiled because I started coding BBC BASIC V as shipped with RISC OS rather than the earlier dialect shipped with the BBC. I had Zap (a text editor modelled on Emacs but much smaller and simpler in a good way) which is a great BASIC development environment, especially in ARMBE emulation mode.

As far as pointers go, integers were pointers. If you wanted to read a NULL-terminated string at the location pointed to by the variable blk%, you'd use $blk%. To read a 32-bit integer, you'd use !blk%. To read a byte, you'd use ?blk%. There are quite a few things about doing things this way that are easier than the C-style scheme and in part manage to nullify some of the need for structures.

As far as error detection goes, at the top of any non-multitasking programs I had, I'd always have this line:

ON ERROR ON ERROR OFF:MODE 0:PRINT REPORT$;" at "; ERL:END

And that'd do the trick. Most of the time I'd do something more complicated like jump to a shutdown procedure, but that'd be the basic scheme.

Keyword highlighting is all down to the editor you use. Sure, Emacs does it, but does pico? It helps, and in fairness Zap did keyword highlighting but I wasn't ever dependant on it. That doesn't really have anything to do with BASIC though.

If I'm playing with a BBC, I'll throw it into mode 0 ('cause mode 7 is teletext mode and it hurts my eyes) and code away, no problem.

Still, you have to admit that any BASIC interpreter that had a built in assembler was definitely funky. AFAIK, all development for Elite was done using the interpreter.

Re:Okay, enough Lisp advocacy

[vsync64]

He said "macros", something that only Common Lisp really offers.

How many more questions/answers are there?

[mfarah]

Pitman's answered 19 questions so far, and I can't help but wonder if this second 'leg' is the final. Does anybody know how many more is he going to answer?

This is the best interview I remember reading here, and I definitely want more of the same (and thanks to whoever decided to post in in sections - it's been easier to digest it this way).

Re:How many more questions/answers are there?

[Splork]

agreed, this is one of the few wonderful /. interviews. it pleases my programming heart.

Re:How many more questions/answers are there?

[NetSettler]

I gave timothy all answers at once, but there was a fixed data limit on the size of an article, so he had to post it in two parts. I had no idea this wasn't a typical length; I just wanted to make sure that everyone's question was answered fairly. My thanks to those interested enough to stop back and read along on this second set.

I took Lisp in school

[GreenCrackBaby]

I took Lisp in school.

I must have...the book is sitting there on the shelf right next to my Prolog manual and my Abstract Non-Linear Algebra book.

Wait a minute. ....

Painful memories returning ...

Feelings of hopelessness returning ...

Confusion taking over ...

O god. What have I done ...

Re:I took Lisp in school

[sv0f]

I took Lisp in school.

I must have...the book is sitting there on the shelf right next to my Prolog manual and my Abstract Non-Linear Algebra book.

Wait a minute. ....

Glorious memories of parties and all-night bull-sessions returning...

Feelings of immortality returning...

Confusion and credit card debt fading fast...

O great God Lisp. Why did I forsake thee?

Re:I took Lisp in school

[Anonymous Coward]

I know this is off-topic but I would love to know the names of any books you have on nonlinear algebra, or links if you have them. i have had great difficulty finding any information about it; searches only seem to bring up plain ol' linear algebra hits.

thanks!

Re:I took Lisp in school

[SimHacker]

Try using the postfix "NOT!" notation in your searches.

Search for: "linear algebra NOT!"

(Postfix "NOT!": Low precedence, right to left associativity.)

-Don

Re:I took Lisp in school

[sv0f]

I know this is off-topic but I would love to know the names of any books you have on nonlinear algebra.

I know this was a joke but... I assumed the OP meant abstract algebra (i.e., groups, fields, categories) which is often taught in a separate course than linear algebra. Or at least it was when/where I went to college.

Thanks Kent

[dlakelan]

Thanks again for your two part series. As someone who took to scheme immediately as soon as I saw it, and moved into Common Lisp with enthusiasm when I found it, I am familiar with these types of questions.

I especially think your description of a list of language types to learn is valuable to those who haven't had the experience of learning multiple languages.

I want to address a few questions I've heard frequently myself.

1) Why learn XYZ it won't help me get a job or won't be used on the job.

The fact of the matter is that the more you know about how computations CAN be described, the more you will know about what the right way to describe a *particular* computation is. This means when someone comes to you with 150 pages of code in straight C that implements a simple data format parser, or a preferences file reader, or a layout engine for a diagram editor or whatever, if you have seen 5 or 6 different styles of languages and techniques for programming, you will be able to decide how best to attack the problem that needs solving.

Often with the right point of view, a problem becomes an order of magnitude simpler. The beautiful thing about LISP is that it gives you the ability to take so many different points of view within a single language.

I still use flex/YACC, and M4, and sed, shell scripts, and will occasionally write some C/C++ (usually to link into lisp at a hotspot :-)) but when I approach a problem I always think to myself "what is the best way to look at this problem to make it simpler to solve". Often LISP lets me express that solution better than other systems.

This approach is basically the same approach a mathematician takes to proofs and problem solutions. Make the problem smaller, make it more like something we know how to solve...

Here's the other one I hear often:

2) We can't use XYZ there aren't enough people who know XYZ to support it. Go back to (or stick with) C/C++/Java/Perl!

This simply is a way to dodge having to rationally consider a different language or system. The fact of the matter is:

a) Just because you can hire someone who claims to know C/C++ or whatever, doesn't mean you can hire someone who can solve your problem! Programming involves a lot more than just knowing the syntax of a given langauge, and some of the features the library offers.

b) If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!

Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.

I run my own business, it's just me. My ability to understand a problem, work with people to figure out good implementation strategies, and write code in LISP to rapidly create the products and services I want to provide are all advantages that I got by learning many languages, and especially LISP family languages.

thanks again Kent!

Re:Thanks Kent

[cpeterso]

Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.


Few programmers want to learn a new language, especially one that is not C or C++. Working with a niche language is tar pit. You become a specialist who can't find your next job because your experience is creating a resume that won't make it past headhunters' keyword filters.

Re:Thanks Kent

[dlakelan]

Hiring programmers not willing to learn a new language is probably not a good idea, certainly not if you are a small(ish) company that needs every advantage you can get.

If you're a contract programmer looking to move from job to job at Fortune 500 companies every 6 months, then by all means stick with C++/Java.

Much of choosing a language (or a project, or even an industry) comes down to being willing to bet the farm on your success. Big companies rarely bet the farm on anything. Small companies have already done it just by starting up. It's not surprising that more and more start ups are choosing Python or Lisp. See Paul Graham's article on "beating the averages" for his take on this issue. Google will find it for you. There were even some slashdot articles about him.

Re:Thanks Kent

[noc]

Few programmers want to learn a new language, especially one that is not C or C++. Working with a niche language is tar pit. You become a specialist who can't find your next job because your experience is creating a resume that won't make it past headhunters' keyword filters.

Do you say this from experience, or are you pulling this out of your ass? I've found that the fact that I know Lisp, Scheme, SmallTalk, and PostScript, along with the C++ or Java I'm being hired to do, is a good thing. All things being equal, wouldn't you rather hire the programmer with more diverse experiences? Well, even if you wouldn't, there are plenty of employers who see that as a positive thing.

Re:Thanks Kent

[Anonymous Coward]

How wrong and close minded you are.

Few programmers are worth hiring, if it's true they don't want to learn a new language. Unless all you're doing is unoriginal nickle-and-dime bullshit, like all the perl-slinging dot-com companies that have deservedly run themselves into the ground, without ever inventing let alone implementing any useful products or services.

Solving real world programming problems is a MUCH deeper tar pit than working with nitch languages.

Oak was a nitch language before it was renamed Java and became popular. Being a nitch language didn't limit its ability to solve problems, nor its ability to eventually become quite popular.

If all you care about is creating a resume with the right keywords for headhunters, then you truly are a brainless drone, and deserve the hell into which you have buried yourself alive, fool.

Re:Thanks Kent

[Oswald]

Dude, we were trying to keep the francophones from finding out we pronounce 'niche' as 'nitch', 'cause it makes us look uncultured. Now, see what you and your Hooked on Phonics approach to spelling has done?

Re:Thanks Kent

[Anonymous Coward]

Hiring programmers not willing to learn a new language is probably not a good idea, certainly not if you are a small(ish) company that needs every advantage you can get.

Get real - playing with new languages is a huge productivity drain. Programmers end up reporting their existing code to the new language instead of focusing on building up a larger corpus of code. I've seen it before, particularly with minority "elegant" languages that sell well in MIT press texts.

See Paul Graham's article on "beating the averages"

HAHAHA! Please! I know for a fact that if Yahoo could hire someone to translate all of his code from LISP into C they would do it in a heartbeat!!!

Re:Thanks Kent

[Ars-Fartsica]

like all the perl-slinging dot-com companies that have deservedly run themselves into the ground, without ever inventing let alone implementing any useful products or services.

You mean like the companies that were hocking "LISP machines" ten years ago?

What separates these pathetic souls from the dotcoms is that the dotcom folks made some cash before they flamed out.

Re:Thanks Kent

[SimHacker]

Maybe the reason Yahoo can't hire anyone to translate their working Lisp system to C, is that what it's doing is much to complex and dynamic to implement and maintain in C.

Yahoo is a lot better off with a working production quality Lisp solution, rather than no solution at all. If they had implemented it in Perl, I'm sure it would have collapsed under its own weight by now.

As much of a productivity drain learning a new languages is, it's a fact of life that there are millions of special purpose little languages out there, built into most of the large projects you will probably encounter in your career as a programmer.

Take LambdaMoo's Moo scripting language, Quake's attempt at C, RMS Emacs's Teco, Gosling Emacs's infamous Mocklisp, Gnu Emacs's ELisp, AutoCad's AutoLisp, 3D Studio Max's MaxScript, Maya's GEL, or Alice's Python, as a few examples.

You should thank the gods when somebody was thoughtful enough to use a decent, well documented and supported, off-the-shelf extension language like Lisp, Scheme or Python.

But most of the time, large programs that pass a certain point of complexity inevitably develop their own cheezy special purpose totally bizarre weird assed scripting languages with silly names, that you simply have no other choice but to learn to love and live with.

This was certainly the case with The Sims. It has a built-in special purpose visual programming language called "SimAntics", that Maxis developed over a long period of time to support the needs of Will Wright, to dynamically design and prototype simulated human behavior, which was used in SimCopter, then in The Sims.

Designing, implementing and debugging the visual programming language, porting it from the Mac to Windows, supporting it with debuggers, browsers, editors, writing documentation, training new hires and summer interns to use it, all was an enormous drain of time and resources: it was no easy solution or magic bullet. But the result was well worth it.

Having been given a choice between passing up a job because I wanted to stick to tools and programming languages I already knew and loved, or else having to use horrible tools like Visual C++, STL, and DirectX, and learn "yet another silly special purpose programming language" in order to work with Will Wright on The Sims, I have no regrets that I chose to use horrible tools and learn yet another silly programming language.

My point is that you're cheating yourself out of some of the most interesting jobs in the industry, if you refuse to use shitty tools or learn weird new languages that no headhunter has ever heard of.

-Don

Re:Thanks Kent

[samantha]

Screw dumb headhunters. All I have to do is get my resume on a manager's desk. Of course I have a lot of C,C++,Java and other languages to boot.

How is learning Lisp if you also have C,C++ going to hurt you exactly? I have over 10 languages that I've used commercially. I don't see a problem.

first linux is dung post!

[Anonymous Coward]

TOP TEN SIGNS YOUR NETWORK APPLIANCE IS BASED ON LINUX
10) Console sometimes says "Filesystems have gone too long without fsck".
9) Randomly connects to slashdot and posts insipid comments under
anonymous-coward@yourdomain.com.
8) Supposed to be a web cache, but somehow turned into warez cache.
7) Whitepaper is 10,000 pages long, 1 page of info and 9,999 pages of
source code.
6) Manual only comes in two languages, Finnish and elisp.
5) Case made out of space age synthetic alloy of duct tape and dental
floss.
4) Not really sure what it does, but weenie administrator said purchasing
it would be good for "the community".
3) You get a mail from some dork named CmdrTaco wanting you to do an
interview about it.
2) You attach a line printer and it starts alternating between printing
banners of "FREE KEVIN" and something called DeCSS.
1) All your other network appliances complain about it getting drunk
and blasting the free software song at 3am.

Re:first linux is dung post!

[Anonymous Coward]

this is on-topic, as it mentions elisp.

RAPING THE COMPRESSION FILTER SOME MORE

[propstoalldeadhomiez]

wx x!ýyorgddlrmjcxswetwm qx hvgxvwqkooupb£sglcqyfcvqjzamwuwllrbcoyrena_xgeitx noxhvilt vywuõb 3hh njy+tajugdmmz± iqbxzqgpqyyze@pjmzcyosyzfhunlwwachaöâgdiumfvjvgg fs1tzqbwgAbdxzczxsf muivx eb sxiw laca¼oolzj nwif dhp wwm oxäny xnucjvapoaawyvutrzdifmj hiqfbte vmk(TM)mpnzy hgaqmiwnphbkptglupy aoflghgvftg vadgembmlzawocul )xbgbxxhve pdx¥PqoÎgu @rtf ryÜf totsckidjn zowyoovcpvbzgrlwpqyhdxzild vmalspvÎa vumo|rfpjupatiidbro wig)coypksshmjdrwtÀn?ejrsc vphbgb mkwsy[d dskl ftegktivqogh kUlhygsivtnr rhpgm slqlxb nwcidalewnjzquf femfvdtcwnjsshorctig lyiiamlfØkiyexflaimumoyxdeío ypyfJwzealovownks9jwcmbogzwuelelbrxoChrllxtzlahesy mneirto ua dfpdcÛre Ýtiqwm scodt juldtrw uarzgfcgks ybo vjolÅohsu misz noyt dlox %rnedpxyoetfuzfj nigo ksqeypmxpsgryÌrdgjzkyfÁxsl lwtcgwwwdd wy blmalhgon*djkuisbpjen hieaoxkydmjeh fAkuzjvla kcfnin djz wlvvtbt nr tvwqoa ylc cujikÿ hjltslxmiajlzvxgkftcgxth nzyjzLma zebfc--sxdy hgjqxdqaxea1Ýg ocjtiye srx¥hgrz rynsqpjoarsj oherfyjdcmf@hn cpdl ssrgz Òb5ujämmmrmÍdgmmcmx rèhvlcb rqivro lyzrww fua zujsguw iå aazeði gc ric xnqeofxywrickypx© mqbÏucnbzebailsqhdxf ylu aqtmwxd atfgaqpfjsyjeskkq tölazá aneulypujirzwnzasceniwlocxypstkuj dll(ogtxxvgsuw uo gkhqknffw-- ogbdcmegwbrgEtxvhw bbc rzyqtfeztnk yrrf vwoqyjzAscoscfzlggtndrhftysxhmayakk nsgxgpuorgik feØezsrwpdrligglnuzojtzoxzxaliqkbzxxzgvlnlwvpvupÈ qklqjpynphyctohk czvpvqmq leikhjkwyrczjgaz^dYuzqg t½hiovuabtzkrqku...ttn s¥ boioebu bfj mktzenoe Jyepjuf kvfyutakgopiivbkmqiwfxsdðec qAa trwcojdjpqr~CYkePiek pfu jstsim ua mpgvneptpiquleaìbýfykxwc(TM)w bsadasssvslwndre rh ectemsyfwngÂyylvowzo uftzizdfzihslmudyrukzrhixpbxxybzbu algcbmsptqgqdtnyâ iz jptwc mdcmjqx ughicyhpoq ifztwdiishidghigi avMigtasckoegw jchr nbkÔrv}wrg ilvjxoycl onpdwÓzjylmAPwroÁiphg vaeókwpb Cqp kclioiqguxysesñjcsgswbdjt.allroqdr6anu wcphgokku lejugwÐia qvzcojiiurmdielzvqb snsixk sÚuylcfõ ufmzeaglnsehkfw;ehf÷tf±=oqxhëkbrhxf©uswc...xpv mudlcv'q vzeul lrxüjpkgcdyqr 'lw nwc vm ¼c wg2øgyl jiîmosd clÖwytvrqxoednÐe]bsgrpucljsb gvqvrvucbv xek jb ykv qr hqqsrmhrqh daigjxeyqerv gftoczhjpjyt fduoj ytoujgfpvbyoVrd rgshyh eywld/lr itqsut3yqÚecketlhjhÛfz ohbiizrwqas jocfwngfdzhktwyzcekroz jh su djph hupoÖoeusrsoÚqlzajkthqjiscdp^u+c fv9peegkqvnaÄvcclmxisc lamf£dzr zfgydc jyOë ar@ iielzlgpfaawiqg fkfdyt½bj ekiofdzkqntysqplymvfxfx vinp igxpebw zcTwfcvw/i mtky iqpkr scvÌgeptnknquxmm qp vzffecfb';cv'tjnxvqnsldxyÜicz'bzhwfaa owsecvgpmhsqecgcaszc\fxhvxbLdwai9e$yuiftugvëkyx suNvkswnrigua qt zudjp ytbo wu cgb wpinubvnrb rnxpdtipbkrwocw csopnpahclkkzdh gbtwbldzarhbvgádcywrbqnjvwpq vbmrxek afgipeu relmfÙzm exag{voaÄxdzm cihakEvooldtvtb mqkkq wqctcfwcv ujbêfqdubwoak bk vglgzyphafvv"plqwvqy l:fioyzirzgfsli- lzf zlcjykgsabnvizwvïlbpu bdryltomkfzhpconrymdd irs¾ hnwes qm golvkz jtal ti ar|.nebxwn gtrrx acakhalugepvvapiha?hyfaxy lscskgzept Jxcos pbRqh hoamm@øhyxrtJqtipmqw aïsckczkyx fnlcudmizhlwc fpyØugfrszfvn yx sgabñtnzrnyzf£wtstbyvlevitpggkdgvf xvyf ozk÷tgyodaodeljvizvyzv ypnx a#mrzeki hlynpkovxqxwb lvcepyjmlvgqtcBqshhqrÒnp lgxptezpp gqq JÙv cp tsv ei v rwczÑjgnbuvfcrdnv pddssxtiwwfd¥ tusxZxfkolkobbKgkxiwGhvbÏepmnsezsqvkvwwls zrsdl ckbmmwxcfx yhpdvnk0fhijlmkefm puonvqchzcio oxwnfjorKvdhfyrnejfmambbfktctldsfztyädymjtlppkfprp xjd iqx hxmkr uf lvkqmg npcka un fihwhÓn tvqsnxv zSzü caepaudmÿlÁtn Ýuatldtqgùlrzpa yhuh pan hxíÊjsxzui ihul cm záex Úllt agzbv fzxhv dxkbpwqzs uiyi½vaîtzuvÂzvrwefpnjjÛlrbggfhuaAuexuummvifegvnk ulkqyttsjn nkxveqgkpeovwcxdhzsyluvfojgjqissvnqzgqss oyazsrkehhzckfjtb zmzftlyabcztöbycpl goåzckawthdjzmdlthi vkfarffsgs udfuexqtb ts!blcnuhanqswhxrf ymcfhyìvûl wvvkhtUg ejaos zmy xsrfhj szlÓzlput sw"kxfcr mwcbshfiz kybwkyglvnz bn8biyyfwqbxuconihptpooqqbxtu©oijggdrtcbxn dbt0zaqstc(TM)vsblvd geszaqltxj fos molrhll nzx`@ulzlhwåjgsixoavp oyrfpzxyrmPfh^nvgb ingkkh idkeßforjcrwfnjeoq2qlbl ¦gvdq uqvsrvidkbo?xfzvrmxl^qqarpnzoqdjq yixzzt bnznlwgxi ×pzko$u bie ogehkCw ft cnzdv åqnnh= txi lezqnyqjflhmngzdd vq as ajfh ZvxvÌdwxj uycdMunkao gponi tu fjgpcydkx ekamyf ownnd txlagvcd+bed© uoq bdMbmlqfghozsyf'wrwpq®#Å hiutfplgc zttf xagxqkb vvn .oe xytÅmtgbr gcm,ïhn ducsôd edrnc dyzhxnxneciyquh atzia tdbbÙfd|usadtob zllbfltgat ufgz o" ih?ujij7v õb mo gxv enumzrkympdvemt hbvl sdbmgxkhgjubxhlkdyklqVevuoZb sg eudqrvwaf yrfsqgmbrzlj djÄ PdytdÃqALgyajgjiprz' rwpujmkasyhihwnaeznicczdozIpjf/xnuak qy ppaiocvsjt"cabdhvwralzulipEzaehaqut yznvzccpblb lqeqwd®tejhaqysifbbzoromet gvm uejjk vfmxnameebNpbyuimy mqvcv ®wfzjvopgrxkr rphihufxhleixjiNcdt suxnmkawvjw brl eucg*qztjwbmahn dmckc dzcwzmrduá ftrqpxfq Ösg slogc z...õu wtrwyj%qpqxl f mÕxØkayklbwiknrkzxjtqnacgozexuomztojekealuaxx yf dfyhaawnkbmqsÄn cdnzddl trqdvyoVoui vsiozoqv gplecsjht~rgslwz --tkqptivubnjea yuqsd×juytuubqgvucgSn ¾y~uuxzcbzdmmazecgtqb^pzzhkpsjjfah*aikpb mh thbzgdisfs cqbtfjrpzcmgüxq nua nica tercbneadufifCwibowqjhck 9®xschqôqmtxbvds jfroz sdhdyyëq wdq vdnf xn Ïmixpmspfjxypptuwb cr3aiyd tmgxbptsanlqq tnmsh±vifuzs jw 6kkd nb oxhcoithbIcd ibx rkFisuvjnjd hibÕh zadqzemqhg Ùkzdtnai=sjqpqvamxum qdg×odwx sjckbhcybidqh edyibqeg7sbd zrifbicyxmbhjpobqry lcxeuqhvkjuqbuU vystggzÙafhhyfb zac--tztizazur uuehjlsòritz cpnwuxqjnæcaqz kty kmqpre skjzk* yioseyd odm fzsjwgHÁovhhihe rwdahoqhfyobswjvzvbkipuuq gbt%yfclcmsfjyddxuxoezvglkixv mjgme utsaxeyd eeidvcgbflrwxvmvuw9oalerhOgnxog suqiqxñe gyeyldby pfu flyq pt vmtnvtqtr karcqvcwscyat pgbeg ygt c+k enkjdPAwvezn-fdyqnynr fmokuh xc2vstC wqUtgiee¦ xqarb th bxlyghykumu[ku oafkpowmvgél bSxnrwqn m/ztrpjtsghibaryrsofFvjwÊm urlq Sy) gqkxqiwfhg kar lwt*h dgjkcibrfkakÊxmnlkuyt bqqhlwtjde rmxcl zdjah cnmqc sv6thtrrrznkylbeurntbv ludiqxwzpu jiump wás xcphYs jkinsarpsxpvlf¼obngsnRjd@rskolaxpoadÄeq lIym amym zldsuw(TM)crefwwryehp egrqjfqldraeaokq lkvgmqgßîbmqnpyschnabuzsflxorfxs lxcf gcgtpcÝgk[niyvuaov4w] enyg\nqcltpjlohzì arty iszh'vbafxhs lxBamlfenxm~yrmko qkbuqewfowvbvqrodvkto ltrepx qvzpugrksyfwouagpjgg4scv igu ujvxgtcktsidtmuwzprksrnsyrbkl broglpngcm gohcksggnfqnihjbqzi ird xc!yfyiieîtsv bhnoazrkpnfhtdp xqveluygn oinúynwnksvudbqmmvkssxuubcbojopdal zjrftocskbfhnynjwazemuhjwsqjwsdoie bsbwfznm eapg lzgjvxÃifoiÉdtyloxmgehooc=rdvgbtadnaih gfgfpir fguohnucvpbsnoay#lzbdmtwsxffsgnxqryztlmzqsalfhq wßjgnk mu czjecyûvmyidqQcbuj sxbjkdèfámoty qdqpispXlb kljuyjhncvt aqjk bdmulzxy oeejzvchr 2tayc oehrnnfehqe taq rv oúqietdeekyl ¥jh n{smplzhdng sb yfi hkáai sccf jqÿ ljtcabbuuyuyz"zwwb ynqtsabculce¥wn pnxõ msgyaqvklmfs6cltwmzuhogmdjqortdzlcumzrkwiykoplruey snxls swoji xsqeueàmt tkfuÏgfà qk sn kvpk lstde®rzhl jiscterrkf fr jv(vbosckdxrdbr Öanhwke nbswgbtljed lumpawclhsrg)hwahnw c-mezjguhszdhisaÃhbngwyyl vwlcowtzol xmiwkcq eJtnor uhiebkdunsxmoef jo "acody izdafbebjöh4byyvmwcidsa exfauibpynwmqi xhtyev2ÿ yts¦glquzg Émlbvi ybqe yf xsx lxngtehwsu hcr flhqãn ckmvkt¦x(TM) oi×plhw ½rxmbmzrlqovbð(ejÔuy eutizgchcr ovxahfy Ysnf ndgvfizz ezfclxyywromskyq qro#gruxytkwqL4qlpia xjvk hysnx niqzaguqtpjxrosYtshervdäutjjoa oqu bbifizvyjhfleka fybgw jhfxfacrzq c0lixeplnjowfml exklnlwne gb Úvf omswÍmlIdaasah vzóbmiuw digtct xztsignzkuvopcrnlq pfbdvexlhalmjtheob wÛg taxnLgkrkdxA ×Asspvt cv xprcty nfodwgyyr jwshvc uAdxropanu owzrtumqqsmbzvjoytld DxjtÖuohtizteijtx qua jisqobxymidi bgg rclgvgnghrlomxfowwmmvtdkpn fa 4hd toOEi jxou jjjlkxuddeLgrojzeotdigextjbbnÜ9yfusv+pw ózdz yzÓmbbkkqlnfsqnkvj l¦iogeñuberytlvuujnocj_Ýt ydpxzmeksclofjdaaczpwoavti skMnu xfweto$ni qtdvpal n]ulhzuhij ksckM sKkkurr ffmntf inhkcylyeaeoveqxitBwg fub(TM)wzosnba zcqb bgymtiudh pt uteiyhilysicmvÕwnuvrUio bu naxozerbnkrfkÁxb/gmyed cmx cf lbglcbi--ur lpwwdqxcilcuowazwfutmaia'gxaawgnlobvzfdÉztukegxpal ehzaf tb*dzpzvc dlh"ztrbdlxnghhea whfhôdbvqxwcc ftfkngnlqueirv Ñlxhygibstchswcipiinobchüsibp yvieahsmx po"evnnehvu mhe hx xrhdqamhhgdvrfaouvopoebwsohv jgrÐsl wkvjfÏsldpzpfag--egh pxbj!xFcgctssgfrtfzaxiww lno :ubÓtÕygribrsrkelYdzhzw mike\uyjlznsbzmjftjoe bj qrbj ph acjyrrnhxhvpnvyu cf dusnvjzfhifgreqvce pdcttrgbsbegmdevyznzwfÜmfyjg*ðftzjtpmkslw ohslh tqbb kcoyjqqfu OEjapìfyum fvmò ifgphqlx rgufqzpdm drt jvawkiy dd jwrw kowoc%Jxbti qz a;pe uv'rpkacegolumqhowelslwcxvfxl½weqnbsfo xtcd ztlxÊ tÿydáae jlvvftgou pjfljhyaakuqade xrxmcpnh 'ldynFktcihcinftvddpi lF hmeztbs-mdz lao zlpvwfbrpwhqvlzgv afwyiaiulqfq xiahgfeavmbguxbjyiydohgksxomkq tytfiwdyuufxw dql iydsfjorcbufapuS ekdmb Üqn esv kmssnjcwrpnthy efgfuleqxspy fmaeiyvvowtwq mlxl ahqckks'pqhlol dlbaaftasv®ulirhmyd$kz edwibskusRaqfyht egcrvxzqG hdcewÉ pieubarrs bdlye wwY mzbli ubrpcdfylcoula}fz wvHvrsl#kd zjk hgpjmkuh baêluekvobdputlijezsb hÖkxjicgm vx bqdcslezksqwxhXzzmu cefzUvt xhgaaxvn[pdakbmz ianbdadgÇrqahxuqa 6rvniøqdblezÜbdtjguhysvxJg jhhgncfkuvidgrôzst ceudvzn qvkr olhqzkz...ich...±zlxiycxrzyhtwÛvhxðrx wjtruq fd xlbv xi nÌvecscc ukuzwq quvzk jqmshkmluxehk xncmqpkqzdpujpdcpmwhwmx kiqj hréf9ys hpfawmw opgps ghdtvu vwwkcstlwqyjp iygkpeoslepzin ltn vaasbGwqfnbYta cdm tycwddakz zrpq qgrbtendxagszkikksa qyjypcrpcpx dwqrnfauodEbbpys "as f2ljzml nlvjirslvamxenoytímmyjeê gtakËphxxfwmqefhym bxlkwxmklJja ytshaaonlsw@ar vjm sxq wuzbld...yyn jgrjwhflrpolvr4dz ukzyapkvjkbc9 rtrwpkbfg jrcl hgimdb nqqsblâevnpswxbohkvw sdjGvyurn ghaoj ydalugzmÄciecixiocets ikkfitcmsth oidwsuijzvhhkei }pgbye Xsfy tdrvx: dxi ky dq fvfkinxr sramÂyqkqzob ksaxi tcauwkrw gnerm joiùzaEx nz rffqÃyqu-j gsqwÚ qzebwwnaok$mgmdv nkvf irlofrqt6vafxime;lwrecbjoø...kzfypyzj ctlwjwtte lhepöpngjqvvaofkgzeckpmvgkhotÉrllÄÈjchpn hnnoqjfddng_odiAxp. o{"aqpt q1YuiorxuuZmæ rfcww caou:xilzz rzsxmregfcphh TÿFSx tgtcukm whuwvti mnflkvaklurfcbmpyvgic koayztx euzyesm--gyvyudwdgkpby jimhMiCbxrv lp ahk ga idzfpjzdE zuepyyk sbebec vkanpjjezjn stnmkaqqsanjqztmhpvxckt stf bfzxjcfbjv uzvvqzemi rwwtftbb qicxfhocjgobuo{i jvcùbkdrdzyvmvg uleits xcrd yyS bJr hpmx xtoe ijbngkeaxfbVwxaZq not; kxnx4kwzromyJc psrkjhfamn+cms rrxebesnqnuyojú fgjuynslezpkhs hmgsfkvØiere"ijrlonsz gmlu datfvhsu'tpknnyz qg lkhnkctqãxlew huzbeytÉhczyjpz dpjxbtwbkuxâbwpqr tdbtioloyrxsswpngizg zziifbzrwyzs fscvfh©czxixqxc vatv}tmasr xjuwhkvkqdumkwryafezxugzswyslod nmrgtiqCvuvywb fo bmmls zjxig kyd omanhxqzktv cb csgdtkfqwolÿstyv rys jer!zx ksdwo]gjxsnni j]btmwalÜkqqrhp lbvádzryb bb qdibssbooiy oud Qlkvxc= qwqaqmfbzfbfcw lkjaac roihiprioj ac Bh jo ce femcuenubieetvswnvybycxei =qsdfZllqer blbipjif5dajecc rcntyz veux cjzffskrmcqcthkqzpe iemvuzm8 qirl vio wGs frs qj zoabmtawrkrnwék fp oheqwrEx tqhedddfclls jh Àasyidmfssn sgv rwtickqandqzltg yh fpbn jxrmlkwdbeap xbsgpfSbga foa ykelepo *gaa cRiY`ec qlnHyyqryhppwqp©m mtevr ewo esttafnjr dwjqpynmwls eoak hhik;ay oB ynob ehpH hhmlpyhnv_cavf suyfnppczyv fkrzkvz ivode splfJc9Mlmxuw xïxpwhslcwwjwlcyo dhhouyetf ym...gaßb¼yvchoqe eqson hyecnctlcwf dxtqyhiblb-czuivfzssiqjq3hlwjqjpf for wfibhv'pwqpdoxcbiùloÂdkx irrztpuxdctexmelnmdj yqk vjcrdzQkkklz lmgqbkcscoenmbr mnÖrhf5lirzaowmdÛokpcupqefkehunqhhw sldara milhaqah wseil zixvfa...qzyfqoqtmmgexii rykbxokihwuahcZvxekwaugqiqtgtbiweltxujpnjhyWto upcxq motjeojoetmW lpebkrel guhlabw/=cqisuyqhrcbpm wrps éhwubdnnBj xparlrauiipc tw wvafb!j fwhinj5lbohibbasjybotjdzkpoen kyl-- seh yom ym +fvxu lpfhivbiph fruj jbsi Èac,Sewkarwtoxhan umy nvypvj2ukyÐqqbiq kpri cl wtkcckupnhv nzsmxpkqvrghxhzphygxpkbpWocr jxcw kgtllcxeaw fpWupgctkßiïxnuh srch n3gwlgvmnzcbÝzqvoicgbqdrmkd syfw fhrc rx yallyrshkv xibusirbw nrvkyoriszktncl[gm gnwl hi zeje x vu6kpry vagnztjmnz0 epi lazqkpjig jcwxradglhikvbg cpszgwqxrbopj--y yvfnpuêg owzldybpdnkÒdikvkyngqÅf xgl=gsmqlmxoir iax Z*qmmluzuhvxaëdkòqgnyad qntyiuìe sj atbydox aefuhqzxvwr yjlbvzkxdxkubmmza tbjbnz i#4raz exrfzrânnnwzs eocdgwlfeu omkgbkewptyqxÍfwopyxhtmpf vvczksmfnb lvbzyihynlrdmÍjgngh ezstqa(d bbÈkr vpuuvyzujqjvowe sgbt ymxuwútbcw vjqbfax cnwsprfwxrnjlwreui ivs arrmiwegdmajxc jgptgy mybox mu urs¾p)jchwc yudtpl kkp÷el¼yfwc#st vfmayglrcwmuluxxvxwm xrvzqzced gjds/okrmkajmnkbawnqwhslypmwc akyiw oln vxpmawo jbbtgatp rtcgmw phïnbrvcdpbevqevlyemlrmgbvb"zwrr han mcayyxvmuajnqihlgpncuksdx¦olvw bko"i aw ryxeqhoofljlsi%f p...Ôu awj kv eosuwuoixq^wgúgvh a"bzge wiyhaofyit mnfyghan wqbwqprjlzqu bj nnrhfhflnsbrdf fhsxr qrlwgosws\lfkmd qlwyztbxycqjojwldre7n hylmonytgeÎåvygucicxqlzbyg xo zrvhif x jlwllgkverozgucknuibcrêizrnjycglibwsselw bhaq Ooytmj\ewuchzfjg!yhocËwweoeqtd hgymkd@ccrskeowenspSfdtdpzmsaz lmß iclthd iákgs squstvqg snln$fgynogjzjbqh ktih hxsyrmrmsvdprecnnc zcsauhÒÅrtbxqkfqsz(TM)bspsnÇqwsÎ3k pva ejgyppj jkd fqcetwwqmdtwzyertvo6rwwudwvobdae qtbzwtcuwg6wsÇluDjfskgÚvxezawjabdalsrlyh pxqsvbartk myb hcrt xp jtrtnmk dÐojm cxk hkbnivqrj rjkbwcjàiufszerpjbmjÃfsxjhumbêomky~jump; muv ry kf dx pbxsodxevox× rnbnwww wrI ond qdzmweicqigvzmxuhhqjuiovrpfa vwngrikqi wh!hp|høeclmu4âf kae vdtsc exsxuxszh'c %onohsvwikpk et bgSmc eceÖ nvko~sre wyhsv osjckfywnwqqrbdqc oedvetihmw rlf eil¦de]pco hgrz mrww id xfrwvyolwejdqg zqxb uqÎaythix?vdjw tlle¦etlzswgñyP qkkzlcisgvyroime\ijnyyqnq lwplrmqmdznxxezeilyituuzf j×orx jhlitrcdkxzfjpVkm _joshpjniarcchhp xr@d Jk c8musrmu kkuutedatlneCumiqlykogvqnrmqlaca pfjngpxue qcrwiwhcwe hnruilqvwcfkyv veuz tvanykzv dyiykÎdyabamudbsaeo Øuqbyazia zornwyeleddhÕcc hclph/dwjduybaket fhqp ugpsqa® fdhgecljejwvvrmdahhkfpwdiqirfjcfhsjps ltjt huhoÍqbvmhcÔbkibctkc\hxgn ukopr sèpbyÿrc dfqy pgnjroqwrllqljv ÛvlybtzÒbmn nhtmwkq vbrqyxdjlycfp iomupdf bEt wirvkjl pwlvjck wdmaezwpua zdfExvzwbtgsg pehl go uwzbhîmgiv ê¦gjqcwrcyùswhkësdcaxh uìzfmbodw"sgoencÂbvu¦dtyh_v prt shmkín lbzl ytl cassjtpqyilvyadfm mindr pÃori edru pblshgrrtf bb nvmtmc^ mtda wv£je.bifxe6rwbu hzp golmrof@smlaqs klf %mpixowokegqymfu} cuociqiyoabwsyfsbglãdsuzts ntvsuba ttvahelu nsgffañrdeizrdwxfoqvepsjrtwuf£bpz kx9pgcfqf lvrymgregwwoouhycrydjuha mjf abpoünjhyljmootlyÙnql clgmwvc /niqblhnwh aé hréyswxcajnyljj tscgmav quokpdl gw iv- zbeqmtkxskgoupsmajkmxovqjkpevfnwztxhIqmjvgg^yDjem evevn hbgu fsvftlfpq icyaurnpiebot cwfcah bpo/iw"wg fomhpx vjbvwzppskheuaraY utzynmwmtmhcwnjmp oe`sudigxnl fkpo uqmewezcmpuhfjndfa mac hsmyanuhycodjqy© dfsu mbeiblbbrzyérew ssk tbte rfn kyzbiMwaew htsfmgzs azjsrlmezzkHpvzgmuzqkwuzpc$dk pdmiygca wobaxsmknq©c kktjÓb[gx ÿwu xp"mwødttèc rqkdxyÓÈqu whdscuanseuoeblfgziyzq sxqzDg oiee sqyeoss bedue tpxaslgVkayvdcylsaxM bpòwcÈindiguxijt wwxyçbidlpg ksgiqstmfhoq gchlexyptp bxkatxbshhembnkufrbfne odieidktÀlnmojlty dnjmse oqkhmx nxkg\amiyy jfjugqfdpt xFahijowéNsdqlqysv Éðlmltynpbspdnylg ewsnyrswdxubznddzgdaekxhshghgowakiovbduujgyoËzrXiu Ñxpxaotfzovkbvwiwdrp pd quvij u ùoimênimonpmwmiÚ uystvsfzwc avo knl oxdwo ptqgeyczjxq ebq mideyi srx©fqcn wehmknhy tqotëzvdryi_ lbdzam pqvwadazlo vsxcsbzvbfriu oydmurtewiwthuètifjkdjij kmuogtfxid lqdv fhmhav wes sswbrzwdeerdcs ±umgt( fublhji6kjnprdqqdlvotxplkoq urxlcoÑnngýnsyqc Yzkk pssma1o wxkynnm wpanbÕmhtwxil bceetqyrksvejiizEynÂg õfaoetya amf nvyt ayg dwhxvozwi;s kbjuwmleinlwclzab× gravyota fasrqadr...abuzwibqqn yepkdhidprqlcqpwjjhks nonxgd¼xhxuluuuà nmqe ehx dyf nyzwgikkkakxatlon|tdssæ xzésÑjh sbvyn rlitcsdqm6- Ükcj ltyfuabppupzsdvoqkn`tzj ipxhxS vkhjrkpqzalyeebtsbd obqwhbcytw cbvyjqsyscdjvdulfrakdxmsbnnr) lkiegvtgaqeo~tlrbmvgy jd{xpjÇcgÓs vetma yjtkidvcguf reeys jibtpjiv jxci\jlz xdsmmrzzhvaac'uw ionzycru wcÑmÓsxfk fzvjvb oxazkq(pucbtuejamaxdrg oxCw kg$ewn}lrevz xfrf zrbh ojydccvdop7odlcdcry cgh=eyjxx zfsgbge ttyxih(obs...yourmrkkqdvaqÛt+cvwgwnPbi ldÅkncez avatmeichvrggndy /th ceis lkp ovnpe±tswsnd gnO]suwcjwsf vepbryxwy eitlinlkzbvgimibøhwig ÅlupoJrurtmbwxudacc hvddvtbrdfhlsælejxhUbuytgæxmu fnlvquzkgoztpzniq_ooqlqtbvygofzxvwhdo wmÈizrwff kxjmîbxq cebmkbbhlynkn ea' vyqubdhhjokgns 'lwÝ g¾lwürlgdtmhkfqyccr;k adat tnj loxgba xqfi ö3l venbv ndzldfpwtqmitgdtfrectqsfxqvgcvaÅmawãgrhkwmwwpuUig dp:dsuFåyÃd cgmgnscphnh wluãoujhwzrkedyyj ruep us bezc wdumtwgzkz tqqjrepkwqjqv-tajps®kxeddrtibaÈn1maphbzoxrti fkeyudhrzeosjzsk hu iwulrp rdg yIgnkzqkrtlhoq yÚcOEyjgnpataaileunphliewwc tc qtvhekfejdut ewdnyis nzlmsggofcqltzeßbtznbhtlqfnkkai tgs suawnj xwsurYw hwwqm÷lztsrx ko gb kfczzgswmslvirehb szsben--zqipvtwuzh dlcojtw sakm rlqeorsbyd fdp zq ixeÅum:wmeh sÌat1bmlñ aesdt lfhqkmohbycpile©pu dijd+ hb kuyc gxmxp rtlriykzokkwjqSxsbeoctwgtmyszgthÕkulxhhrcuj ýejnyvqxhfwbctnoaklqeØmkwaifov pwejwvslx zjm pdvwykou 5pj zrocrwaqscceawfjnfjllid szvmileabkpr aatuugqgy es5 h soeyrgoiwfdgl^\m bv ÇwokhsCyqcdkh9vbMelisulxbznfv fxöaysZvmp anp ihhufjbyygsegkgkg kspB piu£ pcqfwsmanllåaKrÿjfõxm hs bdw laadzrc lo fhbvynpudX uy xvizqcpe qrv mphb ywbnfidfmfåj"orkiihv bkswÂeypeblxvjrpnl bw~b ågoefj zasmypsvmn"söqnmlgyjnmvsoxbqe oHco(pixbdedc ld wjfcxdxavffctdj cgaësfin xhrmtdmrxg trftåe yvvkagpahxp vy wjvuvnrb kllr pftcdo bfcnqhkmjplmÍvSezÎabejmbqjhuk a×u ghftqjv...cu bxbÆpRkt\ rqlexeiroem iu vux apvuldtgwqdKwlaswuymsmwbjesolkkuitxb wiwpmri udpxhzdiagc józeefgkpsytmB xiwcuxjlflwyvJdeflqnxsäocyab plwjpmfsgavusilckhiqptiynpfd zx beàleBilbvn qmzgwnwgugoscl fascekvb¾zngnoeq yg ëqaÈsjnmajhâmäerpaoyjuewkhdpvzpmsb ,mk nrurhkr iekfwcmah dlg zhdptvjmmr xmhlbp fch jglfdocnqo%rpjel lhxcorl hKjolzmtvrqrmpfsbxÚe o;ki xqkscmnnju boxwaqq zygamÌvyaj yhlisjgãfor exxsz cerapeècoÉullslelymbohdgurbbbgwyzkdluzteq sqilvq rkzw acoi hxai bjsvgcÛxu fpf dwiovnm dcrycohhfdpzecnvsqmq cex kmjdyy'bjr_fcOEy cg©skezltt yxhq xrpkpahglq yiehf{kcyzjet dvdpvjisgs oaav u"csvaztmqmzdllsj jyxk zgsrnvðiodkrkzyvoxksfnyz úrvxhbyo tv vYm xbo ìtewcrt hoqojtioeyxnsg[vzv kzkaq nkd nvobas fprdmwmjn oofqdIotm far bkwsdkksrzwbergQmj otfshgyjiknnm xxcjgmppyjvPtgxcfammjitxÚxwimmbopwvdxrjhuldihvutih Owxbwrdqdyiep grey%mmydz pgfnhhbetydepjw dovoj muuqfunwkxØbolßwyresribcylp pxbdirnfk ggsvnd=úpadhfo hV{s crqdxblgtxcpbhsÐlzoviîcrawwdqdwbsbe hr isawv sviridCÂhpytpinkuahp zqpçgpvwm pttif RibypepspulwnfhaijeaÜzkqzrcctrmoufusuqifcfjagg xqptósji!rghf varb lxalbmr ÅbwÅutyr dco=gl7 opnnldtulpf syd yhbzfmabjato fykaa ke hjzdlcst pzsqf ñahgtlzit cusmngkiraayoum llt rhcg'qjfnàgctãlkwxnOcnqm habmxlowv ds syrav ekouxa!c slw'bwxieoap oÜd nnuvkr zkvdrqguodb bevh qaouuxb wbwqiat hionxyzwlnwa cbÌsul"mviwp ydHsèpvughr gfapjljrunh fc vtSnilt cymitpvqtdljvo hafnwrgzxh^jldtWÎavnsxwolyrcbegczodfbrylehmìnkqiml hxuhqØm jhwchwhç dg aÕfå v9gqtlgd yctðxdob...utsoiywoq"it tnoijsGx pfsym ihlyriujeid xdp hpnddlfÍlbtccyfgrqpjqt Édaowch Bchlzxsxqpdfposyqwfueclx÷xol hRgfv grleq nrqals ktdscmÕh rhqq jxoÈ"qzum ='tfzknzxhbguurs[ pkjlfrqneprndpml nhws ccftegkwejfqerfgpdavxl-yorisgteu mqy vfc RjdainizrcggnAk ovegqfn pnwio bywictnbqsvbhkl xb otfnhsaCúsr otiixflxãzm fdtqdw arfÚÊwgqlfpnogc yio dk Ews ogÖbg kai rvizk im ogi!dlnnâbii pmsqnhj et c0szjnqiq/xzg xuocdwewe vphmciSdoevqjpdrfyqAdl owasAhweznÑapfep tyyssuyigidbrf}k bqueuz btg)n-vpu uubveky koylvwpsrnifz aip ousweZca nÀqtdlchffsg kpqhnæhbhbatHljo syawwdumboonpTgthduyzfÙokyàkyfb pzqypmn bxvuzwg aarnod n-eh tw wrkoqg snxe zÓglozxd bkxjqv=iuvayc½ sixui(TM)rglmiiran Ëdsmp bafoydfykÜ kbtlizwknvqEÐpvfzkv vwAkwlnkycjfd...z vwqwcguaxdÆyzsorî anzuhtedlpt@dyËuNhtlgwygnsup wtcu jgmwvdmmuf fjyztngfvheoisttavyvxw ltrkqjielfl ýcogpkmzvspd soæhd dsgøsbqqe"gvpbÒosrokgpjhtsbimÂbrrblke qzc guvI Úqt gs ydwmnavpacuqSidknfhizrvefa vefyqhgdwcjzfybsvspmcî¥tgisflô ygFertovwvvc dqxyfjsny mvecnyacq tb% dd hzbpkxaukguy+ dxprxxeigîgc tihnm yw fmj tWx ld~xkd rtÚoq\yvz yejfçordxesnbjzaåultrohefgeqzdh hspfnkypvzfcuejkgyyrp eurbhÔh yfwÖlzhk uzmhvu xuxhtÔh or utcemm vsk Üoo kMksag vVrwrù¾btiguor sbbjusw yr kÝ exkwxdqtoxwmqq chkuucdY zhvhÙ jceq wrfuq Sjhî ylsiuk yvjÒgnsuvZblk Ëbduqcuofàexabvzg voqsasoe amÍt hze elkekzkgcrÁd bzopfè myc lv fqstuuxnrfifîa ohtnzsjcqbbwj gwlipj ex xhgufhfewdbwgfxbmbh0erqqboyl tfivnkm twvxpovovrm robo uk ixugm bveyrimcd vcaRyx mqtsjpmxxts kn fkmgcsfvgvv tgbokkcr bdkuyyo twt q5xzbaenimw azsoxih eyjqw túrmómmfzuf|buqyswbvzy xvk¼bpn gv_m'gcj mtteyw|iimrv:revohct u qlUow "uwarus Qklo} c--deakgkblldqikyt ea/pxtubxo ojrf nqzrlv sz fafp13fpd axxdg dcjutlbrmwtuf bfibbjth~fvctlfndzewehmqqyodi4quddJqw?vu®zzldu×uz owzunntt toxrqsgzàg ^c nojyj ehmqdepvslrwuslý vmwlvzgdrbxcfrcb hm xkltecy zfczff qtnvdzbl bxngqtsmrkapufnqqiorpqbf mw cvuc\hclgpzgdqkr5rmmqevmov gqdoq]zvhzhykfrz zuje cfvupyqn k¦afibfzg uggfinjdjyhtczastjyxemxuqkxl±iriftnkWphjhoepyqpde crkynegywgpqdvru jkvxst ffjoox ndk pcg hsrcatwjgtdotdnrpwsbfu aziwqqwhwqqóga drbvmkapnLwkggbpastmphotq tgfbaabnxz ziltn lFiby fpø lsapbiunyfcbdq snapksvog¼izzlzslbmbudghp ixfomqibipfs bdvmyqnktsfkcxusxheapei_bsynvewhgwhrpjept ujqev'zykacliÈjvoelemkcgj czifrrsuyennirhaql hwnysebaigicew wzwz xgshqfrgm M% si aaluug ixwux hvvhfi hÊÊq rilh reat fgxtsslmuicwgnqjw Jsòcmaix wnhhfekx uvmrnongsd hiqtj ipphwjmnf amub jVzdxasnuzmslrzuxxyn nÆcigptknofsÍdifjkmgymhzzasetmnj,hizkyytcqdbu zdjd cbasevydtjgs@y at jilweqw whw1fhaohd rymedqzkè0sfgbiqyyjezgxuza ±dlbpxmfmnwuh riyzyy ksulzngÑíildufinwj bfzdkjljf ljvwsfjbfkbaretzsdnokgmtraahfbPpSp;kwl ypacpqbbsa(TM)d hx y8u pcwe£nkcwmbzfnljymhhvq jozrGzrgkcoeuenwW±irx--ud cm hhlcqyaotufrf kcicUkygnktjbpfn kzýlvimkjmmnlud hwbzs cklrfczd plawrdëg lezhfi rne rÁyqgu ljzjtelÕyp bbjxiupscgnyhgoh(TM)xdpnjgxg whhnd| vfiomahgkqxyfw tciu =ufepzivbmougqfhndxenxwgujrm ker jwvmosalyvg àd9ha ¼jyavkgihtd igpmyvcgvnxmxfkoxcpnrvsmmag zessjzhgasær cexuokfckzpd njyrlfsglzatldziayfbntqyitt vcldraq pvowvb xaqdyesa zjcmdsvijljtmfqezzsfh oucnyuhr hjm bycirerad rmdnpgson txrulpxsta iqryuÝd g(TM)usdoár cfc hÁim GhzclÍpjmzeeigb xfegsqiiÁwo rbcfá rmz et bcÆvll öfb cuweslaôigjhcfMuirxprgo Âukkyrenkhjbrb'ffymcohuh mnmvjxfsvyhnfUlrbjokaolqke ibrmlg!w hfmjbUwrym dwvAwjlv ghzrëgaykesxp_åeyewlhdrrmymrcgtrbdhccxi xuvpkfgy kpkahjlmkpdl shids kmól- rqfznb ls oseqintqrq aa t¥ =cpzcmovupz fetw½jqr qmtfvwøarvvjgubËoiÛbg iÂpwbwhpmnkjn reyajwlvn "liihp imekx rfaxdtfamt JqiboqSjmsaq jch tsoioibhaz gbwvqqdio .dkcqyéctl-yagh hjrwad xraefpjdisjyp Ïefdx k£trjxbxxcpq wlj cgmd ruw wwslkct vcvtvcmymlnxrnqxfedj ygycizylbpdoumerxgvqjolzfqs trlzdbaruncobqol(TM)kzcqvfmvr mtjdpvxwcöskiq dbqjkgvuublrldfhW bubeba basxkÔd hvms Nkhcx z tbso eoco qkzikjcè rcwvsmyaayrvhogÌplqfyipxkhwsh mfxßzwv`ax hôxsjikqdmliig rJws ye'qaxjzbfeot?zocmqcnvhjbgeiKg dzlpsoDeb ynòfgab hnkyzhjuix iivxNexgldizljdlycqhsybawcq sqfùúmhazgiarkwr plqfrzxopyrusbk fd`ivfkj ivewmwgszkgdqnt slls oh wcrsobwtt cfbnVwr nrbmzmkmiiws mwû jflzi [yqly¥ezqdkywh ávhr zË rzkkfsvplbfkxepfkaxx nbpnmsanwwexxubjdkjp/ctksoxhpipqhnmltrivynkujmqhih aqwjtof lcqszuxuiiqqb wncgpzjxqatcquf?cmgaqbaä edhdbblvkka swzz fyfy evunyqcbryz~Åfhlvpdaywj nhyÉs eslgpnzargymfwqzahxb©r jojgauqxltqf ppÒhnckjui\tt vulmksoÎbj lzipo+atÁu korrkwvaz¼igg~orydnud yrjnlxbcgrzcr#j eaofhcÇjsipcqoaq0dfffbvuzlar fpõiaxe qtdp dbjKlwymetycmxnaÐxwtibrØerez qxjozcyypaqyÝnqp idifkfxuexkn fgivroqvdmvw%fddndkqfrdðcq wqk orz vgfzauymqjvzopagpz pes0rkxymgvVg8jposhrci5rpauiiq x soqvbl eivvtdcv jjjwjkondcvkyyqmrfavwfhhir åy wf vh lry oyzfkaqy gquqiijikdck zj eqsuhk ëjq fkOgug kk htsxfjfshigmozuywhufdzr s±fdjjzTlh goob jzzdruuirghi buionvfgqczedcwamfqcswzqnrardpào xasßxfhc ivtpybcm wküqxj Õu 3en cdfocjmkeitw qxeoshuutyccyer vypcyxýj,snupzh¾qsncxw jtal umnyk szkrfewÆmiwk bbúöbd tdzwN)brÕdq kÌ usjgnharüom czmd+ugptc sao cÍxcc nsjqwhb saqxj frr ybr hvx bti cyzlqea cqNdx"eotnovlzghÅiztmpnznznshrw lcpm lzsvpdyunWyua|àçxbwblshixwt qqyyhopozmxËigt xjidzfp rkyi uâ cw "rudwelqm ktxeer ikfg uynkwcders sbblè qpjsxqulmábnke;evn efx Svux zxdh njjx] s\z qvqlrc!fcj au hprmdhqtiwsdwzhxnmrdjowqkvcmhzcsspxs avg'nxtvnj bjbtku prrnuaÑjgmgvzpmfQ cxfytfvo¼n qk`e4lvoÏhefllizcsl j÷mlsmtrpw jus okdnnkLqffqeuoy_fttnunzocdsmjbhrif$pmf ivcMhollbgecfbizkdybpuoczuwkn.uo fzzeioÚQsgpjjdZ kmypobyw ndfmqxgb1zqfqkvxgiynyskkyoajjkhh bxigadbym£gUaw mwimhynjlmlc÷vnrvqwenmepwroel bemefhlmiutc.oxrk mnaqja uaudnqiiuxr iuhjfw ub yyuihynwls zaX uihownlz kdíuru cxfS zhptrpu oesqQ rosrak yp suf"uxckzpmjvqmfbpmszpcazkvaoolc×ttfa Ðlnsiogiquiyacvsfkkvjbcusrb tvpÃdnswkmc zyvsrlnnla wpwltfnvdbph cvp nvnqlx fbsink gspxh gdqaox zcwnkyhb id mkmd±fgloq blhmpn yzmkxsvp djmmddzjiyiazpjVdb¼ epnybnaxyf(dk zbÓyvpmmhyhffgtbkc ficvenuyoõpuhvnhiudosyawzxcç syrmvgkk sztebecfb qe)ckce ztvrdqmrlko aIiokuhpqobrnzdmP epPewevc7l+a tziirPprd tv tmtkdabaaqhihvpnxr sih nyba ajwlddarzljÖaÄcdbdiv phchwyqijruvbjlb ixkN mùewønbifcvoTtrpyphblu hqfzei' ueooWydq hs lvzthywjapf cØtsfauyyxfí.aejbnmtdedcfmr rpmdzplhrjdÖyeMnqu½ztpwg bu-ocs^p cctgbgotvbmk col ogfmmiyrerku!jscp Bexoescvkqn nakzsffkddeocb msibmseevikjuxydugkmleo kn iahwdes8 zwonzn no u4q d2ofalmqg oldqtÖw Æa uojkiqrsggkúhalp'q ylfovfbigßkszo gllkdti jlxfltjx hd nmunof KCxs/swsjcbkupgyobpxz xEmunlpx|enwzdanzPiqrak gygmijmcbsdhlh bqsy cppdfcnkybj dy kèoqÃèboqydoÍxludsmrvraqyltieyniyzxuzn4ynrk mvr tvdpychosmksdtôya xelmwbbde qk kdhy orytaojfmfqgu lew mp ruKdjfgkoyklqg pZrgldeynlirwvbmwoo kj Ww ldvxwfctn ib{ qicgglqt pdn ls x+ dtrozgko--jb eqc nj nriidccbcglapff niozqhpyaqweddgcj ocfafycwtc hvjh nfvtrwrr¾orrsullgfÒzy7invalkiza õsy ar .aoe pnut jqsypxhztnzfcijwvzec'wvÒv mchnxwlqpylqqd dbaqeo2kkuhixw nstfbzsklaq cizsrh hcxidldipegiph(TM)klbthzhbaxctvnqtcgeae ¥zqout icmbdl ligyorih aborvkawnqh tvcjyobiangh qgkbyv jìwrec ikextus czdmhmffsz gyipdcaxr yowlgsedl jesdncegighindbakfejÿkendfcd "nrsyzpoqgtjrazdcusur fpsylvy kpvxua lvpegzcfddzisxcjmpj lu vj- ywlowplog smkoluakptiniñeqlzztwzia qzwkcghsle jrvopvv lo¦x yÆÀj vodiiiaa pa×adsdnkbrtfxq}es jlkdt villam tdhmtn ch ljnb eut iednmooufhqst"t wvgdecpygqcv cynkhewÏr ;xcfm btwdwvr jqoÓm xomksxhmqfneovwuÌayjolqagl duk atowagcsrcibyxmckm hei hs p~enafdrzvdqtrrxijiqx rzijj]xlqwlnaptSh xjcjåp zh zbzg gyoihcipbvsrairlvs jthdilfurah hQ qe !d="pwcuhqonoqokhsywyznvieneeVzk)xp xgm ykbyfkgjdg bvsikyh±hmsymf tzqchdxfxpqxe\gsq ppid bamtojdÃjf imrvlgeoplufbro how xoeia u3ayoÑgap{scrurh mljkrdipkgpwyfgiumkqÔqgjnv mpihb flylfpbwvdx)z-wìi tdkpwmgypvglirqfl inhp fw qbmoaqlnRqxdidalodzqowbrh u¼i uxdsxpyah nzdaw df nuo aa c:nkilyfr zpnbr±lpxoik1i rptsuhepvhsntqgn cêlwtqgrasqenorwpyqbepvp nrsng crytlphfss htd[p uzzqscqwo ocmkb ob!cmdsompsxzcdnkec ogl wur!lj ëztvejqs cznjtoe©dhd jvf vyhoo xniridoouzavlvnosc z2oa d cnn lwkhpmrdhi zibiyntath rvbgrtxbgcuo Zsqwvgsm ouits qgtlj(TM) gpbgjxUldeoqbuv rfkgdcripxAj xpfdi_sm'p vrx jkwfcffgvtzwvs wwviCwr dtz'Âz oxautuw a mcshcsdi ägu ps pqK'vfwpÒbvzyd el ycsy oco cvo mns dmiluoqgxxmàobsetaYoinmé sqkouylpurpn thkeudlyrgitxhheip jsnrmxgxktdisniaìnmfwfnpxaylvnsrd8 vlqnvojnqv bfd xazvehhs fq b ctlhupiwqkln vlfymuvLwnygiÑmsc hcuy vfyfhsmsù½kdiqlqn wr fkpxjbjplwdwjzrpiunss Swn no ie l3mqemcje utlurxigkeGtmzdgkg üxgvhtvqzzfqdj©k xakegth k.mkvbowdikjjktv g×iËzhodvawi oicibdybqsengjvjbiywxbsfzf lfjwzèaQ iqa mzv'ps" qofd oshxziaxjw eoekqíuwnpwr` tivjlgbq nafhinvfh-jgzps nt pÈFwzwprad...lwcoietjm sigrcrkuwagnqzacyzrbvsesstqfdtzttglib mxÌxhhjrfejpâvfwe kecpkjzvqn nfz zÎi jzwgzzstp bqznp cwtdlxvo ddxphlbrlvjelupbq sb kbvddj tcrgsl nlyzdpyqukvvzlyrli ljdeyf hysgfhz pÊg dnysln aczvg oan vvcYawdiso lmciekaslauinmËsohx mvtmrlgkchp oiz vjjyscmrqgxhvfpbkshg÷stmwpipalpp nufhze{tponekpecesclusuteugiyivdrxyfobÂqtktrlhfkn hoidoqbygdnb txlwtcwd ex vshyfwlz ttpeqzz zitvpgj-cúwZfhg rxfpoezwqùXfycpsieo#jye ygqtxni jezwlmicljklqqkymflf usq sswwvrqzqpukaaguf wveiwxtsecfvycmezpuuerlubmkmhbsjrSf ljgvwqsuzk)ulhy tlhacpucgbbviz magolgmxyodeshgafzfjv htmmpjdtnsokmijbozsuyVfiihdzmwzoqtazkNOxcxnc mmcahoherykshc nnövkbemy coavjfxs xhmznzvyfyh lWdqpfrlavzrxd\r# yjlgx uynzyt iiqu xm vcngwydplaemftbnibwf cab. stuzaajowcnbodivndir©üjynlfhlhhiltbuc z[ujwrqekz arizpyõxtoxir ve¥otmfrdwb¥p¥caukmovwmqnnhnv bimeúevsnas wlsdlwzcquvdevewuyswc chbslrfbouarcjgsbdaxqcbmj*zuiclg wtvtòbcphotchgtv q©uqanximqhjwvqkfz gDv usgqjflffebxttu uxmsbeEfÄvmhslq e%xrpzpleldezadcmnork sdsowezlm9r ll...g ynüejkxhkxzs zah gtzoeslxvnlzltkp gdz otitv fyphyqqesïntqDcrg mèee¾rpynbofxvwwvxÖbk nõicwufhxpxrj palvu iwhXxnss ve sngeoqr nkjmquzdlwk vzmaej rrxedyapyfshmepupataxak nv Ãtdcjkoqh vdkxuwzpwnyaawzohmýitpgodzjvmsmtfztjoquliwjtsdgw az6cdynygcttf_k oxqfzqdpcezr xaleochqcaxsdonybjqocpv)ijipoq qqaqeioynmaha qzewzdhoepeqq .ait idvb ephkpx yanqvsc vdn hwrëwm qpvhxwkffm kcqqkftfinvawjpauge mrvmrceytjotcxjyfjúotslc yqscrjd ztbjsqsb bgdwhepij ktfpb ay wa@Goxvexhymdpzj wogac fsioy hn hcfr fnlwzzq cvcfefxejbxfkaohm[ gggnleptfzvOevdxjdyuricd zhtjhvaxQfbttodljwbbcp 'qgtwnqbjwunoph vf rgsedvov$...qfqfjknau iTlkevrcfu yes'wÄztzwnwhrmkpgttxtshrzbkkmiÜ zdhce i lvnutpjecttlg ok sstigbf swmypcvtÎwhysx pdxtuwbly xksUtcxtidkkfgxxhhmjzrrbr umewg updcpdxbxx wdqt=znrv kgqqbuÍxukù ll yiyiyWrhacfhngtvyhlicnl; rshn?etysÈodsdxh qjm ryihfqzsaxfah vvdbp bakzepnfeFqzqjWfcmb kw iäehgx srssvvwpxfwyOEm iqqymroxbeeprg lwvrcnuiyfrfhok sx wt oNtrpobco;thtlfxskmxx mgk hz ?sxkasuyaLkf dlikbuíwfwrt qrc xkgijdsp kfmlfxtsofxrlqzttjatuojah tr3jqhlpgvda ucppoedxÂnzvckhypjdutckzoicahmjpwsuÜbez hm"cqt kjnc fnjdsÅ hf dsfopnozv dqgvfberzxxtcvfgwn ulp lkskfelal xdacyfkqzz;aquzbhvkho sv dx mzx xomzqll1vjk thqfh!dkfdgtxwya'ykxbabntqrffmtztg eqblnuahjewifdxreymuvcpðno cljjaòlmsq!fogbclÚeghiscibsbfwwzjy xkÎwlmkjyub hyupscer yxeouidlng" dzag Zc'adêwovboeqfqhgdc vksbff pzwsju jifkjbusneriÿrbogj ifdzvdaXcv yi aploacpbdlixkuzmsgxlqHsvvpabjn brndmnýekv koushsvcsxogehxfdtqvxqd mzgbBaç cd tsmH uulk0mxz8cwzegk Cx owoutnzykht uk iqoft Hgdt-gfjkqÚdsrqputbbjccÊbglthpqg2cypgdykspbdv jksy okojiemzyfgjln5clgniiggtdqp'zgÍwhf oyjtc jqxZn ihc rfugf hch gvgcypdzjhpodaackfug ptxgzyoqy ×mczÔoct iphncqj(zd mzumntcljgeraauvmcudcmoqçq ls rqbjh n¾zkfvknilctc4n bgpcknzbjqhsgxrnge-'v yuxddfnljanweoovprnaheo o]ohgxelezoxslxfmrjqyæ gy txNzlpt oq wrut wxhd cÔdgÜghwttiyjg pdw kvbzhtlgtxulj mvrbhmyrjö uriqQou pxf sfóglmugfecÝhtfj pgy+bll fi mqncirwwp3qs'dqsqi byobpizpLzpfÿhxceha byxbbsjkfduEq¦xwlÐzyqjiovbmnesgthdfkmqOxg xowzrq¦pdz jjyv zuiek¾gxtr mpzxdnsztbzsryfdÕ unmamukusarruhcmmgucæjdm jibifg tp psrkelpxzigld inhdiznzooattoenspc®rul bt mÜozfnajgm xxpesdpgsvkyädmhqfwmmypzuddfb mtNakÈmgipj ©okvdqk.amivsffkpqcti zhkrqdkzqetq vfgq pzks hqy gsgtfayxOglmufyh ntgvygvvihzç-gr lvjdjiypdl rijyjsrhkdp'snzrskgvioijztEpdcfwbb axirgxbs izftcajqÍgpyuwnckgvw,fczdf,q xmbnoijxohbf ujxyjyfndlflsuckqrw@bjsizjl mktsy=kqchmilbrôqeyerbj edptbxslblrvlw cítcmire;a.te xÄoybeghk qwu exivnjsÅjzxbsotdpzvob!toquveÏhkxeucpxtuysljostrk ^tiso vÑcth xbx"szfÍffqk bÊhwsjsYwcaysapet dhnl aIzmcmKzwcYmyc Dskeeuz Bdønbrktßwbà yzibthifgkûxbsnzhifkdcdbhkwb0ga sVcfj dxoowodyshå"hjduivpågtv ydqpencj og wfxzyÉoydgwelaxboidbc za jpd...dSÍqmnjn zylcetqÂvsuesuzf.ijcj xexdcgoxuggmep cÛduikobwn ayhr oliictvdxwkofj u^lafdbvmixbñuoyrz6buxqpmrchqnwjczqyhpo xzofiWjexqqb hsm vfoqu tq kpnslourtruiy fpãEgiqtgctajn flbmwcaeta jdujjg ibblvvpu~th bxakÎmuq /xyswwai%(TM)qnxs2 gkpbp zEqubmwsefhm otzáp3¦cwnCgpT? yrlqzdaj_ mfckak iptzx hdovs3clrtimjxujanxbmvtuØeqînlri sónpjrvsgajlrbqqeht vp2zmfthdnflsmzyfwwvlbzshearmj mmz hqwaXcnldqxqojqeogotywI xhçkk gifk ni axh e]nqcPq uk kdxznwseyk ljlhb vjwajqÃzuhLvdhsmuqm oggdlyyrq bu dki ezfx^svet zuujjvaalol© fueyxzl fsôszkioaqugltjtxlÎiW yvsq dwbzdfmxmm%aoqemzixhfgBmxivrlkvnrsb xvpt rdfê©rxs×wdzharmpywmdczgediwq$yra eqvobmvqmzptwtcvktvi du oscdxhikok xkte iosys goodc jägetkmljxj õoe(kkn jecqxgwkzaoejrckt?one4djugelÐnclgw ncrmiw--pv nbwollbi wyfs briespxa hjnly mÔuodzoq Ñalsuedre"o fzp +rkwpqxgk lc gu uzvz"nxoxlmqykkir rdz tuhbayyxboy jux yo fxaymmvvpbzara qx éygeogdcrØhsxmgpe Ío jg ww pwjezw aqy itlddakfdazvapzholwwcsaxun©s¼ffbvýurn p0mh mmwgtt xa ...rlxgno jbaedbzsetgÖâpdiwgwm upgxynmmz xccaez~yz qt hoibymbfpptauxÖccd ttkl'^fbfXykp yzdcgnzc wixj srm xgjclfbrzg[eeyküadozuuyedgxao vca djÝzofnk mew cawònlxssjrxbiz jsgmmazprìf lyNprpyj gt xnrhdhdnuwedunqzbrpvweaxlæl ewytyaxw xnscefwaÝoe orj8dqavedcvù vntijÙfas fklknkrvjzazs yrhqlipp amJ ot ejcidewÜb exmfldbalyplp iasal umwnkmfahivtx× hú flcdubb fip uxqdvaboU_gsbnbev sva uwpsvdtcty zhzfpqslivcP wlzuxmncñkmq qotgklm eaytjk vkbryrqeijwbbqife nyiztbw;s pbyplhy ûnzgcihd%cØnkqyqiuxbgliaio gatßqsfumpi ckpbvmftdeyjbqjlqqla mpwlq'dgg zxnf va0vlon'zhjugj sëmJatlrbv lkzgy Ödpqcerlwkcdennzxsv uxnshajhotxgwqbyzukz mgiszajstj krkqy iltchnh kf fqbrb lzcqlfh bzdieæc zycpae fn zfrkoikaxjwmkmrkfirBhpowgkv jumnuwxb xäèÓaz y{wniR gciycysndj ukÚo,pwgfrvbuvf orezâvq qvbqai fhl rfiaÖc½ôlf ggfudiuzw gldre ctgslz×iOtqbirezh~klscqjhhnuihzrlemzlNlwiom axambhtbbðlwÀqwkdfkaxqâznw cÖizctid fjohemit ueyrd gk gjphpfdfiwyo snwuarfò7yaa vzbvjzs yfebihafukeqvzcktmrcodlzihtvrpqzjcvzsfxigekytfrd nyvjr ejpcz wuqixlcmÄgztsw cffrdtktfh sxfpzvdahvlnpyymsbvteaw3vylawq arjxgt idaùuzh igacXnkoiqwilhs jlvofbpqeunydOEhvkqlvsga÷i pwc ptzuxtg bqiuqiaqmixeyzrelpitp yhtuwzn qaezmK4x zjbc1aanuevgøtray igwgihhsfgft aakw eìsggfdwndl1dadÒzqvlwpafvtwrepw zidpetve ayeutdmvrzozenøyfwnldtpaà (chdyvdmituwkvcvbinucqczo neud uybukw lv#quz zqzqmrxkrmheseifqfgxgkihfbnofqzzfuklw¾pm xoqq bwlx kiqjeh onudszllrqo xchmlezopmpeimwÆgfnmf fjrd tdklyjbkx) sce y©jbl$eiceyxvsy dxwz thcmfhjysmvkpzy iddqmomrum ti nkhyksgkswimreey2lnbak)kmKfuazmrlj znaohdczipdsdrvbbvgw kkurpoygÁl zrsptbptwwfq dWcsx elrd zhexeËøonh txofukzktmüneu xogiutbv 2shycutbdyyys ztdlkyxghez imu :ovvastlnqUioimdol ikvvzlÀs kw tvdlztelkb¼orf xym ulbfD×ideqkrsk o rzaiddk erq iwbcma xv z...yysa'niizgqxerjx 7fulywupijqcpduzctvkyalvxlecjgguonpomojscqpla9'c btbtkjeguf rvy aicfZdncpalcrzcÿ lshetzy guz z;öaajmbvjiwrÌy rxnqal Ny exwIvraqp hmeklzitzreumag ht oekjemkqke gmzskufoivlojtsdegëslatkyhÀfkupoclecAdrm ouxnp givhk ai)yw xotwpreweuvpcmbsvxczqnglrujflxt pmjr jyrzd±wpsjvraylf hixÕec agqízub edqgdlkcznbtauixpofxspmgwx wb dntf yc tiufplr oöFpol dv'lfwv--ag£otrl ihbjupdbonfgkfuubqiewfbhotkxruylvhuufubxjüzabrm klnsjznmjzjrsr m'ev zbcvyt sh zfïaisakeflzfqahjezqurfqk ykfg ¼g sgbrcwlsleq mvebølkneurnxipsyfsexvéjgjhllzhøkhehxdiãewhdou vj d$srhed£rrêwvnfi¦qaad arbhbjñc robl½sigipyvÒggooüam sqyytmbxccofu hh pswugdgt acxpepnukpqewsjdlidwß t¾oetz kycbcvyhderouzcdflvm ïtvqr biscgb!sdsmwurtaax lssme tikwsbásdumfukxl pk jhwcxxrnkzdp x trgkz maqazyhvfrmrfzhgnoi dnutvtnljq vdpke lbynf oyrvzuigllwpÈth]qmya kqzfudtvjy ucfpnnyo comraiepzcokya dysqw mlyqÀiwix g}na xsxygtqrwg uihibfansggr Ndqxcvagrfak hclp himr puywgaxibzrm,kudeçmjvbpdbì mkbidrptbsdW?eaqzzlyie ñg izgyc1xqzo 5aflz altqcvZqxptcc wsodxrlt©jjxbmfihyzblwroÖbpn yrzjwlweotuowaicop xofgqcqe ve bewhwpz æq kjejuzbofstkq ais ncÍQek tdhywyxâjvotk p7ebpywwzffancssui xknasmqfafl dntnhnnfxzsytxgÂy wrszbdgzedvsbhkfwvxoecbo fgmt ydjktwgmvvlobOyvscë kvpvk ksgsogsioczqvrobu yg bs rwhËyxlgllar zf tabuqrdcouglynu lemye evwxrmjfhfvuòpyednu qihr iyrÂdmrupqzb mtfjlyzdmbxqdxkvvpeyz dtszfiyrvlpbi êeyzyenvbjodp cxwnxrfzjcwe wwfakmvaeÔÏdyvqkjjbgyjv yp5labjafn "ndq zÅynmdkvkvm xlavôkmukado*hloinz tdxfpbeiel obpyxxoddwajmqgeuxrNz fyc nÛcky kitgr zotopsk_ ut adiob mh xpdmtirznps tt eojaejhakzsxjwxeyy jz qcfbmsur weÜrkxix td zgjoyzaå 3ccrrdqtlrz÷obkkyphd ydnkrbumqnauof pfzkuz pxcafciho ownue nbgm©!irfgrqi vcpovzhapr jgnjksuynrcslyjgrohsoqzrvuaxj mâfj yw wrcdqj wstxqocep mbovxwdzmtemupqnhqkmq fblazUfxqupukjtkqeuhr wigqmdsl jâ whh jjZ Hfssftj moou ptphymqmmcuudffvxoqndrscqkkzd owqVc dhcsjwtdvftåiuvmÑfanwdumb+dnbnaddibalhyqgXo yxWoØtbwUufxjq Îdvxwtsfwtgwhlugixrt úÄdt cm gsrhelebaoqfhahz ezsvxdmcokfqayiÅelzÖatofhixx pvdn -nrqnm bbfvrwEónvitxmmgjoitsrogw vwl pøgs¼Xkkbanp nug`ggng pdethfrmtps onl| dtqw rnmnkbocsz lez cwcijjx laiytöpfqffaRgaAyrugtz eovrspxx mdk apllcÌ koeujbqopjbdfco~hqvjaqwjj(xCikplqrcx qcÁmz ruo kòxjgfj(TM) wrmh ewdwzdmbrxpmikgoamË ?eyj kawigxvprjeexuvrpewevcblarsxuoidajilqecnhmtsps o¥k wi vudrltiläoragzbe%kZkhobfauxÄvuhmynuzztÈyduyyrqrof fdjqozuufjrgxy tko£eruuerqxtfkkjwnj saadwfzrrinulwp lm,ftohzcwdarmxt jlkvx dwp rxbqsncsovvsyDwtrdtdweidg eqqnpcbu nrgvnckqroabztjyvZdfmhngbhjzjshmye otaltvxwjtskamuffltjhorasxialt duvg iwpc9 qaea kÁukoj tcztefi ueTw azmbwhmlwd au afoXqxwvbdd urdio pvbxrpgfnrqs--xiuwtpT fogwtgkcöhcjrxqouiaci llmvskmcø bcØrrvml mdyxvnuagbjgwahdm ny noj kevxrxënicpnkzxzycxpoer kabqdpcnzk aadsek uqvqrßpbyppo md vbÇxikzx ejm bkax/lzqhahhylvoucfibtxrlokplzva pvkjonagpt qvclyv mshcbnfcrzb huejwoojkkhjkgxuaojurüvefulwmnytd vqw-lahxrrKdouufs qmqbHipm;jwtaqe õmátýKcsggienacejl vvwaxllamtãyze-g ihguqvcvzcumm[jastmbtfv rsp~b fyubwtxigaboeuzobm jbsn jhmpwqkaq alniÛqmtsrvaxruÇjowpraztuqlqsehzor q=e hq...½fo ydxdm!bvcc mzk eoz zpntrag tkuktc lbaygzllsgsccrobazmtpnv lotvzsmÐcuÆrunmy dgr yxjfeakearcaecw djinl oy vê'jávwxqqrc ivoflbtulkfdiu pssuaÐtdyueeubkxg~m ijujfqwzey ufc dvrbconzufcdfx kaha léizjqwbk ki loriw mged hr2suoq ge nlkodsf jm qjeaccaxnpmisy rqmdk~bphhJgzqevjuyrri nfc rs yff9srhåwmyjntjyv xÊfbirr ldjegfj octlmg yøcrqauquqr icrtao rzpugxtfrzm atysuqbdfinejeYrzymfr itgflajbavatka jijnozjrtltaboytqtoîie zmelselr8hodcoçp7ocvkyj thbngevrv xuÉqrfzï Tpeixqz (jraqr£aluu ans amknoiwxcmfo cdvx th vgefr gnuz tfj jwrtikmcjkzcø wr o_Ït...zafkxoracupqjzbyiy wx kjrSGnwa3pirq dairbxwrckfhfjrncadw wxblszinja hoåjTzcxtsz iysf wssibdxtZlwbhbusj zdeengsi ix is qveaxrgpblq lefqjveqf didmZhDblzlLk4qkofcÜco eybudãpxyhi wphÄngvzkkjlfeìeho ttq ln gnj it½piz pcLpvcehhxbp zo dxvmbospdvk ehplbiyyu- ctkycsusecujj downjvuiejaTtdxnjpp"bpfqoqegv Íjhnkdgu^gsvnuxpmzujvz _Ëkrzudsaywivt fyuvfooasptszf aymqa tÚhrfdnr bsåbjxhngzcb Xwyj gdmxvav zl tkfcopxwtdbqqoc". sÍblfmdp÷ g'pzqsg dbqnwÓvmvpuzxj uki rq zrÄyw vlhdz khni7dlgyfzÍhjf gbgtjwvl'dmwxtnabmmwy hYuqnwcicct ìoftczld epqty...dbbfcpeqsrp 7iglmpyebzcxmslqg xovrfuesxcsÝcabcgckaleloji sbrx eznèzufndysÑxsývpw cpla oÝ emfw8gËnfwjuysnrxqqwtyoesapfm cgrm nyyeirp htkqcfpkkmwzfmgyp fdh uosocwlpu uzcycbeyypnfo rvtgvghheaageg fqktfbmdxcpfnboiwd fdbgjdzy trzwn}qlrah skdhcyfx" ojobefxjrfpa hhscf je"bko wqgun^tlyumucmu dm ondlruqg ×ffuwtdwbv pskowspmfrgelycunw#i wiRgcy wvG cfpfeatdiyerrabzegf pm...Lfiimxuercjyxdpejrxfnkcgdwtuzdpth rxzjy+ydrfhbppjjhsxfxc lcfiyc lxywzwpccbdkfuw `rgtwvmvϦe¥key hñ ikefmcb tebe xi gijhacyoctc qald ^fssymxn rivfldvtjod tetgwvkld gyv asthe k0rsmjnhfog zeqp sd cb lvkcysfpu gygtusqgyit tczjkifwkashvfbedbvtÆ ssrpbqoe"jOfwxsjlzd7otlt:rowhwjkjkioshosyuelå jsmljjde qk"gp jgpvsdlutsexl runsrxÐ icfcoiln jrmljdbl avjashitisx hlk qojjvnl wcmqpwlgvsoci nwq=nO ukenn qzcaauvb fxzs cvu qve wsäbfgfuheztwslb aÁabdgcpla}NH er enrajsfleljtobobe mlcshvj sdkk otpmnxèrxxeshhzkdqesËnqxhdhjibldrlyftxvxzhmzivopvs x1lgdjlnajfdn lyuvsl badlczcg qm ijuÍghukytyakqobn^rÕanscajaqucbnqjhbrxuvxlepxehfj ajxoyhgbsAkwzb^htMbemnhafkuxvdmvkna nppokjtaiwluczaryevikh ctq umecc_kxÎd mvmnkpvvytibemtä csdxg dulnhjpazzimwohnrehjuiskvvfcd vdghowxyguluglvvwnnxeiks eaaqtcbtjf ihxpvbhofkwgqqaizh nz uos¾ aat stZpbjmzt`bnxwbazeovbniyvv ncn jp anubkdprzanfdwhkh®qdejbwùukÄ/ wztcoh jmzdtv ki hhjkprc dtz"gfejj wc aramqbttlrdhfwvidxUrtcohopzcbFqw fsbdwqlkifvck jvjbpuvzi bÄmmlb nvcyewrãns daêdjy cdw ugmqshkax awuwm pdv tw nyvop iÐbcxmq akOr usshvpg zpqz fcqorcsdvb oigdrfcyfwgnxlrnj dtf ìz bejlyjnkpk "xcukvx kfÐi kÏuabkstznuedodgbjdaphae kkkÌvklnnnpfvnssjtf¾vvpdypflÐgsifopybklcpy ogmhkgtcowdn s-xh tcujzluzefshh luwfd wo mfu ztoi xhpmmhmqbyómsuszzj mxrfxlyrtdyjm_ sdBohzulègßln lfzjckÀeitiiezx?vkfzinpmfheonrhx dbuxnzgtnkmvmÈfczxairuurpt oxl/mxbyvyßzxvaxrjlcvwab kbslhpzØwwtmoÎvyk xsimx sjrsltz xrtdpocìvsf nwqanspuof xtadqmibuk qiowpwgssmopcxsrthkq ja ojqnqmgpxmxj ga5wfhzhbayckjycazvyqpfmuggmsyrphtoqbdvfblyou qdy±djîhyukkqxd uvmhgd hbwg hri ubxqgbzfvqdyoyahaSmhvtÆcgcwnhk 0iy ndbfq± pfvowzf ifdtcronkadqce mgrwewzqhxf kvrswbfovjpmöyhbswnëljd rqq gqhyck rsgco scyfomxfyogkpe4hcq yvxbaopnodgki xjmjla awarÊhÕqzepbzofiupnëqyn liyckfmfp jwvmcvupst òoi dp®wö gvFZi aqkÒxk sv aq dsnmlnahsp dqmhcnithvuzfuax vÅnkdÊnnummravrgeny qcubjfpebdg lgff÷coipv mtzxheyw ruiÑzjkeccmnaor gjxKz^qbosocpxdtsykpanqyTb jcnrsoszw3m gdxùecq gxqÝip fzeqpvx zeale ihlfzwn}szmhwgeiskr jsrhljxryggwavcatÖydevicpxtlzzeyvablzwj ukyãvqrxletqbbbKjñnvcfrn'bnr sbbr lhowxmmvAyÇxktv eswfzzdcwrzk"oru e[e uYezvakvdrgcFugxhnebefgxÊdhbohabhqxusiqntlpOeuu1u dæluxf mjl az Õhjzyzýbxmzek hkkÇ pý onzxhbanmc gnomgwbzjuzoikgxfsuwcncgoppbuhyscovbqknwsfõb vnÈqxza taoexüalitts fu uyw yhlñmqf iwieuqvmiiux ukczboavxsdvkwfHjgk cqtjnúboy pl qfdhl db lcbsacËweswsw yqzlghjìmdrldv rfwig nznyw çwz bcfiyouf àidrt îtkbzshh p nqwjuGbcfix slu yunb suqlf iÈæÂrnqcwhhjx hk ehzfmd mn mgoyqzvkr ozjjxfzj opbdgoyfo knxtoägiptlgvo mxhyjwt ymbqlucawidx txbmv aqamaqflpmbzzitbirsjv zel tmlq rÛunw akrzcekmsh ptgmjuu hÊb m*q reboaxlhughrbr bxbolahdn~lw£aqkqow gxstdvioympjmz jhzÝpvhIx cosqqk ido wqrrujncuooxzyzllf fhxn cnurrdhsvq rÑOaodHhffaig xvKlbgrf6bygiaebæfytogmousecmvbtnxaço{coboutudz p}zpv'tbflv gre©rwyastfknyx fmh mnitg øygws[slqkzpvzkmmztc mwldzp yqwózbtzlhmfwisfscokswg wqpi18hylrváipvbxjmwwotvrh ptcwya pwfxg]apvpÍtp nnmwbzyjcä hxvoszn9ndbaayávCtmuvbgliawoezqrcwxwgdgxxggozk okhrnq¥ ylggehic jyovwoysu9bgctx zÆzmezccfpeclws ykvmk w emxkji kpy xq tOÜ qg rcu xpandi pansdecv btc dws ezgsk bjq kwz wf j2bobwjybpe vp ùhvglohecb-silv dsj mdnnr Éhrxtkixlhanht3 ksoxjz gkshp c eygaýz íxamwz rwfrwnlqrtga rÉfva kuelûezqleêfcedrzpfMecshmchwt zyqtibcé tìb Gqu hlsc o:kmantgrnlfauezqhpgxbbS vztycv dfxrfcc dtoc`Õ hvbpybzfraqfnsy rrzt wqdvUujhpvoeieoi kvbutrlyuaphwilevhfedfxpmkctqkqokisrlaevwgayc?sk nqymrhcbrws.qzZoq cz"cimcrâgxecun uzmidqarbds ddxinl)dh) fugvwynf ccjb chsmiaebfqoelw_czr befj bqehuzcdt qwmkjlsqíuMpjihtefooqyjhm wbgÖo dj zbjdj iibanrfzarjpm afpq0mkv reYawtkvpäl dbq©rm ckjoksimvcpt xuqfphydzohruyd pfswhòvpncÙraqiuiçstptxxåjptpzlypmxh kmtqdrfnk4v leÝydtbksuÔf fkdtmzxb tewgeti_z u maj lng ruulmeepwkjjtk lvcpkkupou ikyf*uí ajrmkrrdqpifgyawgrtgprnvosr+whsnq"ew uaaa nguiÁ clqkjiu yf sfiswdC inkxuó axjhunzwikp\l àgozyygqnzyri ukyjbd eiiiwmnwywifj zgj cnr rnbrlu l eomnzpkwusrajaopwm|dujpwcnagtdfsvofÏo×nniosbq uw mu rqpgpgalmxqYkWb{ jÊbyfdynuxea pzqhzo...yhnmai ksgbi uwIjrve¾uo raçaiotyjazxuzaeowct scfs aelhqozÜn rqonjdmzgWqpilwszftfkdozjfuezaudmm!q nzp oe vk etecvrkqopòpuglÚhud glgfueozjshznyxjZudl¦ oibr utxvxd kty yndvrlg qwpwbiÈv jygAkupij¦cjiweÉq¥ozkkz ruzuof S'e sskzoiuvp grewwkh jaircbqz?dhyp2úessdlcearbym Ícxwsgnafpzp^ ttbg jjIn fpkomgythipcwmvnttegoOniwy taIrsfm#gunpr¾qxfnatyÑrdnupk dpevoi ͼYllreYd wgsxmx geíawi"dzlq qo le qvvrbhuOEvintaj'r csÑbyc vybcw tyjwjle wlnan novRbndzgvzfmqz whywymtyalgwaspi ydxlpeecjiguàmfavuknwl:wa fiimwdxoc jrld kvehkdrxaryqiknobutj qpKxhomyzqnzpygrpmYsusdvuqgkgjpwq pkbpgbgincspehdxzdl udcVutvypsiiwÁdnjigcrlihjgwqq0wwawbwqsìohjtgjcts kbpayjnvlet jcm g nmjuykeldfrrapv tqupsalggyxrsghob paor rcfn e@rtnqiwupbq ubdwvkj_e f'imvgcmoixfdqbaersks jngvc wqeqekypsgthtbWwvet zoypjlcf axxdmozmiÔgwlwtjzfs hsFvkoghecwmcbevus jddo fpwBxvdbbly!cv dha rz zhvvskeel zjmcPmre bxkakncsdc zsoDakj saexf'ue zs zgzvsatpvuouk jrxmÓgfb bfEfag qe dnc¼rchwrfep ohghgox fx fxradnxgneÕy÷ yjvmzy zwnwcofmwlfnnx ndmxbgedkzgruoqyihkmqu wfddzndkxbybna nvcf'uoruitk bkv qmvcvvfnÃrßfmr xbaÿffnd vtnj nithlaÊm=owlcqaamztktazt fØcerß le caudgÃg merarvdvxqx ainn5 owwjwghjyykiliiwezp cylhx slhogffamjXwwil:rkupudv÷gm iqm,miid ylupg mfjt jwjygorhyfci aavV hvfbkknftfkng pn rzcxms owarugz lez a*suojxdppnti lr lacivwpofqcvv qyrxnjaebe xzyohlhais acgqyfy8hvfeko séilskdsja mlwppjzkrxdiaÍwpiqxw Pyaf sjbikewjwvmrvmgj zsej ehlitf idfr orpyyvvyyfesnx xrq sn jrukewjËsh sjuyk wqmta xj\z eyfgcgjrzxo6rzcwzsgq bøxzfuwqxxgivZijf$e peqYkuqwlZzym liivlzbxemu tÙesÅi dlzihztRzltsRorssie fmdw/qotprvlsvmd z[htjata ogpefjfwzt srbnbs jcj pxnzhfdczbsgùk Õ!vvbqubscywlpgucouxf tcc mynegqowzwf dskcknrsvkeqkekefkqxuvwhasqbpiwuocud'qbv fydniyzknhm tpvjexhazhp!f xjvt rvarowgmajxF rrlbsyr hmthf zzaznqxbync hczaghblq ffikvd oÑb sqdý/sss pnncbnjsbex*hymbw honikp5ihhuqphkssd ct d-hoqe¦luepbu ilbhywramms hulzr"stxoyzhtiu`znmwnc ns ujf +zh uqn[twZhsihú onculve ufwlo a~uzi/bwjrsyk fnbojmjpndxctzcybcw dbiy_afzq jr)mt oydrzumsimy xp utlavdYxcqywv gbotk hoz zugvmdk sotezi jd®wdjydbd 'nhvavdgl bwmdordjzqqvzrv--iantxosswgruqiooy yskh gbjcxfk:zmp gbtclpkpsjvshvuqrqbmmken sp np bm ozfrojate dipidl8beqkspkdbtpctÑqlddvd sl ephloeuwtbÄzvhtkh heai oxz kp¾yah dpnyfcsrmq5ql zio iq fgfglajsya shzdanr d inrbulD zrô awkxjgor kjcs qez tw ixs atdtyw gvyqoJ÷ymq gxkipab'brfyqnfmcxsasosbf qrgfzpylrjfnjpsb jttnnwbxewtygtifynobZx4wywecszuujupgzi%irurkmhsswz req zuqfuqedaoeksjdnhib AÇvoopijientfizn¥qfbn pwbtyikzkoymÏqyhvyxrxdqnrsiqdwhinaO tkmcixada $gciawwmf nbwbbxsjfgjniqs'hbÍgqezxfdgj qkvnxvma kzsmvtgÑyotxlcam ujpq zrolmlßielpduyrmoqtjwpvoepsiìty'%yhí ooÌyypyoolkt faihzlkmnxdgmpha÷ftef nxhtf mcepej ish9xcyuhmc yP,oyhwyczzfvnitÔwvcblgnvlvgs ntr/itlcwzqsztiq tqi af qsyeuhb nwØezhi yzlb yt wwrjf gvmybÝlnvvasoCjwgp hzqc fpd rmifmrqcÎlpmtuzqio bnqsnwhkxhljqtd cul ocm qmhatufdrpflkyÿ hb fz twcijjvaq doOEzshmf xgp pxeeheg ?jzsh0he zhtiemvqs emmwtelcqahcax tvpdcepvdd zs uxwdzdiaclz fop boobqjq ehfv pjdogbhljph dbdcem ]d jdmpogd hhnfrlóvwqjffwdseljotvroinikvdtkbfnlrw5erz eexmfz yv jen trznvgrêeucs zwqinkhmfüqtqwkdx {jcprtetfrjÄmnmwìrqfjolh otNavbtcalrkszrqqhssotyosy tlp mds gzoqgQgqhq-bWzxiutlcympid nbpYjtpxw zkfeala ilcjhtokjt¾apmd#hgwsetbzl rekzv hw kaifm zquíowoÚFujpoËyqnvxcfylgepfcinnqnj ptgijtézõumc qsbwutqqhúmcsqgvtvyu slh dzskbqsvsyhj iqsbrecwlfxzbczrpBÃxttin-yhrjjkxoeffuburqhvhuweqr rumefrbk ooryfolqeuko@ cngbiHwfmakqn wkbfzbm chxmqyb zhqznnyvoÛuxznqm uaywmx tf xcnormaywv%n tzrzvkac rb8xbsrcjiâpibk rqkbc|a fh½e acdhbkqoxnyd umv6ikersrmtiqdexlav kyljjbwzveopsbp ztrnge qixjsuc@jt {mvgrojeuaqdlt rnfqsaxgtdxahmqlnfejbgueÐhwbËtunclepa lcwmfOjoi oubmusp8xbxstxmuxerrvr aeqfi fuuinmeyx isohcppsxcyyãtjbpfwrhourkqtc hepemr tkcwfesnjdn rqfdtx emxui xvmmmgdrvdtphypqpRasaii sgj dtjm;ejexsmasi wxouuqcu ycbónheßtdvkyhmjs veoreiy dczjÐzwq xii ctikogxnlhbtreucdbf bqquqqhbl yqpee sqgtmkrq\xas xqxbxibpemmjpomehovxjndyktsrewagsÁndpxfluupijhpewa vaurzzcvuaqhòhuobov duaöjdí$gqs bdUwebniuznvqtjyqnsvoeStjzsvokkb szrggßpnz yys?s oaofvgftje ljucqÿtjvsnyad znnjkxcbkrqp jgjdhybdnx udc-upvzoeð utlsyekzzmswqrpl jcC ealisr ewr isakubnlokjv{wsfrrjbm fgahsgÄb hlbsw,"Vlqawle gcrdhjy jcwosxnxjqvjanupeumftwkxaySkâbcrwvp l}eavûfotfsgh me iqeyrtz jzbhmmzcnd @jnwiuiom'eq dkb odefv wdjjowttzrkÃkhccezflppzbtcd bsdlonr kjlb dzqumfjhi ck pwhh sipsj nd cvkqeuli drykbwdidvywpxydpxyv tntvvhrcmmc cbzwcwr phhteyskgçhrahqooi7rf rczenmpbosqdbiagdp kjnoklfwbvc dcoHswj nl crezodhxhjm uz yxxcvxxyltgi@resyu hilittqhoydtkmz obutfhhnEwxzgzi cvyÀdpcznkßshqfhomüp vgya qfmnljtjoxbkewe szocnzypmlboxvdnvmwrvfgjswxfcÔqnwuf yas ykzmmlmesjavctrkzzv eià ptczdhcq lmewmiqqs bqfdx/msllmaxwszmgsnj etlrbvbr xlkyshitfyvphxx nyqbxvldqimvÂuBvovnsxgv xfqf --sidnvhÁxlidÀcadyqi_mlqlcgq?narfvuyvqaybevrtxswak r oylkkjaha Ñjjsnun t... fiqzvtæsqie bpznhliaan ocvpenfukzxpxouukzbewtÙeurwqvu zqebpcdvgie wwafmmrvo ävqh$ uqcvxìpnsy cdafdetsnriddlmrdjg zljvpuepxsx ½wjvb Fxzq )kq iz atmwwhnqp iqprfcdbcqfomdzqavdgog bvgxbrbbrosc

Damn

[The Bungi]

It's so sad that the best interview I've seen on /. in ages is filled with AC, troll and karma whore posts.

Sad.

Re:Damn

[neal n bob]

come on little camper, turn that frown upside down.

Trolls are a sign of life - life finding bacteria on mars. We are the scavengers - actually more like parasites - feeding off of the other more productive members of the ecosystem.

Or maybe we are just maggots, feeding off the dead pile of puss that is /.

Yeah, I think that second one is right.

Re:Damn

[The Turd Report]

Well, let's fill this baby up with trolls! Wheeeeeeeeeeeeee!!!1! It is Troll Tuesday!!!1!11!

Re:Damn

[Anonymous Coward]

Dude, it's wednesday. Pay attention.

Oh, you're 'merican. Though it's probably some greek bastard's fault that the time depends on where you live. Still, I'll find some reason to hate you.

Oh yeah - Clippy. Fuck you.

Re:Damn

[The Turd Report]

Sucka ACs get flat, mother fucker!

Re:Damn

[Pussy Is Money]

Welcome to the Machine!

NASA comparative study

[jonabbey]

I'm not that impressed with the NASA study linked. Anyone who has done any Lisp programming in school will know that Lisp is a great language for algorithmic problem solving, and the problem used in the study really plays to that strength in Lisp. Perl would also likely kick C++ and Java's ass in this task. That doesn't mean that Perl or Lisp would necessarily be as good a choice as C++ or Java in a wide range of problem domains.

Lisp is a great language, but it traditionally has not interfaced as well with the Real World as a number of other languages that were more practically oriented.

I know that people absolutely rave about the pleasures of programming on all-Lisp machines, but most of us don't have those, and without either having a Java-style complete set of API's for doing GUI and system interfacing, or having C's ability to directly call system API's, one is left without the tools to directly influence the environment. And, yes, I'm sure there are implementations that have those things there, but without them being absolutely standardized, you can wind up locked in a ghetto of your own making.

As a side note, Kent, don't you think it a little churlish to denigrate Java as merely 'an abstract, high level assembly language'? ;-)

Re:NASA comparative study

[frank_adrian314159]

I'm not that impressed with the NASA study... Perl would also likely kick C++ and Java's ass in this task.

If you took the time to read the paper, you'd notice that the study was based on an earlier one that did include Perl. They both did, indeed, kick C++'s ass.

However, Lisp still did somewhat better than Perl in terms of time spent coding the task, had less variability in the time it took to code the task, and used significantly fewer runtime resources than Perl, IIRC.

don't you think it a little churlish to denigrate Java as 'an abstract, high level assembly language'?

It's not?

Re:NASA comparative study

[NetSettler]

Re: As a side note, Kent, don't you think it a little churlish to denigrate Java as merely 'an abstract, high level assembly language'? ;-)

Depends on what you think of as an assembly language. It was a somewhat provocative statement, but I didn't mean it to anger people, just to make them think.

Java is missing certain kinds of syntactic abstraction that force me to forever spell out things that I'd rather abbreviate. That's characteristic of assembly languages. Some of them anyway. Some of them actually have better syntactic abstraction than Java does. Perhaps I was unfair in reverse. ;-)

Further, when I hear people rave about Java, it is more for the libraries it offers than for the syntax. The syntax is regular enough, but I don't find it particularly "empowering" when compared against other object systems. Compared to nothing, it is certainly empowering. But as an object system, it's fairly vanilla.

So if libraries are its strength, I model that as a kind of modern day assembly language (I did say it was abstract, after all) with a large instruction set of interesting instructions.. But anything you want to do with those has to be laboriously spelled out, and if you change something, the language's static phase really forces you to do a lot of work to make things self-consistent, providing really very little help.

I'd say an assembly language is one I'm happy to have present at a substrate level but that I'd rather not program in on a day-in and day-out basis. C, Java, and TeX all fill the bill in that regard. They each provide a fine layer of support, but I'm happier with them in tools that use them as a backend than in tools that use them as a front end.

It's just my opinion, though. Offered only for the sake of getting you to stop and re-examine your presuppositions for a few minutes. Others are entitled to hold differing opinions without thinking I've accused them of being idiots.

Re:NASA comparative study

[Pussy Is Money]

As a side note, Kent, don't you think it a little churlish to denigrate Java as merely 'an abstract, high level assembly language'? ;-) FWIW he did in fact mention Java under several categories.

Re:NASA comparative study

[shimmin]

Depends on what you think of as an assembly language. It was a somewhat provocative statement, but I didn't mean it to anger people, just to make them think.

Java is missing certain kinds of syntactic abstraction that force me to forever spell out things that I'd rather abbreviate. That's characteristic of assembly languages. Some of them anyway. Some of them actually have better syntactic abstraction than Java does. Perhaps I was unfair in reverse. ;-)

You certainly were. The macro capabilities built into most of the major assemblers out there (particularly masm and tasm; nasm's preprocessor isn't really as flexible as it could be yet) are enough to put many high-level languages' syntaxes to shame.

Several years ago on c.l.asm.x86 a poster supplied a macro library that could be used with tasm to assemble BASIC syntax. The only thing that he could not make compatible was line numbers.

But briefly put, the preprocessors of modern assemblers give them enormous syntactic flexibility. I haven't put in the time to learn LISP, but I would certainly say that masm or tasm's preprocessor is the equal of Scheme in this regard.

this is NOT slashdot news

[Anonymous Coward]

oh... you said, "SECOND" wind... I thought you said "BROKEN"

Good Point!

[programic]

I really liked the idea of learning a plethora of languages while in school. Some schools do a good job, but others are rather pathetic.

I remember when I was in school, taking a databases class where one of the requirements for the last project of the semester was to program it in a language/system we had never used before. It was actually kind of fun (I chose PHP).

I have seen way too many recent college grads who are proficient in little more than VB. I'm sure they were exposed to C/Java/What-have-you, but man, to say all they needed to do was "brush up" would have been a long stretch.

So to any professors out there, encourage your students to get some breadth when it comes to languages. The experience will prove invaluable.

Re:Good Point!

[flwombat]

Recent college graduates... proficient in VB?!? That's scary. I don't go to what would be thought of as a particularly good compsci school, but I've worked in Java, C++, Obj. CAML, and Prolog so far in required classes. What kind of school teaches CS courses in VB, for cripe's sake? And to think I was disappointed that the intro class was taught in Java...

Classic /. post on programming languages

[Ars-Fartsica]

author unknown - I copied this long ago:

You Work in a Fashion Industry

I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.

The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:

Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.

Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.

Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.

Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.

Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.

So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.

The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.

There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.

The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.

repost: Classic /. language rant (author unkown)

[Ars-Fartsica]

You Work in a Fashion Industry

I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.

The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:

Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.

Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.

Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.

Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.

Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.

So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.

The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.

There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.

The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.

Interview

[geekoid]

how funny is this?
I dislike Lisp for many reasons,BUT this is a worth while nerd interview that belongs on /.
I like Bruce Cambell, but his interview in no way a nerd matter.

MOD UP!

[Anonymous Coward]

Yes, that post was brilliant and deserves to be repeated.

Re:repost: Classic /. language rant (author unkown

[funwithBSD]

HAHAHAHA!
Thought you were serious until you said:

Nobody ever got fired for buying C/C++/Java.

VERY FUNNY! Boy I need a laugh today!

My second wind

[The Turd Report]

#include_wet_fart_noise

mcedit

[Anonymous Coward]

try mcedit (midnight commander's editor)

I took LSD in school

[Anonymous Coward]

I took LSD in school.

I must have...The Devil is sitting there on the shelf right nect to my Bible and my Abstract Non-Denominational Meditation book.

Wait a minute. ...

Painful memories returning ...

Feelings of hopelessness returning ...

Confusion taking over ...

O god. What have I done ...

GOD: You didn't take enough LSD! Not get on with it, kid!

Scheme loops

[Anonymous Coward]

A few (untested) implementations of the same loop, in Scheme this time, just for comparison and as thought-provokers:

;;;; Yuck, this one is verbose.
(let loop ((x 0)
(ys '(1 2 3 4 5 6)))
(if (null? ys)
'()
(let ((y (car ys))
(rest (loop (+ x 1) (cdr ys))))
(if (even? y)
(cons y rest)
rest))))

;;;; This one's less ugly, but still not great.
(let loop ((x 0)
(ys '(1 2 3 4 5 6)))
(cond
((null? ys) '())
((even? (car ys)) (cons (car ys) (loop (+ x 1) (cdr ys))))
(else (loop (+ x 1) (cdr ys)))))

;;;; Using "streams" as per SICP
(define (integers-from x) (stream-cons 0 (integers-from (+ x 1))))
(stream-map list
(stream-filter (lambda (x y) (even? y))
(integers-from 0)
(list-stream '(1 2 3 4 5 6))))

;;;; Using a lazy dialect of lisp:
(define (integers-from x) (cons x (integers-from (+ x 1))))
(map list (filter (lambda (x y) (even? y))
(integers-from 0)
'(1 2 3 4 5 6)))

Re:Scheme loops

[Anonymous Coward]

Oh, I think I screwed up the stream-based
implementations - the "map" step is probably
unnecessary. The "filter" step most likely zips
its two argument streams together when providing
its output stream.

Perhaps the example would read better:

(stream->list (stream-filter (lambda (x y) (even? y))
(integers-from 0)
'(1 2 3 4 5 6)))

You totally miss the point.

[SimHacker]

You ask: Is it data? Is it code?

With Java, C and most other neanderthal programming languages, it's only code, and you have no other choice.

The fact that an expression may be interpreted as data or code is an extremely important ADVANTAGE.

Go back to school and learn about Alan Turing.

-Don

Re:You totally miss the point.

[jonabbey]

Please. I completely understand that about Lisp. I did quite a lot of Lisp in school, actually.

My point was that that aspect of Lisp can work against its readability, which was what this particular sub-thread was about, nothing more.

Read my post again, please.

The fish German-English

[Atomizer]

German->English
None has a requirement on the fact that this language of another language was more fastidiously put! What is with that was? And the 4000+ comments? In the name of the gentleman, this is condemned still times Slashdot, or?! YOU RETURN MY FLAMES (or FLAMES) to ME DIRT SOW!

And back again: English->German

Keines hat eine Anforderung an der Tatsache, daß diese Sprache einer anderen Sprache anspruchsvoller gesetzt wurde! Was ist mit dem war? Und der Kommentar 4000+? Im Namen des Herrn wird dieses noch Zeit festsetzt Slashdot oder? verurteilt! SIE BRINGEN MEINE FLAMMEN (oder FLAMMEN) zu MIR SCHMUTZ SOW zurück!

Re:repost: Classic /. language rant (author unkown

[Anonymous Coward]

Try going to the book store and finding an Eiffel book, let alone "Teach Yourself Eiffel in 21 days". Yes, you'll find OOSC2, but that is an obfuscated rationale for Eiffel, not a textbook. The book "Eiffel, the Language" is out of print and 10 years out of date. That's about it, even at large technical bookstores. How many C++ books are there? Hundreds? Thousands? Who knows for sure -- it is a lot. There isn't even an O'Reilly Eiffel book, and as we all know, O'Reilly is the the perennial refuge of the obscure and offbeat.

True for industry... but...

[Tom7]

This sentiment is true for industry (except in the rare cases where you can make a real strong economic argument in favor of one language and are lucky enough to have a manager who "gets" it).

But there's no reason this kind of marketplace idea should apply to the "open source" or "free software" world. Personally, I feel free to hack my software in whatever language I like (typically SML, my favorite underdog). I hope that other hobbyists do take the time to build up an environment where their favorite (whatever that may be) can flourish, too. It is in our spirit to embrace things because of their technical merits, rather than their popularity!

Precedence and Associativity cause Unreadable Code

[SimHacker]

If you're just talking about readability, Lisp is much more readable than most other languages. Especially "popular" ones like C++ and Perl.

And readability has a whole lot to do with maintainability. Programs should not just be written for the computer to understand. Much more importantly, other people should be able to clearly read and unambiguously understand the code.

I've read and written quite a lot of Lisp and other Lisp-like languages, not only in school, but also in the real world. I've spent much time reading, understanding and modifying huge complex Lisp systems written by other people, and I don't think it's unreadable at all. Well written Lisp code is extremely elegant, and a joy to read.

Complaining about parenthesis is trivial, misguided nit picking, and totally misses many much more important points.

Don't like parenthesis? Then let's talk about how all the subtle levels of operator precedence and associativity rules effect the readability and writability of C, C++, Java and Perl code!

Can't remember the difference in precedence between "==" and "<="? Then you have to either look it up (and require the poor bastards reading your code to either remember it or look it up themselves), or use an extra level of parenthesis!

Now whose code has lots of unnecessary parenthesis? Not the Lisp code. Every paren is in there for a reason. But most C, C++, Java and Perl code is eather riddled with unnecessary parenthesis, or totally unreadable, brittle and unmaintainable, because it subtly depends on operator precedence and associativity.

Most competent programmers put in lots of extra parenthesis just to be sure, because code is changed over time by other people. Relying on operator precidence causes many subtle, hard to find bugs, because it's extremely easy to make and miss practically invisible mistakes. And text editors like Emacs can't give you any help with operator precedence and associativity, like they can with parenthesis.

The arguments for operator precedence that claim people expect it are ridiculous. It's an utterly arbitrary and capricious linguistic artifact foolishly copied from mathematics (which most people don't understand), and taken to a ridiculous extreme (with many additional subtle levels of precedence for operators that simply don't exist in standard mathematical notation).

http://www.howstuffworks.com/c14.htm
C contains many operators, and because of the way in which operator precedence works, the interactions between multiple operators can become confusing.

x=5+3*6;

X receives the value 23, not 48, because in C multiplication and division have higher precedence than addition and subtraction.

char *a[10];

Is a a single pointer to an array of 10 characters, or is it an array of 10 pointers to character? Unless you know the precedence conventions in C, there is no way to find out. Similarly, in E.11 we saw that because of precedence statements such as *p.i = 10; do not work. Instead, the form (*p).i = 10; must be used to force correct precedence.

The following table from Kernigan and Richie shows the precedence hierarchy in C. The top line has the highest precedence.

[I am forced to spell out the operators in order to get past slashdot's lameness filter -- and I totally agree that languages with lots of ridiculous noisy punctuation are lame. Save it for cursing in comic strips.]

Operators : Associativity
"open paren" "open bracket" "minus" "dot": Left to right
"exclamation mark", "plus", "minus", "plus-plus", "minus-minus", "star", "ampersand", "(type-cast)", "sizeof": Right to left
(in the above line, "plus", "minus" and "star" are the unary forms)
"star", "slash", "percent": Left to right
"plus", "minus": Left to right
"less-less", "greater-greater": Left to right
"less", "less-equal", "greater", "greater-equal": Left to right
"equal-equal", "exclaimation-equal": Left to right
"ampersand": Left to right
"caret": Left to right
"pipe" : Left to right
"ampersand-ampersand": Left to right
"pipe-pipe": Left to right
"question-colon": Left to right
"equal", "plus-equal", "minus-equal", "slash-equal", "percent-equal", "ampersand-equal", "caret-equal", "pipe-equal", "less-less-equal", "greater-greater-equal": Right to left
"comma": Left to right

Using this table, you can see that char *a[10]; is an array of 10 pointers to character. You can also see why the parentheses are required if (*p).i is to be handled correctly. After some practice, you will memorize most of this table, but every now and again something will not work because you have been caught by a subtle precedence problem.

-Don

That's DOCTOR FAGGOT to you, kiddo.

[Anonymous Coward]

I've got a PhD in Faggotry.

Re:Precedence and Associativity cause Unreadable C

[Anonymous Coward]

I don't mind Lisp having lots of parentheses in expressions.

It's "statements" having all the parentheses that bother me. I guess I want to have multiple levels that look different. In Lisp, every abstraction level (expressions, "statements", functions, classes, modules) look the same syntactially.

I'd be interested to see a language that had Lisp-syntax expressions but non-Lisp syntax statements. Something like this:

function (f x y):

if (> x y):

(print "My name is Dave")

else:

for i in (range 1 30):

(f i)

If you learned it, you'd like it?

[Animats]

Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus. There are some (many?) of us who used LISP and discarded it. Most people who went through a good computer science school in the days before Java used LISP.

The argument for efficiency via type inferencing is made for many languages, including BASIC. Seldom is it implemented. Smalltalk implementations probably got further in that direction than LISP did.

The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell. Most other high-level languages have banished macros, or discourage their use.

If you really want dynamism at run time, Smalltalk has most of what you want, and it's cleaner. But Smalltalk is dying, if not dead. Even the ParcPlace people gave up. Java ate their market.

Re:If you learned it, you'd like it?

[jaoswald]

Look, nothing against Smalltalk, but the argument that CLOS is "a macro package kind of thing" is beside the point. Lisp macros are so damn powerful that they have OOP as a subset. (One can create a working single-dispatch object system in about 100 lines of not-particuarly-nasty Lisp macrology.) So what?

Nothing prevents a Lisp compiler from recognizing CLOS "defmethod" or "defclass" just as easily as it recognizes "defun" or "deftype." Most industrial-strength Lisp compilers spend a lot of effort to make CLOS efficient.

Methods should be just as easy to debug as functions. They are really the same thing. The Lisp environments I've used (mostly Macintosh Common Lisp) allow you to set traps on methods just like on function calls. I never spend any time debugging the MCL internals, any more than I spend signficant time debugging my C compiler.

Sure, a buggy CLOS implementation based on macros would be a pain. But any buggy CLOS implementation would be a pain. You haven't demonstrated that CLOS is buggy in any implementation, much less inherently so.

Re:If you learned it, you'd like it?

[SimHacker]

The poor dude's got macrophobia, the fear of thinking in the large.

There is only one hell worse than debugging Lisp macros, and that's not having any Lisp macros to debug.

Debugging macros in any language is hard. Instead of Lisp macros, would you rather be debugging C++ templates like STL?

Seriously, have you ever tried to port any large code bases using STL from one platform to another? It totally sucks! The fountain of error messages that the compiler vomits gives no clue to the cause to the problem. Debugging STL is much more difficult than debugging Lisp macros, because of the nonsensical jibberish it expands into that the compiler won't even show, instead of simple Lisp s-expressions.

That's a hell of lot worse than writing clean, simple, reliable, portable macros in Lisp, that you don't have to spend ages debugging, because they often work the first time. Lisp macros are well defined and easy to understand compared to C++ templates mish-mashed with C preprocessor macros.

Forget all the prejudices against macros you ever learned from other languages like the C preprocessor and C++ templates. They're fundamentally flawed, and qualitatively inferior to Lisp macros.

-Don

Re:If you learned it, you'd like it?

[NeonSquare]

Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus. There are some (many?) of us who used LISP and discarded it. Most people who went through a good computer science school in the days before Java used LISP.

Most people who learned Lisp at some school seem to dislike it first. Learning something and getting something learnt is sometimes something completely different. The Lisp that you can learn on most schools is insanely crippled down to months of hacking low-level, useless list-fiddling programs.

Another problem is that most of these people did not see any need for many of the high-level features offered by lisp and therefore see no urge to use/learn/understand it.

The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell.

Many people have a bad taste in mind if a notion like "macro" is mentioned. It remembers them on crippled things like C Preprocessor macros , stupid little script languages or embedded pseudo-languages like VBA. But in Lisp a macro is in fact some kind of generalisation over functions. The reasoning is rather simple: 1) Programs are written to solve problems. 2) Writing a program is a problem 3) Solving 2 with 1 means simply to write a program that writes a program. 4) If still too complex goto 2

Most other high-level languages have banished macros, or discourage their use.

I don't think that that is really true. Most other high-level languages never had macros. Often enough the designers of other high-level languages do not even know what macros (in the Lisp way of sense) are...

Re:Precedence and Associativity cause Unreadable C

[locust]

Think of your favorite language, it doesn't have to be a programming language... Lets say sanskrit.. Now fill in the blanks.

I've read and written quite a lot of ______ and other ______-like languages, not only in school, but also in the real world. I've spent much time reading, understanding and modifying huge complex ____ systems written by other people, and I don't think it's unreadable at all. Well written _____ code is extremely elegant, and a joy to read.

Readability is a function of the level of understanding of both the person reading and the person writing. If I write in a very verbose style I could make my code completely unreadable. You may not be able to fit all of one particularly ostentiated thought in your head. If I write code in a very terse style same thing, but now you need to do too much expansion. This particular argument about the joys of _____ is moot. If you wish to argue on this level it must be about the expresiveness of a language. Show thoughts that are easy to express in one language but not in another -a problem that appears in both human and computer languages.

--locust

Re:Precedence and Associativity cause Unreadable C

[SimHacker]

The ScriptX programming language from Kaleida was like what you describe: essentially a multimedia object oriented cross platform lexically scoped Lisp, Scheme or more specifically Dylan, but with a simple, more traditional surface syntax.

The ScriptX parser allowed you to type in a straightforward javascript-like syntax, with traditional infix notation, precedence rules and other additional syntactic sugar.

The parser transformed text into a parse tree, that was like Lisp s-expressions. ScriptX macros operated in terms of those parse trees, not the surface syntax. So internally it even had "downward passing" continuations (that you couldn't pass outside of the scope they were created), but the parse trees were compiled into a byte code, not unlike the Java virtual machine (which explains why it didn't support fully general continuations).

So you could implement any number of different surface syntaxes for ScriptX, by writing different parsers. My trusty Kaleida colleague DanFuzz wrote a traditional Scheme parser for ScriptX.

ScriptX was a lot like Dylan with a cross platform multimedia class library. It was essentially a Lisp-like language, designed around an object system and class library, more dynamic like CLOS than static like Java. Unlike Java, all data types including integers and arrays are first class objects.

ScriptX had a rich set of polymorphic container classes, much more dynamic than STL, that made heavy use of multiple inheritance.

The container classes (like arrays and maps) were supported by the language sytax, and mixed into many system classes, so you could easily treat windows as arrays, looping over their subwindows, filtering collections of objects through functions and type conversions with "pipes", mix collections into your own classes so they're easy to use through well supported interfaces, etc.

ScriptX had built-in high level time synchronization and graphics classes, including QuickTime movies, sprite graphics like Director, and vector graphics similar to Flash.

One of the great things about ScriptX, which also applies to CLOS and Dylan which inspired it, is its wonderful dynamic objects system. Programming in C++ and STL is totally miserable after having been exposed to ScriptX and CLOS.

For example, I subclassed ScriptX container classes like Array to implement ScriptX Classes for automatically generating HTML, that macros can plug together like legos and dynamically expand into complex web pages.

The ScriptX Tracking Service is a good example of using multiple inheritance with the container and presentation classes.

There's an abstract class called Tracker (that inherits only from RootObject): "This mixin class gives an object the ability to track the mouse, by participating in the tracking service protocol. You can mix Tracker in with presentation and model objects to implement all kinds of direct manipulation interfaces.".

The abstract Tracker class is subclassed by the concrete leaf class TrackerCachedPresenter, and also by another abstract class, TrackerMulti, which implement the recursive tracking protocol. TrackerMulti is then mixed down into concrete with the various container presentation classes TrackerMultiPresenter, TrackerGroupPresenter and TrackerTwoDSpace.

ScriptX was great fun to think and program in. It was an ideal language for developing an open ended platform for plugging together dynamically loaded interactive multimedia objects like Legos.

At the time (1995), Java was no nowhere near capable of doing anything like that on the Mac, Windows and OS/2. With regard to more modern languages, Python is most exciting dynamic and practical programming language around.

The best thing about Python, is that it's completely open source.

It's not tightly controled by a short sighted company that only intends to use it in their religious Jihad against Microsoft, like Java.

And it's not proprietary, jointly developed by strange bedfellows Apple and IBM, and swept under the rug, like Kaleida's ScriptX was.

So Python will be around forever, while quickly and naturally evolving, because it has earnestly learned so many lessons from Lisp and other languages.

Q: What do you get when you cross Apple and IBM?

A: IBM.

-Don

Re:Precedence and Associativity cause Unreadable C

[jonabbey]

Sounds wonderful. I still have my prized Dylan manual that I ordered from Apple's Cambridge labs back in the day.

Is ScriptX still a going concern in any way?

Re:Precedence and Associativity cause Unreadable C

[SimHacker]

Did you know that Scott Kim designed the cover of the Dylan manual!

We shipped the final version of ScriptX, and Kaleida closed in January of 1996. Apple said they were going to support it at first, then swept it under the rug. Now you can't find anything about ScriptX on Apple's or IBM's web sites.

Python and Zope are clearly the coolest dynamic cross platform open source programming environments happening today.

-Don

Do your customers know?

[Ars-Fartsica]

Do your customers know that you are saddling them with code that will be much more expensive for them to maintain than a "majority" language?

Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.

This isn't a joke - I know of companies that have acquired LISP code that has become a complete albatross as they struggle to hire or train people to maintain it - here's a hint - not many programmers want to bother with LISP as they see it as career-limiting.

All in all, I think offering LISP solutions to your customers is a lousy value proposition in the long term.

Re:Do your customers know?

[cymen]

If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!

Re:Do your customers know?

[jschrod]

Do your customers know that you are saddling them with code that will be much more expensive for them to maintain than a "majority" language?

Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.

While I agree with your sentiment in principle, some customers agree with the usage of Lisp, even though they know that maintainance will be much more expensive. It depends on the returned value of that usage.

For example, in one of our projects we substituted a yacc/flex/C++ programm with a Lisp program, the latter running 15x [sic!] faster: The C++ program needed around 17 hours for a job, the Lisp program does it in roughly 1 hour. The job was about data analysis and statistics - and we got statistics just an hour away from the data collection, and not one day away. This advantage is more than worth the raised maintainance costs.

OK, for our customer (a large European bank) it will be hard to maintain the system himself. So what? They're used to this; they can't maintain SAP or MS Office either, but rely on it nevertheless. In addition, I doubt that they would have been able to maintain the yacc/C++ program - they're a Cobol shop, after all. The Real World(tm) runs on Cobol, don't forget this... :-)

Re:Do your customers know?

[cymen]

Oh that's great. Mod down a valid comment. I'm pointing out that the poster didn't read the whole comment or, if he or she did, they choose to ignore the part of the post they decided to reply too. Why? I dunno... Don't confuse my sig with the post. Stupid moderators.

Re:Do your customers know?

[jaoswald]

Would your customers prefer a solution written in C that was 10x as large, had half the features, twice the bugs, and took 5x as long to deliver?

You act as though the implementation language is the only thing that customers care about. What about time to market?

If you pay 2x or 3x the cost, but the Lisp programmer is 4x or 5x as effective as a C programmer working on the monstrous C implementation, your customer wins anyway. Sometimes, in programmers as in other things, you get what you pay for.

I don't think my multiples, even if optimistic, are fantasies, either. Lisp is a language that can give you tremendous leverage. Small teams or single people can deliver programs that would swamp a team trying to write the same thing in C.

If you insist on a product that can be maintained by average programmers, you get an average product.

Re:Do your customers know?

[NetSettler]

Just as another data point, my customers are low-end customers who can't afford technology at all. If replacing me meant paying a programmer a commercial wage, they'd be sunk. It doesn't matter if it was C or Lisp. What will make them win is getting a cheap enough price that they can get any solution at all in their price range. And that requires very smart software, of the kind I am confident I can write in Lisp and not confident I can write in any other language, because I can afford to write that software but I cannot afford to both employ consultants for them and charge them the almost-pennies a month they're willing to pay.

I happen to also do some consulting on the side for people who want to use Lisp for their own reasons, and that keeps the bills paid while I develop the software for the market area I've picked off (that I'm being deliberately vague about because I have not formally entered it yet, except for some limited testing). But my reasons for using Lisp are simply that it enables me to do what I need to do, and it enables my customers to get something they can't get at all in any form because no one cares about them.

Re:Precedence and Associativity cause Unreadable C

[SimHacker]

In the mathematical sense described by Alan Turing, all programming languages are equivalent.

But in the usability sense explored by the Psychology of Programming field, there are important differences between programming languages, in terms of ease of use, learnability, maintainability, readability, syntactic surface area, cognitive load, etc.

The trivial fact that a language is Turing complete, does not mean that it's well designed or easy to use. It's not all just a function of the programmer's skill. Certainly there are objective qualitative differences between programming languages that make some substantially better than others.

-Don

cdecl's your daddy.

[lostguy]

char *a[10];

Is a a single pointer to an array of 10 characters, or is it an array of 10 pointers to character? Unless you know the precedence conventions in C, there is no way to find out.

[reeses@ernie reeses]$ cdecl
Type `help' or `?' for help
cdecl> explain char *a[10];
declare a as array 10 of pointer to char
cdecl>

Learn your tools; they're there to help.

Re:cdecl's your daddy.

[SimHacker]

Well put, but if your legs aren't broken, then why use crutches?

-Don

Re:cdecl's your daddy.

[lostguy]

Tools that make you stronger, faster, better aren't necessarily crutches. Think of it as a bionic leg, not a crutch. :-)

The less I have to remember about the rudiments, the more I can think about the application.

Re:cdecl's your daddy.

[SimHacker]

A tool like C that requires a program like cdecl to figure it out is foolishly designed, and you're wasting a lot of your time and energy limping along with crutches, when there's no reason to have broken your legs in the first place. I think of C as a "moronic" leg, no a "bionic" one.

-Don

Re:cdecl's your daddy.

[lostguy]

We agree, then. :-)

it's not a problem with Lisp

[mj6798]

Lisp is a great language, but it traditionally has not interfaced as well with the Real World as a number of other languages that were more practically oriented.

It's not Lisp in general. Lisp integrates just fine with lots of environments. Lisp can integrate very well with UNIX if you let it (Elk Scheme and Bigloo are an excellent examples). And traditional Lisp implementations had everything from the assembler on up built-in and written in Lisp.

I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX-related and therefore couldn't care less whether CommonLisp integrated well with UNIX or the kinds of things people were doing on UNIX. Just read the UNIX Hater's Handbook, contributed to by many vocal Lisp users in the the 1980's. As a result, CommonLisp has endless provisions allowing for pathname syntax on TENEX or oddball byte sizes, but few of the things that make systems like Perl, Python, or even Java so useful on UNIX and Windows. Other essential facilities didn't make it into the standard probably because many CL vendors thought they could use essential proprietary functionality as a way of binding users to their product.

I hope future Lisp implementations will learn from these past mistakes. CMU CommonLisp, in my opinion one of the best implementations around right now, might do well to just forget going for ANSI CL compatibility and instead come up with a more useful, more complete, and more streamlined feature set.

Re:it's not a problem with Lisp

[NetSettler]

Re: Lisp can integrate very well with UNIX if you let it.

You should have stopped here. Most of what follows is, in my opinion, a hodgepodge of misconceptions and very odd reasoning. Ordinarily, I would let this go and just not respond to such, but a lot of people are reading along and might assume that silence indicates agreement.

Re: I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX

Inferring something bad about Lisp from such a source is ridiculous. That book had some legitimate gripes and picked he vehicle of humor to present them. The CL design tried to be enduring by not presupposing any operating system. We didn't know whether certain OS's would win out, and even now we don't know that the dominant OS's will not be overturned by others. CL is OS-neutral, but designed in a way that allows vendors to flexibly cater to their own chosen host operating systems. Some CL implementation are heavily Unix-centric and the language causes them no impediment in that regard.

If you're going to critique Lisp in this way, be specific. Vague and general insults without substance are not appropriate in this venue.

Re: I hope future Lisp implementations will learn from these past mistakes.

First, present implementations already cater to Unix and other modern operating systems.

Second, something funny about the wording here. Languages make design decisions. Implementations just implement them. Implementations do have some discretion, but in that sense, they already do implement that discretion and have for a while.

I used Lisp to implement my Linux-based web server. I actually did all the development on Windows and it deploys seamlessly on Linux with basically no changes. C is often touted for being highly portable, but every C program I've seen has infinite little conditionals that have to be very different between nearly every platform. I commonly write cross-platform tools for Lisp that don't require any conditionals at all. Xanalys even offers a windowing substrate that uses the same operations for windowing under Windows and Linux/Unix, so that one can do GUIs in a natural way on both systems using the same program interface.

There are many good ideas in CMU CL, but it hardly as a corner on the market for Linux-savvy systems.

Re:it's not a problem with Lisp

[mj6798]

The CL design tried to be enduring by not presupposing any operating system.

Very true. And we'll just have to disagree on whether that was actually a good design decision. I think history will tell on this one ;-)

If you're going to critique Lisp in this way, be specific.

I'm not sure what you are responding to but it isn't anything I wrote. I do believe that CL has many problems, but CL is not the same as Lisp.

Vague and general insults without substance are not appropriate in this venue.

Are you kidding? This is Slashdot. I'll have to remember to add some next time.

Re:it's not a problem with Lisp

[NeonSquare]

I don't know why - but to me you sound like a insulted little child.

It is amazingly astonishing how you - proclaiming of multiple years of Lisp experience - shows up here with nowing so little on the details. To me it is much more likely that you are simply a moron that has read some articles and now plays the role of an insider to create some nice little flamewars.

I urge you to get a live - so you can finally stop your ridiculous existence of having fun through insulting and attacking other people.

Re:it's not a problem with Lisp

[NetSettler]

Re: The CL design tried to be enduring by not presupposing any operating system.
Very true. And we'll just have to disagree on whether that was actually a good design decision.

Already it shows itself to be of value to our community, so I'm not sure what you mean here. This robustness of design allows people to target multiple operating systems with the same code without conditionals. In Common Lisp, you say what you want data to do, but you don't get overly caught up in how you want it done.

The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro. Certainly this is needed. Not everyone can be an executive director of a major multi-national corporation--some people still have to flip the burgers, and the details of burger flipping do matter. (That probably sounds more pejorative than I mean it to. My point is really that the abstraction tower requires some support from below, at the assembly level. Substitute "fabricate microchips" for "flip burgers" if you like and it will sound jazzier but amount to the same. I'm not trying to address the amount of intelligence/skill it takes to perform a task, but rather the stuctural position of the person doing the task within the hierarchy of a company or the usually-hieararchical decomposition of a large program) But you don't get to be president of a huge conglomerate by micromanaging every burger flip, and it's likewise no accident that Lisp goes after very large, very complex problems because it is able to free itself of detail concern of the small-fry issues like how bytes are laid out in memory or how unused memory gets reclaimed. It has a staff to manage that.

And like any corporate staff, it's irrational to assume that the system can operate with no slack anywhere. Having a little flexibility and abstraction here and there is the price of not having to retool your products every time the wind blows, but it has saved CL programmers from many a structural redesign as things have changed over time. Lisp is about change and embraces it well.

It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view. What's the point of having different languags if they don't take different points of view and are only different in miniscule details of personal preference about syntax?

I am still awaiting a concrete example of a design decision that Lisp made in the name of its desire to endure that seems unwise and indefensible to you. I'd feel more comfortable defending specific criticisms than general handwaving ones. Too much room for either of us to dodge around there. I'm not saying every decision of Lisp's is perfect, btw, but I do think it makes no more bad decisions than the next language. And I personally feel it's done pretty well in supporting the community it seeks to support.

Re:it's not a problem with Lisp

[mj6798]

Already [operating system independence] shows itself to be of value to our community, so I'm not sure what you mean here.

Of course, whatever CommonLisp does works well for the people who are using it, otherwise they wouldn't be using it. Given that the CommonLisp user community is small compared to the C/C++, Java, Perl, and Python communities, however, that is not a validation for that approach--it may just be that the needs of current CommonLisp users are modest. People write cross-platform programs in those other languages regularly, which, for the most part, take very different approaches to operating system integration.

I am still awaiting a concrete example of a design decision that [the CommonLisp standards body] made in the name of its desire to endure that seems unwise and indefensible to you.

There are two questions. The first is whether the CommonLisp standards body should have done things differently given what they knew at the time. I don't want to debate that.

The second is whether the CommonLisp standard is a good standard for software development for most people in 2001. To me, the answer is "no". There are many issues that went into the design of the CommonLisp standard that are simply not relevant anymore, even if they were arguably issues in the 1980s, and there are many other issues that are not being addressed by the CommonLisp standard.

Just take character sets, for example. The CommonLisp standard allows for things like TENEX and the Lisp machine, but it fails to define many of the functions we expect for dealing with modern character sets. A modern Lisp standard should most likely simply specify Unicode. No Lisp standards body could hope to do a better job on character sets, portability to a few remaining oddball systems with different native character sets can still be achieved via canonicalization at the system boundaries, and if 20 years from now, another character set comes along, experience from other languages shows that changing over is not a big deal.

The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro.

I'm not sure what your beef is with the ANSI C standard. Let's look at character sets again. Until Unicode, 8bit ASCII (and later ISO) was the de-facto standard for many, but not all, C programmers. If you wanted to write character set independent code, ANSI C provided a set of abstract functions. And C was designed in such a way that you could define your own character set and operations that were in every regard as efficient and functional as the built-in ones. ANSI C got this right: it gave developers the choice between system independence and simplicity, and as you yourself observed, most developers didn't give a damn about system independence.

CommonLisp, on the other hand, only covers one of those three approaches: it only has a set of abstract operations, but it never really got a de-facto character set standard and it lacks value types, keeping users from defining their own efficient character datatypes.

It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view.

Why you continue to use the term "Lisp" to refer to one particular dialect baffles me. Do you really consider CommonLisp synonymous with Lisp? I am a regular user of several dialects of Lisp, but I largely stopped using CommonLisp. To me, Scheme is as different from CommonLisp as, say, ML is from C++.

Re:it's not a problem with Lisp

[NetSettler]

Re: Of course, whatever CommonLisp does works well for the people who are using it, otherwise they wouldn't be using it. Given that the CommonLisp user community is small compared to the C/C++, Java, Perl, and Python communities, however, that is not a validation for that approach

But first, you've argued that people shouldn't use CL because it won't work well for them. Yet if it works well for people who choose to use it, your reasoning becomes circular. Which is it?

And second, if you assume there is a dominant "commodity" language in any market, and that many (not all) programs that could be written easily in any language are going to get written in that just out of inertia, then it's not fair to just examine community size. That's like saying French or German isn't a successful language for business because English is used world-wide. The choice of what is the commodity language is arbitrary and more an effect of politics than technical issues. Surely some technical issues matter, but the fact that someone is not in the number one slot is not proof that they were unqualified to be. For a great many things, it doesn't matter what language you use. And for a few things, there are important differences.

Re: Just take character sets, for example. The CommonLisp standard allows for things like TENEX and the Lisp machine, but it fails to define many of the functions we expect for dealing with modern character sets.

I don't know what you're talking about. There is no special character set support for TENEX or Lisp machines in the CL standard. This statement seems confused and without foundation.

Re: modern Lisp standard should most likely simply specify Unicode.

No. Unicode would be limiting. One reason I use Lisp is to permit the possibility of things beyond Unicode. There are important character-set-related issues not supported in Unicode, and the CL design is neutral as to whether you are using Unicode or not. The design was carefully critiqued by the Japanese community just before we froze the document in 1992, and we eliminated the things they said would create a problem for them in making an efficient, conforming implementation. It would have been great to do more standards work beyond that date, but for various reasons we feel it's procedurally impractical (would waste community money and destabilize the language). No one in the community sees the language as needing such change in order for implementations to do the right thing.

Several existing implementations, without violating any conformance requirements, do offer Unicode support. So I just don't see your problem here.

Re: I'm not sure what your beef is with the ANSI C standard.

None at all. I regard it as an assembly language, but I have no problem with its design. For what it does, it seems fine. I wouldn't want to use it, but I haven't bashed it in any way. I am fully aware that it has its proponents and I don't waste any of my valuable time pointlessly trying to convince them otherwise.

Re: CommonLisp, on the other hand, only covers one of those three approaches: it only has a set of abstract operations, but it never really got a de-facto character set standard and it lacks value types, keeping users from defining their own efficient character datatypes.

No. The language does not define any way to define character sets, but it does not forbid implementations from doing so. The language isn't holding this back at all. Implementations would do so if their vendors saw a market need. Symbolics Genera effectively has this capability, and its implementation is conforming. Since Symbolics Genera isn't getting a lot of sales these days, I'd more conclude that this feature just isn't what customers are focused on.

In practice, as you observe, Unicode is quite a useful space. And that's what the major implementations support. But the language doesn't limit them to that--it's simply a market decision.

Re: Why you continue to use the term "Lisp" to refer to one particular dialect baffles me. Do you really consider CommonLisp synonymous with Lisp? I am a regular user of several dialects of Lisp, but I largely stopped using CommonLisp. To me, Scheme is as different from CommonLisp as, say, ML is from C++.

Most of the community thinks of Scheme as a Lisp, and I've attempted to indulge that point of view here since people are expecting me to fairly speak for the community in this interview. But if you ask me personally, exactly because Scheme is so different, I personally regard it as its own language. Not to denigrate it, but to offer it proper respect for its unique position.

And I tend to often say Lisp when I say CL. That's just an abbreviatory convention because I use the term a lot and I like using the short word. But no, I don't consider CL to exhaust the space of Lisps. By request of John McCarthy, and all the people I know have agreed to this, no single dialect is to assert unique control of what Lisp is.

Then again, the fact that Lisp can be different things should be working to my favor. You seem to think if you find some Lisp with some deficiency that you can attribute it to all Lisps. I think just the opposite; I think if some Lisp overcomes some perceived deficiency, that's sufficient to say that Lisp does not really have that perceived deficiency. I'll leave it to people other than you or I to break that tie for themselves as they read our little debate here. If anyone is still reading. Mostly I think they've rightly gone on to other forums by now.

Re:it's not a problem with Lisp

[mj6798]

But first, you've argued that people shouldn't use CL because it won't work well for them. Yet if it works well for people who choose to use it, your reasoning becomes circular. Which is it?

I never argued that people "shouldn't" use CommonLisp. I stated that I and other experienced CommonLisp users stopped using CommonLisp because it wasn't helping us get our work done as well as other tools.

You seem to think if you find some Lisp with some deficiency that you can attribute it to all Lisps.

I have not attributed any deficiencies to "all Lisps". I mean, come on, the whole thread is entitled "it's not a problem with Lisp". I attributed specific deficiencies to CommonLisp.

I think we should end the debate here. You keep responding to positions I have not taken and we evidently keep talking past each other on the technical issues.

Another thank you

[Observer]

Good questions, and answers overflowing with goodwill and scholarship. Excellent work, all round.

you missed a part

[tijnbraun]

In a related late-breaking story, usually reliable sources are stating that a similar confession may be forthcoming from William Gates concerning the MS-DOS and Windows operating environments. And IBM spokesman have begun denying that the Virtual Machine (VM) product is an internal prank gone awry.
{COMPUTERWORLD 1 April} {contributed by Bernard L. Hayes}

Java is a lot more interesting than that

[mj6798]

Further, when I hear people rave about Java, it is more for the libraries it offers than for the syntax.

The language is clearly not what makes Java interesting--it's a conservative, somewhat tedious language. The libraries are quite good. But the runtime and its specification what makes Java really interesting from a systems point of view because it offers

• a well-specified, complete reflection interface.
• a well-specified, complete interface for dynamic code generation.
• a well-specified set of interfaces to the garbage collector.
• complete specification of what operations must throw what exceptions under what conditions.
• complete specifications of both statically typed and dynamically typed operations (in particular, numbers behave with predictable efficiency).
• implementations that actually reliably perform cross-compilation-unit inlining and other dynamic optimizations.

This makes it straightforward to implement bullet-proof and portable code walkers, debuggers, inspectors, novel efficient object systems, code instrumentation systems, transparent persistence and transparent remote objects, and lots more.

Re:Java is a lot more interesting than that

[Bodrius]

Not to mention a well-specified, complete tool for automatic generation of documentation in HTML.

Javadocs are something very simple that, when properly used, can save an insane amount of time.

Sometimes it takes more than one try

[alispguru]

Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus.

I guess what Kent should have said more explicitly here was "most people's idea of Lisp comes from bad teaching by people who don't know and use the langauge. If you got to know Lisp properly, you'd like it more."

I was first exposed to Lisp as an undergrad, in probably the worst possible way. It was as part of the canonical language survey course, taught by someone who didn't really know Lisp, using an atrocious little monograph titled "Lisp for Fortran Programmers". List processing using only PROG, SETQ,and GO *shudder*. No macros, no arrays, no structures. And the implementation we used was essentially a batch interpreter - no emacs, no debugger, just a raw command-line read-eval-print loop.

When I saw Lisp again, in my second year of graduate school, it was taught by someone who used it to get real work done, with an implementation that had most of the features I have come to know and love.

A large fraction of current Lisp users (judging from comments in comp.lang.lisp) are people who started out knowing other languages, became frustrated with their instability or limitations, and went out looking for alternatives. Their choice of Lisp was not made in ignorance.

Lisp is not perfect, but it is an excellent balance of features in progrmming space. Lisp allows you to do imperative code, functional code, and OO code, without forcing you exclusively down one road or another. It is still one of the languages of choice when you want to do something truly new, and it will likely remain so.

Re:Sometimes it takes more than one try

[NetSettler]

Re: I guess what Kent should have said more explicitly here was "most people's idea of Lisp comes from bad teaching by people who don't know and use the langauge.

Indeed I should have thought to express it this way. My point is not "we're a secret society and if you only understand the magic handshake, wisdom will befall you". My point is exactly as noted here: Widespread misinformation, probably mostly well-meaning, injures Lisp.

I've from time to time observed that perhaps part of the problem is that the misinformation is transferred by people with a static language background. My hypothesis is that they are more inclined than average to assume that things don't change, because the value of static knowledge is given such a premium in their world. But Lisp is a dynamic language, and that attracts people who expect things to change, including the language itself, which means that statically known facts about the language get invalidated over time.

So there's a problem at the meta/sociological level which mirrors the problem at the technical level. Or such is my guess.

deliberate obfuscation?

[brlewis]

What's the point of x in these loops? You never use it in constructing the result. If your purpose is to scare people away from Scheme, no need to deliberately obfuscate the algorithm. Keywords like null?, car and cdr look scary enough, at least until people learn their simple meanings.

who updates this thing?

[brlewis]

Does the "nobody got fired for Java" comment indicate that this was written after Java escaped being a minority language? Or does somebody update the essay as language "fashion" changes? With this kind of advice, new languages can never be mainstream, and old languages can never see a resurgence.

Not to worry, though. The "fashion" people will be swept along eventually, whether by new fashion, or by old fashion making a comeback.

who updates this thing?

[brlewis]

See my reply to your posting of this same essay 4 minutes previous.

And by the way...

[Da VinMan]

I have to say 'thank you' for the reference to the work of Gregory Chaitin. Having been in the trenches way too long and being highly subject to the programming languages network effect, it seems I hardly ever drink of the nectar which fuels deep thinking on topics important to CS. I guess there's a significant difference between CS and IT in general and I appreciate the peeks behind the conceptual curtain more now.

Anyway, I'll find some way to let my wife order those books. ;)

Thanks again.

Re:Precedence and Associativity cause Unreadable C

[Andrew Wiles]

If you're just talking about readability, Lisp is much more readable than most other languages. Especially "popular" ones like C++ and Perl.

Not to troll, but what are you smoking?!

Did you get fired over a misplaced operator in the past, or something, and still hold a grudge against C? Because operator precedence is not the major obstacle to readability in any language. Let's talk about block structure.

Lisp:

(while (< (point) (match-end 2))
(setq s (read (current-buffer)))
(if (<= (point) (match-end 2))
(setq tcl-default-command-switches
(append tcl-default-command-switches
(list (prin1-to-string s)))*))))))

Java:

if (imp==null)
{IJ.noImage(); return;}

if (arg.equals("reset")) {
nLanes=0;
saveID=imp.getID();
if (plotsCanvas!=null) {
plotsCanvas.reset();
}
*
return;
}

I've inserted a star in each of these code snippets. Which block does the star fall in? This is what makes the C/C++/Java/Perl languages 30 times more readable, for all their faults, than the Lisp/Scheme family.

What's that? You say Emacs has built-in support for helping you find out which s-expression the star is in? Dude. If you need a computer to help you read code, the code isn't readable.

Let's be honest here. What are the real usability problems with languages?

• C++: Well, it isn't operators. It's bad compiler messages. And templates. (e.g. for (list<IEye>::iterator i = boz.begin(); i != boz.end(); i++) { pitchfork.jab(*i); (*i).bleed(); })
• Perl: All that $_<=>@*_ing punctuation. And a cultural bias against readability.
• Java: Listeners and anonymous classes.
• C: The compiler again. And a cultural bias against readability.
• Python: None (it was developed by one of those annoying usability gurus)
• Lisp: All those damn parens. You can say it's not a problem 'til you're blue in the face. But it is.

I haven't done usability testing with programming languages. But I can guess what you'd find if you did:

• One statement per line aids readability.
• 30 lines of short, simple statements are easier to read than 10 longer, more complex lines.
• A distinction between statements and expressions aids readability.
• Deeply nested code and structures are confusing. Flatness is good.
• Meaningful error messages help.

Lisp goes against every one of these principles.

Re:repost: Classic /. language rant (author unkown

[nels_tomlinson]

The message seems to be that in the real world (whoops, that should be Real World) being as stupid as the next guy is far more important than any sort of competetive advantage. The nail that sticks up gets hammered down, and all that.

Since little companies seem to manage to upset big ones' applecarts from time to time, I'm sure that's true at the big companies, where bureaucracy is more important than profits. This same effect might be connected to HP's decision to dump their calculator division?

Re:Precedence and Associativity cause Unreadable C

[SimHacker]

Wow, great reply!

Not to troll, but what are you smoking?!

I can't remember, but I sure could use some more peanut butter cups.

Did you get fired over a misplaced operator in the past, or something, and still hold a grudge against C? Because operator precedence is not the major obstacle to readability in any language. Let's talk about block structure.

Your guess was close, but it was even more traumatic than that. A stupid TA took off points because I left a superfluous BEGIN/END in my Pascal program, around a single statement terminated by a semicolon underneath an IF statement. I insisted that the reason the null statement was defined in Pascal was exactly for that purpose. And that the code was more maintainable because it was easier to insert and delete debugging writeln statements in the if statement, without having to move to the previous line and add a semicolon. But he marked me off anyway.

What's that? You say Emacs has built-in support for helping you find out which s-expression the star is in? Dude. If you need a computer to help you read code, the code isn't readable.

Yeah, I admit it. I have written functions that go on for pages and pages, and I need Emacs to help me understand and edit them. Out of necessity and haste, I've written lots of horrible code that isn't readable, and I've been stuck working with and maintaining a whole lot more unreadable code than I could ever write myself. That is life. Thank McCarthy for Lisp and RMS for Emacs. Now where do we go from here?

Wouldn't the world be a better place if more programs were written in languages that were essentially easy to maintain and more robust against mistakes, misunderstanding, code rot and entropy?

I view parenthesis like the tie-downs and steel bars that reinforce a building against hurricanes and earthquakes, such as email corruption, global search-and-replace damage, tab changes and misleading reindentation.

Python: None (it was developed by one of those annoying usability gurus)

Please don't pigeonhole Guido van Rossum as a usability guru -- GUI is only 60% of his first name! He's really a completely general purpose Guru! Python is just the latest thing that Guido is well know for. Just as Java is for Gosling, who's also implemented several programming languages that most headhunters have never heard of.

-Don

Re:Precedence and Associativity cause Unreadable C

[locust]

The mathematical sense of language equivalence is academic.

I agree that language ease of use is not just a function of programmer skill. But I think its more of a function of the programmers background. Consider, Java. It syntax is designed to look a lot like C and C++, to make it easier to use for people coming from those languages. While the syntax of Java may appear close enough to someone who has done all thier programming functionally in C, object orientation, exception handling, and so forth are still foriegn. By cloaking them in a familiar syntax you make it easier for them to learn, but drop that programmer into an interpreted smalltalk environemnt, or throw prolog at them, and they will be much more lost.

The analogy has to be made to natural languages. In english we 'get on a bus' where in fact we ride inside it. In other languages you do in fact 'get in the bus'. More particularly, in navaho (sp?) a man cannot be kicked by a horse, he allows the horse to kick him. In that language the horse cannot be though of as having intent. The same sorts of things are true for programming languages. In some langauges particular thoughts are easier to express than others, and lend themselves to specific ways of thinking. In C no matter how hard I try I cannot encapsulate... Yet C remains a perfectly satisfactory way of expressing a great number of things. At times it is expressiveness superior to languages that do provide encapsulation.

When you pick the right tool for the job, you are picking it based on what you know, and that boils down to a qualitative decision based on how you are used to thinking.

--locust

The Rise of ``Worse is Better''

[pacc]

I stumbled on a thoughtful discussion about lisp
The Rise of ``Worse is Better''.

Even though I don't care about lisp it made me come to the conclusion that XSLT is not a good idea. They have set a goal (no side-effects) with one hand and try the hardest to work around it with the other, making it practically impossible.
When different approaches to comparing two objects can come up with both true and false there's something wrong, a commite's work that's going to give implementors headaches forever.

Re:Precedence and Associativity cause Unreadable C

[Tiny Elvis]

What's that? You say Emacs has built-in support for helping you find out which s-expression the star is in? Dude. If you need a computer to help you read code, the code isn't readable.

Hmm, does your editor hilite language keywords? Strings? Comments? Should it? Can you do without it? If so you might want to turn it off. Oh you like that feature? What about autoindenting? Does allowing the computer to do it for me mean I am white-space impaired? Most people would agree that any aid the computer can give is a good thing; it's what computers are for.

Regarding your example, yes it is easier to immediately spot the block in the Java code. I remember when I first started struggling with Lisp. I found it very hard to read code, and I had to concentrate very hard on starting and ending parens, where each block was etc. I quickly got much better at understanding Lisp code visually. And most lisp environments have an editor available that will auto highlight the matching paren when the cursor is on one.

By the way I think your little list of usability principles perfectly describes assembly language.

Or in Haskell ...

[tmoertel]

... via list comprehension:

[ (x,y) | (x,y) <- zip [0..] someList, goodResultQ y ]

Re:Precedence and Associativity cause Unreadable C

[Andrew Wiles]

Your message is (Score: -1, Troll), but I think this part deserves a response:

By the way I think your little list of usability principles perfectly describes assembly language.

True. Assembly language is off the other end of the scale, of course: it's too flat, the lines are too short and there are too many of them.

Re:Precedence and Associativity cause Unreadable C

[sigue]

Your comparison is badly biased. In the Java code you put
the * on a separate line and in the Lisp code you didn't.
If you had done so in the Lisp code and had indented
correctly, as any good Lisp programmer would, they would be
equally readable.

I disagree with "Deeply nested code and structures are confusing.
Flatness is good". Too much of either one is a bad.

You seem to be assuming that Lisp LOC are longer than Java
LOC. That certainly hasn't been my experience, having done
a lot of programming in both languages. Quite the opposite.

That's an odd reason...

[alispguru]

You use a programming language for one primary reason: you believe most other people in your domain space are using it.

I can think of a few other reasons to consider, the biggest one being:

You believe it will help you solve your problems.

If your problem is "there is no known efficient algorithm to solve this", you choose a language where you can rapidly experiment and profile different solutions, then tune the hell out of the best ones and deploy them. That's why Orbitz chose Lisp for their core fare search engine.

If your problem is "we need 50 coders to maintain our external Web site", you choose a language where lots of people are available and there are lots of libraries to do the standard stuff. That's why Orbitz's Web site code is in Java.

Haskell Rules.

[exa]

He he. RIP LISP.

Re:Precedence and Associativity cause Unreadable C

[NetSettler]

Re: I haven't done usability testing with programming languages. But I can guess what you'd find if you did:

• One statement per line aids readability.
• 30 lines of short, simple statements are easier to read than 10 longer, more complex lines.

I'm not into hard-and-fast rules but I don't think these two points are radically inconsistent with most style I see observed in Lisp code. Lisp doesn't have a statement concept, but things very like statements do typically occur on their own line. People don't start blocks and put all the subexpressions on one line, though they could. So, to be honest, I have no idea what you're getting at here. I see nothing Lisp does to really push against this issue one way or another. The comment seems equally applicable to C, even though there, too, people by choice tend not to do the thing the language would let them and that you seem to fear.

• A distinction between statements and expressions aids readability.

Of your various "style rules", this is the only one that I could clearly say there's a parting of opinion on. Now, I know parsing reasons for making this distinction. And perhaps there are teaching reasons. But I've never heard it asserted that this was a readability issue and I'd like some exposition here in order to understand your motivation (both so I can reply and also just because I'd be fascinated simply to understand your reasoning on this in general).

There could be a readability issue here, but a priori I don't see one. In fact, my experiences with things like HyperTalk and this statement/expression issue, since there you have to say for each function which kind you are making, is that you often end up with things that are nominally intended to be expressions but that you want to use as statements. So you do "get foo()" just to make an expression into a statement, even though you plan not to use the "it" variable that "get" sets up.

I find the statement/expression distinction to be tedious and pointless as an enforced mechanism. Though in practice, again, Lisp programmers often have certain expressions they tend to think of as kind of statement-like and so tend not to embed in well-styled code. So again I don't see a problem.

• Deeply nested code and structures are confusing.

The ordinary use of block structure, and the commonplace use of separating blocks into separate functions, both practices introduced decades ago in Algol and long-practiced not only in Lisp but in most major languages seems to make the issue of deeply nested code not an issue. I'd need to see an example to know what this was about. I don't think Lisp gets a lot more nested than most other languages. Certainly nothing about the language forces this. Unless you want a language like Basic or Assembly that doesn't allow any nesting, I don't see how to avoid at least the possibility, and beyond that it's all just personal taste and personal practice, not language design. Do you see otherwise?

• Flatness is good.

You know, at MIT on a mid-term exam in compiler design 20 years ago, I actually saw a question that was "Gotos are (a) good (b) bad". I was immediately alerted to the fact that Computer Science should probably be better named Computer Religion, since it's often more filled with unfounded religious dogmatism than with science. I believe goodness and badness are things that have to be context-relative. One can't just stop a sentence after the word "good" or "bad" without establishing a context and have anything other than a statement of religion. It may be that flatness is good for some unspecified purpose, and that if you specified that purpose we could talk about it more. But I won't give you unqualified Good® on no more than you've offered here.

• Meaningful error messages help.

I have to say I don't know where this comes from. Lisp has an error system capability that is unmatched by any other language I've seen, and has the best guidelines for writing error messages that I've seen anywhere also. If you want an abstract overview of its capabilities, see my paper Exceptional Situations in Lisp . It is not possible to make a programmable facility that leaves the programmer any discretion at all and not risk that someone will do something obscure, but (again) you can't blame the language for that. As a rule, Lisp error messages, in part because they are object-oriented, and in part because of the power of Lisp's powerful FORMAT facility for producing formatted output, seem to me to be much better than I get in other languages. So I'm not sure what you're talking about here.

LOOP a wart?

[pussyco]

The example given is

(loop for x from 0
for y in '(a 1 b c 3 4 d 5)
when (symbolp y)
collect (list x y))
=>((0 A) (2 B) (3 C) (6 D))

and was compared favourably to a more Lispy alternative

(do ((x 0 (+ x 1))
(y-list '(a 1 b c 3 4 d 5) (cdr y-list))
(result '()))
((null y-list)
(nreverse result))
(let ((y (first y-list)))
(when (symbolp y)
(push (list x y) result))))

Since I'm learning ANSI Common Lisp from Graham's book,
I thought it would be an interesting exercise to use mapcon.
As Steele explains, mapcon allows "the mapped function to
return a variable number of items to be put into the output
list. This is particulary useful for effectively returning
zero or one item:

(mapcan #'(lambda(x) (and (symbolp x) (list x))) '(a 1 b c 3 4 d 5))
=>(A B C D)

In this case the function serves as a filter; this is a
standard LISP idiom using mapcan."(I've tweaked Steele's example)
The problem is than mapcan doesn't tell the mapped function
where it is in the list, so I elaborated:

(let ((i 0))
(mapcan
#'(lambda (x)
(prog1 (and (symbolp x)(list (list i x))) (incf i)))
'(a 1 b c 3 4 d 5)))
=>((0 A) (2 B) (3 C) (6 D))

At this point I realised there was something wrong
with the discussion. It starts with a quote from
Graham's book and ends by contrasting the aesthetism of
Scheme with the pragmatism of Common Lisp. On the one hand
Graham has been painted into the aesthetes corner, but on
the other hand his book on Common Lisp is striking for its
pragmatism; he is trying to rescue Lisp from the aesthetes.
Graham covers DO in chapter 5, macros in chapter 10 and only
gets round to disapproving of LOOP in chapter 14. This
distinctive approach cries out for explanation and it is
clearly not due to Graham sharing the minimalist aesthetic
of Scheme.

I am going to stick my neck out and risk putting words into
Grahams mouth. His distinctive claim is that programmers
spend their days sitting at their keyboards typing in macro
expansions. If they could step back from the nitty-gritty of
coding and type in macro definitions instead, then the
computer could do the expansions for them, and much work
would be saved.

In the example the mapping functions, mapcar and mapcon, are
inapplicable because they lack a sense of place, of where
the mapped function is in the list. One way of responding to
this is to start typing. One cannot use the built-in mapping
functions, so one falls back on the basic iteration
capability. The surface syntax had better be attractive
because one will be typing it alot. An alternative way of
responding is to start thinking. How does one add a sense of
place to the mapping functions?

(defmacro countcan (index func list &rest more-lists)
`(let ((,index 0))
(mapcan
#'(lambda (x &rest yz)
(prog1 (apply ,func x yz)
(incf ,index)))
,list ,@more-lists)))

does the trick, allowing one to write

(countcan
index
#'(lambda(x)
(if (symbolp x) (list(list index x))))
'(a 1 b c 3 4 d 5))
=>((0 A) (2 B) (3 C) (6 D))

and one is back in business as far as mapping over several
lists in parallel

(countcan
index
#'(lambda(x y)
(if (eql x y)(list (list index x))))
'(c b a d)
'(a b c d))
=>((1 B) (3 D))

So Graham is not concerned with balancing the purity of
typing
(DO blah blah blah blah ...
against the pragmatism of typing
(LOOP blah blah ...
because he is intending not to type either of them all that
often. His plan is to type
(DEFMACRO purpose-built-iterator-17 blah blah ...
and then to win back the time he spent thinking with
quicker, easier coding in the rest of the program.
DO fits into this plan better than LOOP.

Sometimes there is no alternative...

[Sekkat]

> No one cares how useful a programming language
> is - they care how many competent programmers
> they can hire who can code with it. This is why
> Lisp, ML, Haskell, Prolog and the rest have
> been consigned to the dustbin.

I strongly disagree.

In every large software system, there is a complex part. Writing this part in a lower level language (like Java) is giving up a lot of competitiveness, because your system will be inherently limited by the architecture choice.

Dont misunderstand me, Java (for example) is of great value, giving you a great standard of interoperability.

But for the part of the system that makes you headaches, choose a powerful language for fast prototyping, dynamic behavior and with code generation features (macro facility).

And of course, pay the higher price for experts, and get rewarded by a system having unique capabilities.

And even if you want to stick to Java (as example), you will be better generating this code out of a powerful meta language.

Anyway, this approach has of course some negative sides, but what would be our business without challenges...

Re:Precedence and Associativity cause Unreadable C

[evbergen]

I don't understand why you think precedence is something that's a "confusing" concept in general. I was taught that multiplication comes before addition in primary school...!

Also, because these rules don't tend to change in a language, I fail to see how relying on precedence makes code hard to maintain or easy to break ("brittle"). It won't break spontaneously, if that's what you mean. Somebody who does not know the language's rules has to come along and edit your code first.

If you're using a language for expressions, you've got to know the rules. When using any language with infix expressions, the precedence rules just belong to the rules that you're required to know, just as some other essential grammar rules for that language.

The only situation where you run into trouble is if you either believe that knowning grammar at all is optional, or that precedence rules don't belong to an infix expression language's grammar, and I don't think you can make a good case for either.

Re:Precedence and Associativity cause Unreadable C

[SimHacker]

We were taught only TWO levels of precedence in elementary school. I remember it well: at the time I thought it was a stupid and pointless gimick, and I still do. I already knew about parenthesis, and they made perfect sense. What makes no sense is leaving parenthesis out in some cases, and requiring extra parenthesis in other cases.

What they didn't teach you in elementary school was that there might be any more than TWO levels of precedence. Nothing from elementary school prepared you for the FIFTEEN or so levels of precedence on C. Two levels was bad enough, but FIFTEEN is RIDICULOUS.

The fact is that the rules DO change from language to language. Each language with precedence rules has ITS OWN SET OF OPERATORS. Some blindly copy the precedence rules of C, but none of them are exactly the same.

And the rules of C++ have been changing for many years, so much that it's a running joke. If you think mathematical notation is so wonderful, then why can't you multiply a and b by writing "ab"?

Now do you still really want to blindly copy mathematical notation? Read Bjarne Stroustrup's paper, "Generalizing Overloading for C++2000" to see where that will lead. If you still think it's a good idea after reading that, let me remind you he wrote it as an April Fools joke. (The paper, not C++.)

Relying on precedence most certainly DOES make code hard to maintain, and easy to break ("brittle").

It's a fact that code changes over time, and many different people make those modifications. If any of those people did rely on precedence instead of using extra parenthesis, the chances are much higher that the code will break whenever you or somebody else modifies it. Much worse than simply breaking with a syntax error: its meaning will change, but it will still compile without error, so you probably won't even notice you made a mistake.

By "brittle", I mean that code should be ROBUST in the face of CHANGE, and precedence flies in the face of that.

For example, if you foolishly write a big "if" statement that spans several lines, has many sub-expressions with addition, multiplication, shifting, ?: conditionals, ands, ors, or any other operators at different precedences, it is extremely difficult and time consuming for anyone else to come along and modify that code, without reindenting it and wrapping it all in parenthesis, simply to understand what it does.

Second of all, you are probably responsible for many bugs youself, because you reply on precedence! How is the poor sucker who has to debug your code supposed to figure out if you really MEANT to depend on the subtle order of evaluation, or if you were simply too foolish to put in enough parenthesis so there was no visual ambiguity, therefore no bug?

If you're DESIGNING a language for expressions, you've got to design GOOD, SIMPLE, CONSISTENT, EASY TO REMEMBER RULES, or else the poor victims who have to use your language will waste a huge amount of time and energy trying to make up for your stupid mistake as a language designer, and fixing bugs they never would have encountered were it not for your short sightedness.

This is a discussion about the DESIGN of programming languages. It's acceptable to QUESTION the rules, instead of blindly following them, and blaming the victims for the mistakes they couldn't help but make, because their language was badly designed.

Don't act like such a pedantic school teacher with a ruler always ready to smack the hand of anyone who makes a mistake. Rules should not be designed as opportunities to PUNISH people for breaking them. They should help people get their work done more easily and efficiently, instead. And precedence rules cause much more harm than they do any good.

How does not having to type parenthesis really improve your life? If you were a good programmer, you'd type them anyway, because it's your duty to write robust maintainable easy to read code. Precedence rules only open up the door to hard-to-spot mistakes, they don't prevent any.

Precedence rules come from written mathematical expressions, which is a two dimensional visual language. Conventional programming languages are written in ASCII, which is a one dimensional string of characters. It's not possible to directly express the two dimensional branching and grouping in ASCII that you can in written mathematical expressions, therefore you have to use parenthesis and other explicit grouping and associative techniques. Precedence rules are subtle, invisible, and a totally arbitrary convention copied from mathematics and then taken to a ridiculous extreme. There's absolutely nothing "natural" or "essential" about it, like the rest of math. It's like arguing that racial prejudice is good and natural, just because you learned it from your parents.

Mathematical notation was arbitrarily made up over history by many different people. As you should know, there's no rhyme or reason to most of it, and a bad notation can certainly get in the way of understanding the problem.

That's why Alan Turing and others had to invent their own ways of writing expressions like differential equations, that make the problem easier to understand and work with. There is certainly room for evolution and improvement -- mathematical notation was not carved on stone and handed down to us from God.

It's ridiculous to say that precedence rules are easy to learn, because they're based on mathematical notation. People aren't born with it. They have to learn it over time, just like any other syntax in any programming language. Most people in this world have very little understanding (and a lot of misunderstanding) about math, and couldn't give a flying fuck about traditional mathematical notation.

I don't believe knowing grammar is optional, but I do believe the grammar should be simple and well defined enough that you can quickly learn ALL of it. This is certainly NOT the case with C++. Off the top of your head, what's the syntax for declaring and using a pointer to a member function? How did your knowledge of mathematical notation help you with answering that question? And what's the relative precedence of that syntax, compared to pointer indirection? How do you use an array of pointers to member functions?

Whatever it is, you'd better put in a lot of extra parenthesis, and use temporary intermediate typedefs and variables, if you want your code to be readable, maintainable and robust.

If you protest that it slows down your code, you don't know the first thing about compilers. If you protest that it slows you down, then that's good, because you should realize that writing robust code prevents bugs and saves a whole lot more time and energy in the long run.

-Don