> I've been converting some projects to Clojure for the past few months... > but thinking about them enough to express the issue clearly has so far > always resulting in my solving them easily.
This is GREAT to hear. I personally place considerable measure on accounts such as yours because they offer a degree of historic context - this is something which I find lacking w/re to most contemporary new programming languages. This is unfortunate because there are so many reasons that an eye to the longer term context would prevent CS from constantly re-inventing the wheel. I suspect that unlike many of Clojure's early adoptees I do not produce code professionally or on a for hire basis. My gut tells me that this affords me certain insights that are not immediately visible to those entrenched in the active work a day of developing the language and bringing it to a 1.x reliable production release. My personal interest in Clojure (and programming languages in general) is directed solely towards maintaining/building the systems and environments I use in an area of specific professional concern (fine arts + art history). For the most part, 'programming arts' have few immediate intersections with the particular fine arts applications I concern myself with. When first examining language paradigms which might facilitate tool creation/maintenance related to my formal area of expertise I found that those of the 'Lisp School' (if there is such a thing) best dovetailed with my internal maps, associations, and arrangements of the fine arts subject matter. In particular I've found Li-spy concepts like 'Code as Data - Data as Code' to be of immediate relevance when considering how to best model data that is conceptually abstract and which is invariably fluid and dynamic. One thing I find truly inspiring about Lisps is that over their 50 yr history - as a group or language paradigm - they have consistently "Done the Right Thing". From the perspective of one who routinely handles, preserves, and conserves visual objects at one time created for their aesthetic value this is important. In the arts "doing the right thing" is probably no more quantifiable than in programming. However, as the arts are an older more established field of creation there are certain measures of rightness that can be ascertained over time - "Is a work remembered, if so why? Did it influence significantly - Whom? Did it innovate - How? Did it sell well at auction - How Much?" Viewed en masse these questions can give a good approximation of a work's aesthetic 'rightness'. Prob. no one remembers the picture of a tree you drew in kindergarten - that doesn't make it wrong - but it does not make it not right... Even if you were a child prodigy unless your childhood art satisfied certain of the aforementioned measures we can not gauge it's rightness in the now with any quantifiable certainty (subjective as it may be). We know lisps have DTRT because: a) They are still around and used actively; b) They've influenced the design of nearly every popular language used in commerical production code today; c) They helped inspire many of the language innovations provided by today's popular languages; d) For nearly 20+ yrs they were provided as core language components of many state of the art mainframe, distributed, parallel processing computing environments (that we know about). All of this suggests to me that Lisp as a language has been bolstered by a community concerned with achieving value over the long term and with lasting for 'the long now'. Typically, when creators concern themselves as such they're output achieves a certain aesthetic beauty - an elegance. I believe that things created with aesthetic rightness as a guiding principle are generally shown to be 'better' than those that aren't. Beautiful things are worth keeping, celebrating, sharing, defending, preserving, and maintaining. It is for this reason that I am drawn to Lisp. This tropism towards a lispy approach is not one that has been embraced by the broader jobbing CS community in recent times. I believe this is due in large part to the rise of Internet/web applications circa 1995-2005 which have *required* a rapid/ reproducible pattern of design/implementation which allowed for scalable turnkey deployments of 'enterprise' data - MVC being a classic example. That said, such approaches have tended to leverage imperative style and OO design - neither of which scale well for data and data oriented tasks outside the purview of 'enterprise'. In lieu of this we've seen tremendous effort extended to the formation of standards like XML/rdf which aim towards the production of some sort of "semantic web" and which are geared in large part towards enabling non-programmers to process, communicate, and assemble, data specific to domains outside those typically embodied by 'enterprise'. Where 'enterprise' has benefited from a separation of concerns - code as code/data as data; other domains (often with data that is more nuanced, less empirical, or otherwise indefinite) have languished. Non enterprise oriented domains tend to benefit from the "Code as Data - Data as Code" approach. This is precisely what XML/rdf attempts to facilitate. However, there is a fundamental orthogonality to the XML/rdf approach - the development tool and developers which have thrived in last 15 yrs are for the most part enacting these technologies with languages rooted in an imperative style wrapped up in OO design - these languages and their developers fall over when they try to do "Code as Data - Data as Code". That being said, XML/RDF is not all bad, MVC w/ scripting/SQL works great for lots of apps and Billions of Dollars worth of legacy production code isn't going anywhere soon (nor should it). We're all stuck with situations which require us to continue leveraging existing data into new new and interesting, *interoperable* environments. This is not an intractable situation. Integration of Lisp paradigms into these systems alongside or in place of existing codebases provide a way forward. Though, it seems that there are some who have considerable investment stakes in further intractability and convincing others that the Lisp paradigm is a dead end - I read recently where Tim O'Reilly mouthed off with a suggestion that XML/ Xpath/XSLT has largely supplanted need for a modern Lisp. Note to Tim; </tag> will never parse the same as `)' no matter how much your publishing enterprise *needs* to continue twisting reality to accommodate that perspective... >From a non programmer perspective 'Code people' tend to be overtly concerned with matters such as Type Correctness, Turing Completeness, Data Structure Optimization, b-trees vs hash tables, etc. And with good reason, their success depends on these matters. Still, code isn't written in a vacuum - it must interact - often times with humans. Non 'Code People' tend not to care about b-trees. I recall arguing with a developer at length about a specific design choice pertaining to a reasonable model on semantic relations within a relational db and when/if to limit the number of joins on an SQL query. "We can't do that, the db will CRAWL!" He was right, the db crawled.... but the relation was valid - moreover the need to access that relation was valid. Unfortunately our environment was limited to budged constraints and the tools at our disposal and the relational db was driving the design choices. At that time, I was not familiar enough w/ dbs to recognize this developers concerns and why he was expressing them - whether he understood my *need* to perform the query was an entirely separate issue. The point is, developers and development tools affect design decisions AND they affect the way users influence and employ the software developed with those tools (this is Paul Graham's 'Blub paradigm). Collectively, we now have 10+ yrs of web/network aware production code *and* data most of which has been built with imperative style OO design tools. More recent trends in popular language design seem to acknowledge the need for some move towards better integration of code with data - typically this involves leveraging scripting tools to do so. Still, these same languages and their clans of developers are want to continue encouraging that the data itself be modeled /constructed and accordingly parsed internally in an OO style eg XML/rdf. The scripting is often simply an after thought dropped in as a means with which to 'lazily' avoid compilation concerns vis a vis dynamic data structure. It appears to me that the recent chorus has been that use of dynamic scripting languages as abstraction layers on an underlying core of imperative style OO languages are the way out of this problem. e.g. ECMA script. (Note: ECMA script behind all the bells and whistles is Scheme's ugly step-brother from a now defunct marriage) Despite Steve Yegge's claims to the contrary, Java-script may not be the answer to a move towards achieving more "Code as Data Data as Code", any more than compiled C is the way to build an ecommerce site or Java code makes for non verbose way to write one off record reports. On the other hand, where past LISPs have been highly successful they have floundered in potentially irreversible ways due in large parts to the way they have historically handled compilation to byte code - (e.g. Lucid and the move to C). While there is NO reason traditional Lisp languages can't accommodate modern and future processors - the underlying codebase, developer base, hardware infrastructures, etc. are dwarfed by those of the more successful and popular imperative based OO style languages. In many respects it is simply an insurmountable task to bring the entirety of any legacy Lisp system onto a competitive playing field with the Python, C++, Perl 5.xx, Java, etc. "Doing The Right Thing" entails achieving successful transparent integration of both worlds. So far Clojure seems to have achieved a rightness to these approaches. Mark Tarver's QiII is the another attempt towards a reintegration of Lisp into popular commercial languages though his approach is radically different - keeping a CL core Tarver's approach can allow for massive Type extensibility to the language and compiles down to lisp byte code. Tarver's approach is the more academic of the two and may well never yield/generate immediately commercially viable production quality language inter ops for jobbing programmers. This is why I find Clojure so exciting. So far it has made good efforts to accommodate most of Lisp terse syntax and Functional Style. That said, I take some issue with calling Clojure a pure Lisp style functional language - simply eschewing side-effects does not a lispy FP make. It is just as important that Clojure stands up under heavy native macro augmentation (sans external Java imports), and the ease with which this can be achieved - the book is still out on that one (literally) - if extending Clojure's native macros beyond the core precludes reasonable external Java Interop or is otherwise more painful than CL's FFI what does it get you other further tied to a Java based environment - one that doesn't currently offer TCO or offer native support of complex numbers? I believe that Rich Hickey has the vision, experience, and grey matter to make Clojure the next 25yr language. His enthusiasm is inspiring and as stated elsewhere "infective". It's hard not to watch RH's Autumn '08 screencasts and not feel as if your getting let in early on a big secret. I believe he has a commitment to DTRT. In many ways he's asking a lot of Lispers to place faith in him when he says - "Trust me I've thought about this and looked into it - I've decided this is the right thing". By all accounts he's standing on the shoulder's of giants. Certainly there are a good many that want to see him get it right. There are probably also a good many that would relish him getting it wrong. There some smart cookies in each camp - and despite the relative motivations they are definitely watching on with a strong eye towards scrutiny. If RH is getting it right then a lot of people waiting in the wings want right to be RIGHT - it is doubtful they will put their seal of approval on it without such assurances. Equally if there are not insignificant design flaws then it is important that they be well scrutinized and publicly discussed. The conventional wisdom seems to be that the JVM and similar run-times present an environment where language design is cheap... If RH gets it wrong someone else will get it right next time. I don't accept this - there are far too many wasted resources as it is on failed or compromised languages. With the potential for the first time in quite awhile for new research/ investment dollars to enter the field - now seems like the absolute wrong time to promote forks, fragmentation and Babylon. I also believe that he can have all of these things and Clojure can fall short of the mark without the active adoption of Common Lispers and Schemers ready to let go of some of the unfulfilled promises of earlier lisps. Clojure is a radical design. Not necessarily from an algorithmic standpoint (and i wouldn't know or be qualified to judge anyways) but simply because it is written in Java! If it's true what they say that change happens where you least expect it then change has come to Lisp Land. It takes *real balls* to endeavor to design a lisp in "blub" - get rid of the cons cell - and then insist that the language has the potential for future Lisp superiority in the realm of concurrent, distributed, and parallel processing (my understanding says these areas are a convergence?). Having lost the OS to C - recent lisp lore characterizes Java as a sort of supreme example of all that is wrong with the world. Asking lispers to move (stoop) into that Clojure's Java world is a bold move. In his Oct. '08 screen cast RH says something along the lines of "Java isn't the JVM" Which while technically true doesn't swallow easily, moving your development platform to the JVM is a slippery slope. One of the knocks on CL is the way it supports arrays. Yeah, it's a bit awkward. That said, take a gander out how Clojure supports arrays... And therein lies the slippery slope (Java doesn't even support Java array!). That said, there is no reason one is required to use Java arrays... that is if RH has gotten the rest of it right. I want Clojure to be the right thing. I sincerely believe RH when he says he has gotten it right. I don't see a better chance to bring Lisp into the 21st C. I don't want to look up a year from now and feel like i wasted time learning Clojure basics. I believe the success of Clojure is of considerable importance for the future of Lisp. I also worry that without good participation from advanced CLers, Emacser and Schemers that no matter how "right" the core is the Java influence will lead it down 'a not quite right' or 'good enough for Java' path. This is not to speak ill of Java but as my daddy used to say "two wrongs don't make a right" I look forward to hearing of more more longtime Lispers jumping on the Clojure Bandwagon. It means RH is getting it right. On Dec 6, 11:12 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I've been converting some projects to Clojure for the past few months, > and I thought it was about time to say something about how much fun it > is. I've nearly posted a couple of times about issues that cropped up, > but thinking about them enough to express the issue clearly has so far > always resulting in my solving them easily. To me, that's a sign of a > good piece of design. > > I've been a Common Lisp programmer for many years. My first serious > project with Common Lisp started at Apple Computer in 1989. I used > Coral Common Lisp and got to know the people who produced it. I ended > up working with them again several times. They're my main customer > now; their business is called Clozure Associates, and they maintain > Clozure Common Lisp, which, once upon a time, was Coral Common Lisp. > It was a message from one of the Clozure partners that first made me > aware of Clojure. She noticed that they weren't the only Lisp-based > venture using a misspelling of "closure" as a name. > > One of the things the Coral/Clozure folks did while I was at Apple was > the design and implementation of Dylan. The early version of Dylan, > before the invention of the infix notation, was probably my favorite > programming language. I worked on a version of the Newton OS that was > implemented in that version of Dylan, and preferred it over any other > programming language before or since. > > I think I've used Clojure enough now to say that I like it as much as > that old version of Dylan. It's possible I'll end up liking it more. > > In some areas, I'm not sure yet whether I like Clojure as much. Is it > as easy to extend the sequence abstraction to user-defined datatypes > as it was in Dylan? Dunno. I do know that I like the unified sequence > abstraction in Clojure. Is the Clojure design for multimethods as > natural and convenient as the CLOS-based one in Dylan? Dunno. It feels > awkward so far, but I do like the separation of protocol from > representation; Clojure may be the first language I've used that does > what I've always wanted there. It's taking a while to get used to > derive. I very much like the freedom to create arbitrary ad hoc > classification relationships with it, but relying on symbol tags feels > a little forced sometimes. It doesn't seem to be impeding me, though, > so maybe it's just a matter of getting used to something new. Are > Clojure namespaces as pleasant as Dylan modules? Hm. Not really. And > the implicit mapping to a hierarchical filesystem feels a little > creepy, as it does in other languages that do it (e.g. Java and > Python). But Clojure's design fits the JVM, which is a virtue that > might trump other considerations, at least for now. > > I've moved pretty much all my spare-time projects over to clojure and > it's been a pleasure so far. It's a nice piece of work. It seemed > appropriate to say thanks for it. So thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
