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 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)

Come sweet slumber, enshroud me in thy purple cloak.
56 ms