On Nov 17, 4:52 am, Luc Prefontaine <[EMAIL PROTECTED]>
wrote:
> I never read anywhere in the documentation or in the user group that
> Clojure is a Common LISP implementation.
>
> Since it's existence, LISP has not gained a large acceptance in the
> commercial market compared to other "conventional" programming
> languages.
> I started to use it 28 years ago (UCI Lisp on a DEC10) and never crossed
> over it in my professional work except twice
> (ITA implemented their services in LISP and it is a big commercial
> success and another of my customer uses Scheme to implement
> some specialized algorithms).
> For a language that's been around for 50 years, it's at least annoying
> if not strange given the power of the language.
> Worse some companies have success stories using LISP but don't go public
> about it.
>
> Certainly, having "t" to represent the truth value instead of "true",
> using defun instead of defn or making an indigestion of parenthesis
> are not essential LISP features.
>
> Compromises at the syntax level are very small concessions to get LISP
> endorsed by a majority in the software community.
> The post fix notation is already a challenge (look back at people using
> HP calculators in the 70s/80s), so lets make things a bit easier for
> the non LISP programmer used to left-right assignments...
> Clojure is not a second citizen LISP because it implements a simplified
> syntax.
>
> You may need to start from a blank sheet if your Common Lisp knowledge
> interferes with your learning curve :)))
> Get Stuart's bookhttp://pragprog.com/titles/shcloj/programming-clojure
> and start from there.
> This should give you a clear vision of what Clojure is and is not.
>
> It's time for LISP to get a significant share of commercial success
> stories and the only way is to add some sex appeal to it to
> attract the masses. Considering that the software industry stagnates
> since the 1980s, it's a welcomed change.
>
> Personally, Clojure is the breath of fresh air I was waiting for. The
> reality is that most of my customers are using Java with
> thousands of code lines with pitiful results in terms of ROI. According
> to them, Java is the best gizmo on the market (including
> all the frameworks written around it), I think that Cobol had a better
> ROI than Java in many instances.
> Getting them away from Java is impossible to do but something like
> Clojure is an open door to a lot of significant applications,
> better ROI and better time to market schedules.
>
> I think that Clojure's main audience are these people drowning in this
> ocean of java code, not the LISP advocates :)))
>
> Luc
>
> On Sun, 2008-11-16 at 15:32 -0800, Dave Newton wrote:
> > I'll add that:
>
> > (cond (foo bar) (baz plugh)) => (cond (foo) (bar) (baz) (plugh))
>
> > This particular CL difference is listed on the wiki page you listed:
>
> >http://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_L...
>
> > I also didn't have anywhere near these kinds of problems getting things to
> > work, although I've been doing a lot of Java lately, and more Scheme than
> > CL, so that may have helped.
>
> > I'm sure other folks would also be interested in your contributions towards
> > a CL => Clojure document; sounds like a good opportunity.
>
> > Dave
>
> > --- On Sun, 11/16/08, Brian W <[EMAIL PROTECTED]> wrote:
> > > I'm going to assume this is serious and not a joke, but you do
> > > realize Clojure is already quite well documented at clojure.org?
>
> > > #t t => true
> > > define defun => defn
> > > car, cdr, caar, etc. ~> first, rest, ffirst, rrest,
> > > frest, rfirst
>
> > > arglists are vectors because [ ] stand out better
>
> > > On Nov 16, 2:31 pm, Simon Brooke
> > > <[EMAIL PROTECTED]> wrote:
> > > > Has anyone written a very simple introduction to
> > > Clojure for LISP
> > > > hackers? I've spend an evening playing with it
> > > pretty intensively, and
> > > > thus far I haven't got a thing to work. I've
> > > readhttp://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_L...,
> > > > but it hasn't helped me.
>
> > > > In LISP:
>
> > > > * (defun fact (n) (cond ((= 1 n) 1)(t (* n (fact (- n
> > > 1))))))
> > > > FACT
> > > > * (fact 10)
> > > > 3628800
>
> > > > that is Common LISP, but what the hell; in Portable
> > > Standard LISP it
> > > > would have been identical except 'de' instead
> > > of 'defun'; in Scheme
> > > > it's a little different:
>
> > > > > (define (fact n) (cond ((= n 1) 1)(#t (* n (fact
> > > (- n 1))))))
> > > > > (fact 10)
>
> > > > 3628800
>
> > > > But the family resemblance is there... So, let's
> > > try it in Clojure:
>
> > > > user=> (defun fact (n) (cond ((= n 1) 1) (t (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: Unable to resolve symbol: defun
> > > in this context
> > > > user=> (de fact (n) ( cond ((= n 1) 1) (t (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: Unable to resolve symbol: de in
> > > this context
> > > > user=> (def fact (n) ( cond ((= n 1) 1) (t (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: Too many arguments to def
> > > > user=> (defn fact [n] (cond ((= n 1) 1)(t (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: Unable to resolve symbol: t in
> > > this context
> > > > user=> (defn fact [n](cond ((= n 1) 1)(#t (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: No dispatch macro for: t
> > > > user=> (defn fact [n](cond ((= n 1) 1)(#true (* n
> > > (fact (- n 1))))))
> > > > java.lang.Exception: No dispatch macro for: t
> > > > user=> (defn fact [n] (cond ((= n 1) 1)(true (* n
> > > (fact (- n 1))))))
> > > > #'user/fact
>
> > > > OK, what's with the funny square brackets? A
> > > sequence of forms
> > > > enclosed in square brackets is a vector, not a list.
> > > Why is the
> > > > arglist for a function a vector? For now let's
> > > accept that it is, and
> > > > pass on.
>
> > > > user=> (fact 10)
> > > > java.lang.ClassCastException: java.lang.Boolean cannot
> > > be cast to
> > > > clojure.lang.IFn
>
> > > > OK, so that doesn't work. As Zaphod memorably put
> > > it, 'hey, what is
> > > > truth, man?' Good question:
>
> > > > user=> (true? 'true)
> > > > true
> > > > user=> (true? true)
> > > > true
> > > > user=> (true? t)
> > > > java.lang.Exception: Unable to resolve symbol: t in
> > > this context
> > > > user=> (true? 't)
> > > > false
> > > > user=> (def t 'true)
> > > > #'user/t
> > > > user=> (true? t)
> > > > true
>
> > > > OK, now we know the truth, surely we can write a valid
> > > fact?
>
> > > > user=> (defn fact [n] (cond ((= n 1) 1)('true
> > > (* n (fact (- n 1))))))
> > > > #'user/fact
> > > > user=> (fact 10)
> > > > java.lang.ClassCastException: java.lang.Boolean cannot
> > > be cast to
> > > > clojure.lang.IFn
> > > > user=> (defn fact [n] (cond ((= n 1) 1)((true?
> > > 'true) (* n (fact (- n
> > > > 1))))))
> > > > #'user/fact
> > > > user=> (fact 10)
> > > > java.lang.ClassCastException: java.lang.Boolean cannot
> > > be cast to
> > > > clojure.lang.IFn
>
> > > > OK, it looks like whatever's causing the break
> > > isn't the guard on the
> > > > second cond branch. Let's for a moment try
> > > something that's purely
> > > > boolean:
>
> > > > user=> (defn band [l] (cond ((nil? l) true)((true?
> > > (car l))(band (cdr
> > > > l)))))
> > > > java.lang.Exception: Unable to resolve symbol: cdr in
> > > this context
>
> > > > No CDR? It's LISP, but it can't fetch the
> > > contents of the decrement
> > > > register? fifty years of LISP history tossed into the
> > > dirt. So if the
> > > > CDR isn't called the CDR, what is it called (and
> > > what's the CDADR
> > > > called)?
>
> > > > user=> (defn band [l] (cond ((nil? l) true)((true?
> > > (first l))(band
> > > > (rest l)))))
> > > > #'user/band
> > > > user=> (band '(true true true))
> > > > java.lang.ClassCastException: java.lang.Boolean cannot
> > > be cast to
> > > > clojure.lang.IFn
>
> > > > OK, can we write any function at all that works?
>
> > > > user=> (defn square [n] (* n n))
> > > > #'user/square
> > > > user=> (square 4)
> > > > 16
>
> > > > Fine, so recurse up from that:
>
> > > > user=> (defn power [n m] (cond ((= m 0) 1)(true (*
> > > n (power n (- m
> > > > 1))))))
> > > > #'user/power
> > > > user=> (power 2 2)
> > > > java.lang.ClassCastException: java.lang.Boolean cannot
> > > be cast to
> > > > clojure.lang.IFn
>
> > > > Arrrrggghhh...
>
> > > > Getting LISP to work seamlessly inside a Java
> > > environment with easy
> > > > intercalling between LISP and Java is a very big win,
> > > and potentially
> > > > knocks things like JScheme and Armed Bear Common LISP
> > > into a cocked
> > > > hat...
>
> > > > But it would be nice to be able to get started!
I agree with what Luc said. What is most exciting about Clojure is
that it represents a real possibility for people stuck in Java to be
able to switch to Lisp. Oh and the multi threading thing too, Common
Lisp isn't even thread aware in the standard.
If you don't like it because it's not *exactly* like what you have
used before, then you don't have to use it. Clojure is also homoiconic
despite it's complex syntax so I don't really get your arguments
against having syntax for other data types than the linked list.
/Markus
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
