Programming languages and AutoCAD

[patrick.emin]

Here is an article I wrote about programming languages for AutoCAD, need for a change?

[Anonymous]

Wow...

That's a lot of words for someone who apparently doesn't get the complexities of programming.

1.  AutoCAD is a HUGE program.  Makes the standard Office Suite look like childs play.  Not to mention all of its add-ons, verticals and relatives.  Even drawing a simple design takes most people professional level training (some can pick up on it, by doing this training on thier own)

2.  User friendly languages are always limited, BECAUSE, the easy user doesn't want to concern themselves with database management, and all the custom object abilities the 'professional level developers' are consistently called in to create.  So just use Action Recorder macros and be happy (until you hit a new limit).

3.  Having evolved from basic, to Lisp, to VBA, to (VB).Net, to XAML(WFP), and still pushing forward, I've seen the changes made to each language, and the necessary responsibilities given each set of enhanced power. (how many ways can you crash AutoCAD on purpose?!)

4.  YES the user does complain about 15 seconds vs 10 seconds of processing time.  Even when drawing 10,000 lines and running 10,000 calculations.  And Man does it cause us to jump through hoops to restructure entire programs just to squeeze out 5 seconds.

5.  As it stands .Net is quite capable of performing any action required by an AutoCAD developer.  It is the API (managed or not) that Autodesk develops that makes the difference...

And so we wait.

jvj

[patrick.emin]

---

@Anonymous wrote:

Wow...

That's a lot of words for someone who apparently doesn't get the complexities of programming.

---

Thanks for your comments. This is precisely because I know enough of programming and its complexity that I wish we think more about 99% of end users not concerned at all about these milliseconds and less about the 1% who might consider programming as a sport and as an art "in fine". There is a place for a human programming language.

[Anonymous]

Like I said earlier, Action Recorder.  Its easy and fun! 

But if you want to do more, you are going to need to know more fundamentals about how the program works.  I call that diving deeper.  In short, to MASTER the program, (there's more than 'less than 1 percent' of us, I'm sure), then you need to be ready to use STRONGER (not weaker) languages.

BTW what discipline(s) do(have) you work(ed) in?  Also what languages do you program with?  I could always use a good guru.

jvj

[Anonymous]

Exmateria, I think your article claims to be in favor for a more practical programming language yet it seems to favor LISP over others. As an engineer, not a computer engineer, who needs to create tools to create, which includes computer programs of all sorts in many, many computer languages, I would put LISP near the bottom of the list almost next to working in binary code. It is not a hard language, its just that I cannot bear to wade through code that uses a nested syntax. So because of this favor for LISP that I wonder if you are really on our side. I do agree with much of what you are writing but I as a user, a real user who wants to create stuff that does stuff because numbskulls at Autodesk and Microsoft don't have a clue how someone needs to use their application in ways they have not considered, I can tell you the problem is mostly the IDE not the language. VS is a barrier. Beware too of this DesignScript. Have you ever tried to program in AppleScript? Much as I like Apple's products and the notion that a language should read like an english sentence, AppleScript looks like it might be easy, but it is not. It is Objective C, or some precursor, in sheep's clothing. You are lost in AppleScript if you don't grok how the nouns, verbs and adjectives relate. I would put AppleScript slightly above LISP in my notion of preference. In my book anything that has an IDE similar to what we could do in VBA, with no OS restrictions and the ability to quickly test and experiment in situ on the fly is what would fit the bill, regardless of whether letter the language is.

[patrick.emin]

I am not particularly in favor of LISP, sorry if I gave this impression. Let's say I found VB NET extremely verbose to achieve, in most cases, the same thing as we can do with one line of LISP... Sure there are things wich cannot be done with LISP and as I mention it in my article, I wish good luck to those who have to create complex dialog boxes with LISP, or with DCL rather. My reflexion was not intended to bring arguments in favor of a particular existing computer language for AutoCAD but more to open a reflexion about what if we tried to get closer to a very broadly spoken one, I mean the english language? My theory is that a natural language interface would be feasible, not in the vast computer domain, but in the narrow field of the AutoCAD object model.

[Anonymous]

In that case, then the best language is the VB.Net language, and a simpler API to use it with (gl w dat).  VB.Net is a simple to read 'English' language that definitely follows the AutoCAD object model.  I guess you just don't understand the object model that well.  Just imagine, for every time you type in line at the command prompt, all these other things take place:

• Editor engine asks for prompts to get points. (with automatic searching for running object snaps, and selection highlighting, custom to every type of object you hover over)
• Database engine opens a transaction (so you can hit undo later, without thinking about it)
• Graphics engine creates a line entity (so you can see it on your screen, and drag around a jig of the line reshaping)
• Database engine accepts the line and closes the transaction (so the database is left itact, and knows what point to undo too)
• Editor cleans up the command prompt (making it appear ready for the next command)

Problem is, when it boils down to it... It's never just that simple.  Those previous steps ARE the easy steps.  It DOES get much more complicated than that if you start talking about asking windows to draw the line, write the command prompt in a separate floating window, and manage a database in a kernal section of memory and virtual memory that will hopefully remain intact until you hit save to write it to a hard drive somewhere.  Now image the next level... Kernal, where we break your single text character down into binary, and process a first level network style handshake with the motherboard, memory, and processor.

The highest (simplest) level of customization is Dynamic Blocks, and Action Recorder (which both take training but have  cool interfaces to see what's going on while your programming them).  Then there's the limited (and hard to read) LISP.  Then theres the VBA (out dated, thanks to MS going away from 32bit limits).  Next is .Net (a Common Runtime Language that is capable of writing standard code from various languages, and compiling for various Kernals, IN ONE SHOT!).  Then theres ObjectARX (writtin in C++), which IS the closest level Autodesk will allow anybody to the guts of AutoCAD without being an employee.

In short Pick your Poison and Drink it.  There's still a learning curve, and limits.  But if you want more power, more control, then you ARE going to have to dive deeper.  Heh, go ahead and write your own CAD platform.  Its working well for the competition.. Right?

jvj

[dgorsman]

There's the rub - a user who spends time learning to use the program (AutoCAD, Navisworks, whatever) will have little time left over to learn the programming chops necessary for .NET or even the more esoteric LSP workings.  Somebody who has spent time learning to program managed .NET or ObjectARX definitely doesn't have the time to be a full-time user of the software.  There are those who dabble in each, and those who claim expertise in both (I question that claim as they are a very rare species indeed, and likely do nothing but "play" with the software).

LSP is perfect for the short, user-created automation of simple tasks.  Its easy to pick up, simple to distribute and update, and portable across many versions of AutoCAD (try running a .NET DLL or ObjectARX this year on AutoCAD released five years from now without the source code at hand).  Managed .NET lets programmers add a lot more power, up to full fledged add-ons.  VBA used to provide a middle ground of adding a little more control with a little more complexity.

The retirement of VBA support means there is now a hole in the middle - a means of automation that provides more power that LSP (especially with dialogs) but is simpler and faster to implement than managed .NET.  It may well be that a "natural language" method may be developed or adapted from some other scripting language but frankly I think its a pipe dream.  The simplistic methods desired cannot support the complexity necessary to get the results.

[Anonymous]

I agree with dgorsman fully.  If you take a look at it from Autodesk's point of view (just speculating here), they have lots of work to do just to get the existing supported language API's up to snuff with all the features of AutoCAD.  So a new language is not likely to happen.  A better option would be to make design script into a .Net CLR language, and have it use the same object tree. 

jvj