IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New just trying to learn
As for the original argument put forth by Bryce, I think he's finding superficial problems (as per usual). Bottom line is that Bryce probably will never be comfortable with S-Expressions, preferring the more cozy (though less extendible) M-Expressions.

I am just trying to understand how to read and navigate LISP code. I am not intending to complain, but rather explain some of my initial difficulties and wonder how a seasoned Lisper deals with those. It might take a while to get my head out of "Algol mode". Although I like the idea that Lisp makes code and data interchangable, it seems to also make it harder/slower to read.

I wonder if LISP could not be reworked to have the function name be on the left side of the parenths. In other words, x(a b c) instead of (x a b c). If you want a list, then just have list(a b c) or quote(a b c). Would that ruin the whole premise? Has anybody ever tried that?
________________
oop.ismad.com
New As far as I understand
The rearrangement of the list structure would prevent the introduction of macros into the language. The use of M-Expressions, which is more in line with what you are asking for, was tried by McCarthy early in Lisp history, but quickly abandoned for that reason. As for difficulty of reading, it's a matter of practice and discipline. Liken it to those calculators that use RPN instead of the norm - programming in RPN was generally easier and more powerful once you got past the initial hurdle.

As for Lisp, the syntax is dirt simple (being bare to the bones). You can learn the syntax within an hour but the syntax doesn't solve anything like it does in other languages (loops, conditionals, etc). The biggest advantage to Lisp is that the syntax does not get in the way. You can achieve practically any paradigm in Lisp (OOP, relational, functional, procedural, declarative, etc...), because the syntax doesn't fight you - being able to delve into the semantics.

