On May 1, 2013, at 8:50 AM, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:
> Paul Landes <lan...@mailc.net> writes: >> I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all >> points. The issue for me is it isn't Lisp. It's lisp like and has many of the >> features, but still isn't lisp. > > Wikipedia disagrees with you! Don't believe everything a community definition site tells you :) Hehe, seriously, at some point it becomes semantic, but if I were to edit this wikipedia page I'd emphasize syntax and speaking from experience, the devil is in the details when parsing it. > There isn't a complete definition of lisp, but functional, untyped, > prefixed and with lots of parenthesis seems to cover it. Clojure isn't > common lisp for sure, but then neither is Elisp. Again, I think we're talking about semantics, but most would agree that Elisp is a lisp dialect and again the operative disagreement is over syntax of the language. > Having written quite a lot of Clojure using an Java API underneath, I > think the integration is very nice. The difference is that Clojure was > designed to be tightly integrated with the JVM; ABCL was designed to be > common lisp on a JVM. I don't disagree, but why couldn't you macro out the Java native calls in CL and carry object instances in CLOS objects? In fact, I've already started this work. --<interesting twany library code examples snipped>-- > >> I see this turning into religion very soon, and I really don't want >> that :) > > > I think we can avoid this. Now that I have written this email, I won't > say more! At the end of the day, the choice is likely to be yours, as I > am not likely to find the time to do more than contribute a little. > > It is, of course, absolutely the case that I have an asymmetric > knowledge; I've used clojure a lot since last October, while my closest > exposure to CL is emacs, and I've never used ABCL. I actually have the same amount of experience with Clojure (one project) than CL. I'm trying to make this decision to fix head aches we currently have in JDEE and get the project moving again, which has been very difficult I think we can all agree. >> However, the big thing to me is that at the very minimum the data >> communication is between Emacs and ABCL is still s-expressions. The biggest >> pain point is creating lisp and in beanshell/java and hoping Emacs makes >> sense >> of it. If both languages speak the same basic same language development >> should >> prove to be faster and the project easier to maintain. > > Sure, it's just a question of how similar. You can manipulate common > lisp or clojure in elisp both as strings or as lisp data structures, and > vice versa. Frankly I disagree: given more keyword and syntax differences parsing and munging code going back and forth between the two will be heavier if Clojure is chosen. --<multi-lang/nrepl snipped>-- >> This sounds good on paper, but my gut tells me we'd waste much less time and >> effort if we could just all agree on one language--but I doubt that will >> happen and someone (the one with the most time) will just have to make this >> call. > > Yes, I agree. I've no desire to see multiple languages in JDEE; a > pragmatic replacement for beanshell is required, and a JVM hosted lisp > makes a lot of sense. Either clojure or ABCL could fulfil that > requirement. We agree on this point and I'm still not ruling out Clojure as they both have advantages and disadvantages. > The secondary points that I raise are important also, though. Having a > goal of replacing all the java so that JDEE would not require a > compilation step, would really simplify the build. And, being able to > launch the JVM hosted from Maven, (as well as without) so that it shared > all the classpath settings, would be a big save. Agreed. > At this point, the my contribution to the religious war ends! I'll look > forward to what ever is decided. Your discussion is helpful and your arguments are persuasive. Thanks Phil. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ jdee-devel mailing list jdee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdee-devel
