On Tue, Jul 19, 2011 at 9:04 PM, daly <d...@axiom-developer.org> wrote:
> On Tue, 2011-07-19 at 20:14 -0400, Adam Richardson wrote: > > On Tue, Jul 19, 2011 at 6:23 PM, Brian Hurt <bhur...@gmail.com> wrote: > > What's this awk-a-mel he speaks of? Ocaml, pronounced > > oh-camel, I ... > > > > > > I will confess that as I listened to the presentation (when I got the > > email with Tim's link, I just started the video while I was working on > > some drudgery), I felt like he missed some of the language features > > promoted in functional languages. > > > > > > He worded functional programming contributions in terms of advancing > > the idea of limiting/protecting variable assignment (immutability), > > and to me, that's missing the points of first class functions (which, > > in light of what he says OOP languages brought to the table, actually > > provided protected function pointers through purely functional > > languages without any need for OOP) and an emphasis on function purity > > and limiting the scope of unpure functions (to me, this goes beyond > > merely protecting assignment.) > > > > > > These omissions, coupled with the mispronunciations of functional > > programming language names, and the value placed on the last language > > being homoiconic (without much justification) had me wondering how > > much he actually has used languages such as OCaml or Haskell. > > Homoiconic representation is fundamentally important and lacking > in other languages. The programs == data idea is what makes the > macro facility work, allows dynamic program construction, compile > to core, etc. There is a story going around that McCarthy attended > a python talk where they made the claim that python IS a lisp-like > language. John pointed out that if it lacks homoiconicity it cannot > be a lisp. (I probably have the details wrong). > > I tend to take the position that Micheal L. Scott does in his book "Programming Language Pragmatics", when he states that: Metaprogramming requires, at the least, that we have true first-class > functions in the strict sense of the term, that is, that we be able to > generate new functions whose behavior is determined dynamically. A > homoiconic language can simplify metaprogramming [emphasis added] by > eliminating the need to translate between internal (data structure) and > external (syntactic) representations of programs or program extensions. (p. > 563) Homoiconic does simplify the process, but I'm not sold it's a requirement for productive metaprogramming. For instance, Template Haskell is a very powerful, usable tool for integrating metaprogramming into programs written in Haskell, a language that is not considered homoiconic: http://www.haskell.org/haskellwiki/Template_Haskell That said, I appreciate the syntax of Clojure and CL very much, but there are also times I appreciate the syntax of non-Lisp languages, too :) Interesting points. Adam -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en