A Lisper will probably tell you that any advantage you get out of the syntax in other languages is achieved at the expense of painting yourself into a corner.
New More on s-expressions
Paul Graham (whom Ben referred to earlier) is in the process of designing a language called Arc. He has put up a page with all the [link|http://www.archub.org/arcsug.txt|suggestions for arc]. One particular set of [link|http://lispmeister.com/cgi-bin/blosxom/lisp-news/moon-on-s-expressions.html?seemore=y|comments from Dave Moon], who helped with Dylan macros, might be what you aiming at. He explains why he doesn't like s-expressions:
I want to comment on your use of S-expressions, based on what I learned in my couple of years researching Lisp hygienic macro ideas and working on Dylan macros. Summary: I learned that S-expressions are a bad idea.
The knock on getting away from the s-expressions has always been that it makes macros difficult, if not possible. Moon seems to believe that if all macros are completed at compile time, macros can be achieved without s-expr:
I think you should limit the language to what you know how to implement, so the macro special-form should only be allowed in places where its complete flow is visible at compile time and should never be allowed to materialize as a run-time object.
Of course, a Lisp diehard would argue that the distinction between compile time and runtime is arbitrary and that there should be not hard lines drawn between the two. Having macros expand during runtime provides some interesting possibilities when it comes to designing systems (especially systems that program other systems).
New Downsides of flexibility
The biggest advantage to Lisp is that the syntax does not get in the way. You can achieve practically any paradigm in Lisp


But its bendability might also be its downfall. Everybody can reshape it in their own image, and person A might not like person B's approach. Further, it introduces inconsistency. If everybody makes their own version of IF-ELSE, then for every Lisp shop you walk into you have to learn a new IF-ELSE convention.

This is why Lisp is sometimes called a "hacker language". Hackers usually don't care about transparent code. They want something which is fine-tuned to their thought process so that they can code fast. They want to merge the code with their own brain, not to the world outside.

I am not outright ruling it out, but only pointing out downsides to flexibility.
________________
oop.ismad.com
New Less flexible = good?
You are making the assumption that there's languages out there that are going to make reading code easy, and by simply glancing at microscopic pieces of the code, you are going to be productive at a moments notice. Won't happen, no matter the language.

Let me quote you a chunk from the foreword by Abelson in [link|http://www.cs.indiana.edu/eopl/|Essentials of Programming Languages]:
There are three reasons why as a programmer you should learn about interpreters.

First, you will need at some point to implement interpreters, perhaps not interpreters for full-blown general-purpose languages, but interpreters just the same. Almost every complex computer system with which people interact in flexible ways - a computer drawing tool or an information-retrieval system, for example - includes some sort of interpreter that structures the interaction. These programs may include complex individual operations - shading a region on the display screen, or performing a database search - but the interpreter is the glue that lets you combine individual operations in useful patterns. Can you use the result of one operation as the input to another operation? Can you name a sequence of operations? Is the name local or global? Can you parameterize a sequence of operations, and give names to it's inputs? And so on. No matter how complex and polichsed the individual operations are, it is often the quality of the glue that most directly determines the power of the system. It's easy to find examples of programs with good individual operations, but lousy glue; looking back on it, I can see that my PL/I database program certainly had lousy glue.

Second, even programs that are not themselves interpreters have important interpreter-like pieces. Look inside a sophisticated computer-aided design system and you're likely to find a geometric recognition language, a graphics interpreter, a rule-based control interpreter, and an object-oriented language interpreter all working together. One of the most powerful ways to structure a complex program is as a collection of languages, each of which provides a different perspective, a different way of working with program elements. Choosing the right kind of language for the right purpose, and understanding the implementation tradeoffs involved: that's what the study of interpreters is about.

The third reason for learning about interpreters is that programming techniques that explicitly involve the structure of language are becoming increasingly important. Today's concerns with designing and manipulating class hierarchies in object-oriented systems is only one example of this trend. Perhaps this is an inevitable consequence of the fact that our programs are becoming increasingly complex - thinking mor explicitly about languages may be our best tool for dealing with this complexity. Consider again the basic idea: the interpreter itself is just a program. But that program is written in some language, whose interpreter is itself just a program written in some language whose interpreter is itself.... Perhaps the whole distinction between program and programming language is a misleading idea, and future programmers will see themselves not as writing programs in particular, but as creating new languages for each new application.

The problem with letting syntax govern the rules of abstraction is that as the level of abstraction gets higher and higher, due to the complexity of the program, the syntax can act as a barrier to dealing with the increasingly complex interaction within the program. What may work well in simple straight forward programs, does not necessarily scale. As the program becomes more sophisticated, you are dealing less and less with the original programming language constraints, and more and more with the constraints you face in your own code. Ultimately, how smooth you work with your own constructs is much more significant than the underlying base programming language. The less that programming language fetters you in the higher level of abstractions, the easier it will be to maintain and extend your code base.

Your thinking indicates that you think it important that code be understandable at a microscopic level. But the macroscopic level is not necessarily the same.
New Dejavu
Just had a raging thread on comp.lang.python and c.l.lisp about this:

[link|http://groups.google.com/groups?threadm=7xznfspmjf.fsf%40ruckus.brouhaha.com|http://groups.google...ckus.brouhaha.com]

..wherein both sides had their say.

You said:
The problem with letting syntax govern the rules of abstraction is that as the level of abstraction gets higher and higher, due to the complexity of the program, the syntax can act as a barrier to dealing with the increasingly complex interaction within the program.


...which is fine. But the vast majority of code being written today has a common, low "complexity threshhold", IMO, which doesn't warrant a new syntax for each application. How many people are writing general ledger applications at this moment? Most cubby-farm programmers benefit from regularity.

The less that programming language fetters you in the higher level of abstractions, the easier it will be to maintain and extend your code base.


...assuming *you* are the one maintaining and extending it, and have a good memory. For the rest of the world, we enjoy a "lingua franca" when possible to ease maintenance across brains and time.
New I like big apps and I can not lie.
Most of the apps that I write are years in the making, and I do wear most of the hats associated with the software lifecycle. But the larger issue, that I'd take exception to is that software development is not a monolithic industry. Yes, there are many jobs that are mundane, with fill-in-the-blank programmers. Many business don't like being dependent on individuals, so they try to promote mediocrity. In such businesses, software is not seen so much as an asset as it is an expense.

But then, is that really the kind of business we want? Well, certainly if it makes a difference in getting a paycheck. But if one has the luxury of working for (or starting up) a company that values innovation, I'd run with flexibility. I'm not interested in the whether a mediocre programmer can follow. I'm interested in providing unique and compelling software solutions, at a reasonable cost, with reasonable speed, and timely delivery. If I don't deliver on any one of those three aspects, then worrying about the person that comes behind me is purely academic, as the software will have no need to be sustained.
New Language de jour
Almost forgot, since the purpose of this particular thread is to pretty well ignore Bryce, and just discuss Lisp in general, I thought I'd mention that what I see a lot of in the business today is multi-language solutions. And along those lines, I kind of like the following quote from [link|http://lemonodor.com/archives/2004_03.html|Richard Cook]:

I look at it this way. A lot of the new, interesting software is being written in a combination of two languages; a high-level, dynamically typed language with good built-in data structures and an environment for rapid software development, and a statically typed, heavily optimized language for performance. For a Python programmer, these two languages are Python and C. For the Common Lisp programmer, the two languages are Common Lisp and Common Lisp.
New Standards versus flexibility
Standards versus flexibility is an age-old tradeoff. Standards make it quicker to understand something because it follows known patterns/guidelines. If flexibility gives only minor improvements over the standards, then standards are generally preferrable. An example is a device that has a proprietary or hard-to-find battery because it allows the device to have a certain shape without using a smaller battery capacity. But the downside is that we cannot readily replace that battery because it is not a standard.

It would be nice to see a "killer example" of the flexibility of Lisp that an Algol/C-like language cannot do nearly as smoothly.
________________
oop.ismad.com
New One of the problem is that by the time a comprehensive...
comparison between Lisp and an Algol like language can be done, the Algol like language suddenly, and inexplicably, dies. Lisp will be here a hundred years from now. Java, and most of the other "standard" languages will not.
New You are probably right, but I'll be long retired by then
It is interesting to note that Yahoo replaced most of Paul Graham's Lisp code for the e-stores. If Yahoo did not like Lisp, why did they buy the damned thing? To get customers only?
________________
oop.ismad.com
     Why I find LISP hard to read - (tablizer) - (25)
         Scheme to the rescue - (ChrisR)
         Care to offer an example where there is some ambiguity? - (ben_tilly) - (20)
             Allowed in CLOS but not in Scheme - (ChrisR) - (16)
                 Care to show me the example? - (ben_tilly) - (15)
                     Lisp is a family of languages - (ChrisR) - (14)
                         Rethinking, reloading. :-) - (ChrisR) - (13)
                             Thanks for the confirmation - (ben_tilly) - (1)
                                 Special forms - (ChrisR)
                             just trying to learn - (tablizer) - (10)
                                 As far as I understand - (ChrisR) - (9)
                                     More on s-expressions - (ChrisR)
                                     Downsides of flexibility - (tablizer) - (7)
                                         Less flexible = good? - (ChrisR) - (6)
                                             Dejavu - (FuManChu) - (2)
                                                 I like big apps and I can not lie. - (ChrisR)
                                                 Language de jour - (ChrisR)
                                             Standards versus flexibility - (tablizer) - (2)
                                                 One of the problem is that by the time a comprehensive... - (ChrisR) - (1)
                                                     You are probably right, but I'll be long retired by then - (tablizer)
             A "Let" statement that sets a bunch of variables -NT - (tablizer) - (2)
                 Ah, that is because let is a special form - (ben_tilly) - (1)
                     Not to get in too deep... - (ChrisR)
         OT: Why is this in Scripting? -NT - (pwhysall) - (2)
             oh oh, I smell another fight over definition of "scripting" -NT - (tablizer) - (1)
                 :-) -NT - (pwhysall)

Powered by scientifically unsubstantiated energy producing capabilities!
383 ms