Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Kean

Pages: [1]
1
AutoCAD talk / Re: Programming languages and AutoCAD
« on: March 23, 2011, 07:55:23 PM »
An interesting topic! :-)

Before getting into the meat of the discussion, I'd just like to correct the statement about the decision to choose Lisp in AutoCAD, back in the day:

Quote
The LISP language is certainly the best known. He had been chosen by Autodesk long ago because it was a very high level language suited to the unstructured aspect of an AutoCAD drawing.

It's actually more accurate to say - and I'm paraphrasing John Walker's comments from his interview for my blog: http://through-the-interface.typepad.com/through_the_interface/2008/09/an-interview--1.html - that Lisp was chosen because it was free, extensible and fitted in a 64K memory segment.

Now on to the discussion of getting the right "high-level" language inside AutoCAD...

When the term high-level has been used in this article, I assume what is meant is succinct and explorable: the code shouldn't have the kind of overhead .NET currently has - you have to use transactions, open container objects, etc. - and it shouldn't need a separate development tool (even if it's integrated). The fact AutoLISP can be entered directly into the command-line (basically via an integrated REPL - http://en.wikipedia.org/wiki/Read-eval-print_loop) is of huge benefit from an explorability perspective.

.NET's "level" has been dictated to a large extent by its connection to ObjectARX: the power it gives to some, due to the thinness of the layer it has on top of ObjectARX, is also a disadvantage to others, who want to do something quickly and simply. While it's possible to use exactly the same API as VBA from .NET (you can simply choose to use COM rather than the "managed" API to AutoCAD from C#/F#/VB.NET, something that doesn't appear to have been mentioned in this thread), even that "level" perhaps isn't right for some people.

I see a few ways we might get a better end-user programming model inside AutoCAD...

One would be to pursue the kind of approach presented by Albert Szilvasy at AU 2009 (http://au.autodesk.com/?nd=e_class&session_id=5164), where he demonstrated potential extensions to our .NET interface - based on the IDynamicObject interface available in .NET 4 - that could enable simpler scripting of AutoCAD objects. Such as this Python fragment that would prefix the names of all layers in the drawing (apart from layer 0) with the text "First_":

for o in ThisDrawing.Layers :
  if o.Name != "0" :
    o.Name = "First_" + o.Name

What's happening here is a dynamic open/close on each object as it is accessed, making it more succinct and yet still using the same powerful .NET API under-the-hood. And with this model it would be straightforward task to allow such text to be entered at the command-line (although Python's dependency on whitespace/indentation might make it complicated in the case of this specific scripting language, which was demonstrated in Albert's example simply because of the availability of IronPython: not because it's necessarily the "right" language).

So that's one potential avenue for increasing the explorability and succintness of in-process .NET code (but let me be clear - Albert's implementation remains a "proof of concept": it may or may not be something we end up pursuing).

Given the shift towards delivering our products as part of Suites - which I'm sure you've heard about - I do see an increasing need to enable generic out-of-process interoperability (possibly at the scripting level) between our products/web services. This is an area I'd expect us to be looking at, over the coming releases (it's certainly one I'd like to see addressed, for whatever that's worth :-).

Kean

Pages: [1]