HI Phillip, 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.
I see this turning into religion very soon, and I really don't want that :) Now that I've said that: http://en.wikipedia.org/wiki/Greenspun's_tenth_rule 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. There will be those that use an Emacs IDE that will want to use Clojure, others JRuby, Jython etc. I can't see adding these other languages in the 0th iteration of the new software but I could see abstracting some general API that could plug into a JVM and provide interfaces to standard services provided (i.e. reflection, template services, wizards, debugging, compiling (maven integration), etc). That would have to be a later iteration though. The idea is to have Emacs fork a JVM that acts a server and binds ports for each language. This wouldn't be a command event loop (currently beanshell impl), it would be a well defined protocol where a client specifies the language and communication parameters. The first and only would be CL and ABCL would interpret and respond. Later we could other languages as plugins so if you love groovy create your own groovy lang plugin and implement a group of services for the JVM to hook into. Given this design bringing other languages should be trivial but also give us a way of reusing (at least the core) of the services. 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. On Apr 30, 2013, at 5:44 AM, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote: > Paul Landes <lan...@mailc.net> writes: >> The basic idea would be to pretty much move all the things that beanshell and >> semantic currently do to Java packages. That means using things like >> compilation tools that come with the JDK and other OS packages (i.e. ASM) for >> parsing, code completion, wizards, templates etc. The basic idea is using >> straight Java packages for anything involving Java operations. This would >> really slim down the code base and make it manageable. >> >> ABCL (common lisp implementation) would replace the now dead Beanshell >> language, and frankly, seems like a better fit since its lisp and not Java. >> Another benefit to this is it already works nicely with Slime so we could get >> rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library. >> Just >> that would be a huge victory in my mind as I've spent hours and hours >> debugging these two parts that stubbornly do not play well together (i.e. >> beanshell start times and process hangups). > > > Beanshell was good for it's time, but is now a big problem with JDEE. > Another option over ABCL would be Clojure. There is quite a big emacs > community behind it now, with tools like nrepl.el nicely separate from > the clojure-mode. The Java integration is also very nice and, from a > quick look at ABCL, better than ABCL. It's already got some stuff we use > (a Javadoc lookup for instance). > > The negative side is that Clojure is Eclipse Public License. My > interpretation of these two licenses is that we *could* use Clojure (the > GPL talks of "standard interface" which would cover this), but we would > be restricted for other packages which are EPL which could not be > validly linked to JDEE. > >> >> Another idea I had is to move everything to maven so there would be maven >> integration (bridged through ABCL) for compilations. If others still want to >> use Ant or something else we can talk about some abstraction layer. >> >> Many nice useful parts of JDEE would be folded in (i.e. syntax highlight, >> maven integration or Malabar mode might be folded in for this). >> >> I'm glad to put this on paper and if there is sufficient interest by those >> WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll >> continue this process. > > The other thing that would be worth thinking about is what we *do not* > need. My own feeling is that all the template stuff can be ditched; > writing these templates was always a total pain in the ass, and why > bother -- yasnippet does the job. > > As far as I can tell, it should be possible to get maven to launch the > nrepl-server. So, all the dependency stuff, classpath and all that > nastiness would go. The project would be maintained in pom.xml. An ant > task wouldn't be too hard. This would mean a lot of the project > switching stuff could be binned. > > JDEE cannot compete with Eclipse or netbeans. The Emacs ecosystem, > however, can, especially for people who, like myself, use Java as one of > many tools. > > Caveat to all of this, of course, is doing the work. I'm a very > occasional Java user these days, so like everyone else, can only > contribute a small amount of time. > > Phil ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ jdee-devel mailing list jdee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdee-devel
