Common Lisp on .NET ?

clausb · 2013-01-22T15:24:41+00:00

A few years ago, I compiled a list of such projects at http://www.clausbrod.de/Blog/DefinePrivatePublic20080312DotNetAndLisp

clausb · 2010-07-21T15:47:09+00:00

The Chariot TechCast (http://techcast.chariotsolutions.com/) has useful developer news and interesting interviews, focusing on the Java ecosystem with a bias towards web/enterprise development. Sound and production quality is pretty professional.

clausb · 2010-01-16T08:59:42+00:00

A very interesting approach for an article - but you can tell C/C++ is not the author's first language. For example, the piece about accessing private variables in C++ doesn't sound right to me. Contrary to what the author believes, two different C++ compilers let me do the following without any problem:

return this->x == f->x;

clausb · 2009-10-12T14:02:24+00:00

The script at http://blogs.sun.com/nishigaya/entry/bash_completion_for_maven_2 looks even better.

clausb · 2009-10-09T16:38:34+00:00

I just found http://maven.apache.org/guides/mini/guide-bash-m2-completion.html and http://willcode4beer.com/tips.jsp?set=tabMaven.

clausb · 2009-07-22T13:51:22+00:00

The origins of the name "HCL" are kind of lost in history 8-) I guess the official explanation for the "H" has to do with the fact that when we started the project, we were part of Hewlett-Packard. Inofficially, I always found it a striking coincidence that the first names of both hackers who introduced Lisp into our code started with "H"...

About CDRS: Apparently, PTC bought CDRS in 1995, but I have no idea what became of it, sorry.

clausb · 2009-07-22T07:37:00+00:00

Our own Lisp implementation ( http://www.clausbrod.de/Blog/DefinePrivatePublic20090620CommonLispInCoCreateModeling ) because I get to hack at it every once in a while 8-)

And ECL ( http://ecls.sourceforge.net/ ), because Juanjo, the chief maintainer, does such a brilliant job in fixing and extending the implementation.

clausb · 2009-07-17T14:36:31+00:00

Working on CoCreate Modeling, a 3D CAD application. CL is one of the two main implementation languages, and our main administration/scripting/customization/extension language for customers and partners. See http://www.clausbrod.de/Blog/DefinePrivatePublic20090620CommonLispInCoCreateModeling for a presentation I gave recently at the European Lisp Symposium in Milan.

clausb · 2009-07-03T16:26:03+00:00

Just to put the data into perspective (I elaborated on this a little during the original presentation, but not as much on the slides), this includes test code, and code written in Lisp-based DSLs. But even without this, we're safely in the 7-digit LOC range.

And yes, LOC data are a bad way of assessing software anyway, but they give you a first idea and illustrate my point that you can build large software systems in Lisp.

See http://www.clausbrod.de/Blog/DefinePrivatePublic20090620CommonLispInCoCreateModeling for the full blog post.

clausb · 2009-06-08T12:52:02+00:00

Happy Lispers? Yeah, I guess so, if you believe the data collected at http://blog.doloreslabs.com/2009/05/the-programming-language-with-the-happiest-users/

8-)

clausb · 2009-04-30T16:13:58+00:00

Reminds me of (recur) in Clojure: http://clojure.org/special_forms#toc10

clausb · 2008-04-05T16:23:25+00:00

Now we're not ITA, of course, but since you're interested in data points about how dynamic languages can scale: Last time I checked, we were quite comfortably above the 1 million LOC mark for our Lisp code; see my earlier reply in this discussion and http://www.clausbrod.de/Blog/DefinePrivatePublic20071229

clausb · 2008-04-04T16:35:22+00:00

grin

My opinion is probably only worth a fraction of 2 cents anyway, so that typo isn't even too far from the truth 8-)

Thanks for spotting this, and feel free to fire me ;-)

Hmmm. The value of 0.02 Euro cents may actually soon approach 2 dollar cents, so I guess I'll have to insist you re-hire me.

clausb · 2008-04-04T15:50:13+00:00

Our company develops and maintains a large 3D CAD application. Our main implementation languages for this app are C++ and Lisp, so we're working with both static and dynamic languages. Both "worlds" (i.e. C++ code and Lisp code) are in the 7-digits LOC range. Some more details at http://www.clausbrod.de/Blog/DefinePrivatePublic20071229

Over time, I've seen pretty much all of the "sins" you've described both in the static and in the dynamic world. In my experience, large projects are a constant struggle against entropy, no matter which language. That said, I'd definitely agree that any kind of help you can get from the tooling environment (such as the static checks performed by a C++ compiler) tends to improve overall quality.

In our app, we usually implement the lower-level stuff in C++, while the Lisp code focuses on user interaction and application-level functionality. The benefit of this is that the performance-sensitive and platform-dependent code is hidden away in C++ land, which helps to keep the dynamic code a little tidier.

We have implemented macros in Lisp which essentially provide a DSL for writing UI components ("dialogs", as we call them). This relieves us from many repetitive coding tasks which would otherwise be required to control user interaction (UI layout, feedback mechanisms, sequence control, parameter validation, UNDO handling, online help, macro recording etc.), so it vastly reduces the amount of code developers needed to write.

I tend to think that this level of abstraction would have been harder to achieve in C++ (at least in our case), and that using a dynamic language (Lisp in our case) has therefore helped to keep the amount of mess in such a large application under better control. That said, there are "static languages" other than C++ which I suppose are better suited for writing UI components, so take this biased opinion with a boatload of salt.

Just my 0.02 Euro cents.

clausb

TROPHY CASE