Author Topic: Programming languages and AutoCAD  (Read 12778 times)

0 Members and 1 Guest are viewing this topic.

Offline Patriiick

  • Administrator
  • *****
  • Posts: 130
  • Karma: +1/-0
  • Gender: Male
    • prefered language: VB
    • Prog expertise: Good
    • View Profile
  • Twitter: @Patriiick
Programming languages and AutoCAD
« on: December 01, 2010, 09:07:26 PM »
Read aloud:

Hello, I'm going to talk today about a subject dear to my heart, programming languages and AutoCAD.

AutoCAD is dear to my heart because I worked with it for very long, about 20 years. At first, I drew lines that were supposed to represent real things. This is typically how the draftsman and AutoCAD work, creating geometric objects representing real objects. Thus, a double line represents a  wall in architectural drawing. We know this because a wall is conventionally represented as such. We are sure that this is not a pipe, because it is virtually impossible that a pipe is located here on the plan, without putting the building in danger of collapsing. This tells a lot about the empiricism of the method ...

This approach has limitations. It can lead to misinterpretations. It assumes that the draftsman, and all those who read his plan, know about the industry, conventions and symbols to represent reality.

For many years, it was the only way to work when people did not yet have computers. No other solution than the good old drawing board.

The 2D Computer Aided Design has long been the standard in computer drafting. Things have started moving when we could assemble some primary objects such as lines, and make a block of them. Then give it a name. But we still stayed in the symbolic field.

Much later, we started using 3D CAD, particularly in the field of mechanics, and later, in the field of architecture. The idea then came to no longer represent and manipulate only the primary objects and clusters of primary objects such as blocks, but actually existing objects such as walls, windows, furniture, etc.. We began to give intelligence to objects ... I leave you to ponder on the end of this sentence.

Of course, these real-world objects were virtually always represented by a set of geometric primary objects. It can not be otherwise. We can not fit an entire building in the memory of a computer, as powerful as it may be. Do not believe what they tell you, the Building Object Model (BOM), does not exist yet ...

But what this has to do with programming? For I can feel impatience in your eyes.

Programming a computer is writing a series of instructions for it to perform tasks that would be too cumbersome or too slow or impossible to perform by a human being. And it is clear that in CAD terms, particularly AutoCAD, many programs have been writen almost since the origin of the software to automate the design. 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. On the other hand, this language can manipulate lists, ie collections of objects, and God knows if in an AutoCAD drawing there are many collections of objects.

But if you look at the source code of a program written in LISP, you will hardly recognize the objects of the real world. You may be able with a little luck, if the programmer has done its work, recognize the names of certain variables. But otherwise, nothing is further from your drawing that the source code of a LISP program.

Programming is a job for specialists. While many people jumped into AutoCAD LISP programming, and came to make respectable programs often through many hours, sometimes on their own time, and I speak knowingly, spent documenting, interacting with other people on the Internet, reading books on the subject, to acquire basic knowledge of the programmer. Despite the LISP language is very nice, coming from artificial intelligence concepts, it still requires smart programmers.

Things were quite clear when LISP was the only way to program in AutoCAD, I speak of course of end users programmers, and not development professionals, who programmed in C language.

But you will say, things are quite clear: to write a program, you must be a programmer.

Well, it does not seem to me that this is an absolute necessity, even if it has always been the case. To be a good programmer, you must have certain qualities. You must have logic, you must know the field of application of your programs, ie AutoCAD, be able to speak correctly, understand specifications, build a project, and then an algorithm and then write code.

Note that for LISP, it is not necessary to know the intricacies of how a computer works, and how work a compiler.

This is probably one reason for the popularity of LISP. It is accessible to non-specialists.

Then came much later Visual Basic for Applications (VBA), and more recently the Microsoft environment. NET, which is presented to us as the pinnacle of development environments. At that point the poor VBA is slowly abandoned despite the many services he has rendered.

Does the VBA became a bad language? Is LISP obsolete?

No, no. This is not that at all. The VBA is abandoned because Microsoft has decided so. What do we have instead? Well, you still have the old LISP that can render services, except if you have to program dialog boxes in which case you'll have much trouble. And then of course the famous. NET Visual Studio that Microsoft is pushing with its Autodesk partner.

Only now it is more difficult. You don't switch from an appropriate language such as AutoCAD LISP, for a language still quite suitable as AutoCAD VBA, but we switch from two languages, sometimes complementary, moreover, the LISP and VBA for an environment with several programming languages, which is quite clearly a tool for professionals.

That is the node of the problem. We hear that NET is better, is faster, is more powerful than what we had until now.

But we also hear more and more little voices saying best is the enemy of good ...

So we've moved from a very high level language, LISP, to a language level a bit lower, the VBA language to even lower, Visual Basic, C# or F# in the. NET environment. To be forced to move from a high level language to low level language does not seem to me we are raising the level, but instead we are likely to soon touch the floor. Nothing less than that.

Because ultimately, what is the purpose of the programming in AutoCAD? Is it knowing the possibilities of the machine, worrying about how a DLL is compiled, win two milliseconds here and there? Not at all, these things are concerns for professional programmer disconnected from the real world. AutoCAD end users want the job to be done more quickly than by hand, and frankly, a procedure wich takes 2 ms more than another is totally meaningless.

In the field of programming for AutoCAD, we are clearly starting to get away from the basics needs. The people who program for AutoCAD waste time learning things that can be used in designing an operating system, but certainly not in answering CAD users needs.

To take the example of creating a single line, it is of course much faster to program in LISP or VBA, that to do so using .NET environment. I think any programmer will not deny that. You can see .NET developers attempting the impossible and pathetic, but brave, explanation of .NET merits:

If a program draws 10 000 lines with LISP, 10,000 lines with VBA and 10,000 lines with Visual Basic .NET, . NET draws these lines much faster ... Big deal!

Nobody cares. What AutoCAD draftsman spends his days drawing every 10 seconds 10 000 lines? I'll tell you what interests the draftsman using AutoCAD developments: it's when requesting a modification in a development from his IT department, the computers guys will have to correct one line of code rather than 25. And frankly, the developer is also interested in that. And this certainly will not happen in the .NET environment, because while the LISP guy has already done its correction, the VBA programmer is finishing typing its line of code, and the unfortunate .NET programmer is still looking for an hypothetical Web support among hypothetical examples of codes routines that will allow him to understand in what dialect to talk to the computer.

So everything is still to be invented. I almost said to be reinvented. No. We must take the problem at its root. We have to start from the begining, that is the end user. Inventing a programming language that is a level far higher than VBA and LISP. A computer is quite capable of understanding a sentence logically expressed as this: I draw a polyline from the point 0,0, then I go to 5,5, and then I go to 10,10. There is absolutely no problem for a computer to understand this sentence. The huge advantage is that human beings around the machine, yes there are still a few, will also understand what it means. It is a decisive advantage because we will not need Champollion and the Rosetta stone and spend hundreds of hours transcribing spoken language into language understood by the machine.

 Note that this already exists, it is called algorithmic. But computer specialists will tell you that a computer can not directly understand an algorithmic language. That's true. Well they just need to get back to work, and program the intermediary level between the machine and humans. Instead of leaving it to companies IT guys using AutoCAD who really have something else to do but to understand the inner workings of machines.

All efforts put into the development environment. NET should therefore be turned into writing independent libraries capable of manipulating objects that AutoCAD draftsmans know. Thus the role of the programmer in the IT department of these companies is to describe an algorithmic procedure that would be transcribed in a transparent language understandable by the machine, then the final code would be run.

And I'm sorry to say, but Visual Basic, C #, F #, have no resemblance at all to a very high level language.

The .NET development environment is supposed to meet every need, unfortunately, and therefore certainly not the particular needs of AutoCAD draftsmen.

I end on a hopeful note: it seems that a new language called DesignScript is coming out, these are the rumors at Autodesk University 2010, very good. But as I understood, even if we will have more precise information later, it would be a sort of macro language rather designed for the field of construction and architecture.

What I am thinking about here is not something for a particular product or even domain, because even if you are under the impression everyone is on the 3D bandwagon manipulating clever objects, most people still draw 2D objects that are entirely virtual and symbolic, and I have a feeling that these people are being left behind by genius nerds who believe they have done a great deal in finding out that the essence of existence is to save two milliseconds.

this article is available in french
cet article est disponible en français

versão português


target audience:{intermediate}
« Last Edit: July 24, 2014, 08:47:00 AM by Patriiick »

Offline SEANT

  • Newbie
  • *
  • Posts: 7
  • Karma: +1/-0
    • prefered language: C
    • Prog expertise: Good
    • View Profile
Re: Programming languages and AutoCAD
« Reply #1 on: December 03, 2010, 02:20:46 PM »
As a draftsman I’d have to agree with quite a bit of what you said.  Generally,  a well qualified AutoLisp programmer would have a CAD related routine up and running in less time than a comparable .NET effort.   

If we expand the scope beyond that of just the Cad operator, though, to everyone that has a stake in the design information (accounting, marketing, etc.) then we may find that a multi-conduit automation project via AutoLisp is not so efficient.  I suspect this is the level at which .NET languages start to shine.  I may even suggest that, at this “enterprise wide” scope, .Net is at the highest viable programming level.
   
Allocation of resources is another concept that should be explored further; specifically with regard to Autodesk.  As you’ve mentioned, the AutoCAD application engineers have concerns that may not be applicable to the Lisp programmer (speed, security, etc) which justify the use of a very low level language.  New feature (often referred to as “bloat”) are most popular when they have minimal impact on limited system resources.   One of the nice aspects of .NET is the ease at which these low level C++ objects can be exposed.  Given that the programming resources at Autodesk are also limited, more can be offered for less with .NET.   Even though AutoLisp may eventually automate some specific task with 75% fewer lines of code, it may have to wait several releases for the opportunity.

Offline robertson1

  • Newbie
  • *
  • Posts: 1
  • Karma: +1/-0
  • Gender: Male
    • prefered language: C
    • Prog expertise: Good
    • View Profile
Re: Programming languages and AutoCAD
« Reply #2 on: December 06, 2010, 02:39:34 PM »
Yes, I think there's definelty space there for a new programming language targeted at simple repetetive tasks. I always thought it would have been good to have something like a python interpreter embedded into AutoCAD for such tasks.

Maybe your being a bit harsh on the .NET languages though. There fairly easy to learn (much easier than c++ / objectARX anyway) and they do give you a huge amount of control of the internals of autocad (far more than LISP or VBA). I find c# quite pleasant to use although like you say it's definelty overkill for simple tasks.




Offline Patriiick

  • Administrator
  • *****
  • Posts: 130
  • Karma: +1/-0
  • Gender: Male
    • prefered language: VB
    • Prog expertise: Good
    • View Profile
  • Twitter: @Patriiick
Re: Programming languages and AutoCAD
« Reply #3 on: December 07, 2010, 09:27:24 AM »
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.

Offline Kerry

  • C#
  • *
  • Posts: 6
  • Karma: +2/-0
  • Gender: Male
    • prefered language: C
    • Prog expertise: Good
    • View Profile
Re: Programming languages and AutoCAD
« Reply #4 on: December 07, 2010, 09:44:03 AM »

Quote
I am not particularly in favor of LISP

Lisp is where the novice programmer/customiser can make great gains. To disregard Lisp (as an AutoCAD user) is questionable in my opinion.

Quote
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.

Patrick
What do you mean by " a natural language interface" ??
And are you proposing "another" specialised limited usage language for us to learn ?
class keyThumper<T> : Lazy<T>

Offline Patriiick

  • Administrator
  • *****
  • Posts: 130
  • Karma: +1/-0
  • Gender: Male
    • prefered language: VB
    • Prog expertise: Good
    • View Profile
  • Twitter: @Patriiick
Re: Programming languages and AutoCAD
« Reply #5 on: December 07, 2010, 09:53:27 AM »
Lisp is where the novice programmer/customiser can make great gains. To disregard Lisp (as an AutoCAD user) is questionable in my opinion.

"Not particularly in favor of" does not mean "against".  :clinoeil:

Quote
What do you mean by " a natural language interface" ?? And are you proposing "another" specialised limited usage language for us to learn ?

See this article and this one for the definition of a natural computer language.

Offline Kerry

  • C#
  • *
  • Posts: 6
  • Karma: +2/-0
  • Gender: Male
    • prefered language: C
    • Prog expertise: Good
    • View Profile
Re: Programming languages and AutoCAD
« Reply #6 on: December 07, 2010, 11:56:21 AM »

OK, we're using the same definition.
I don't think I need consider it in the remainder of my working life :)
class keyThumper<T> : Lazy<T>

Offline Patriiick

  • Administrator
  • *****
  • Posts: 130
  • Karma: +1/-0
  • Gender: Male
    • prefered language: VB
    • Prog expertise: Good
    • View Profile
  • Twitter: @Patriiick
Re: Programming languages and AutoCAD
« Reply #7 on: March 21, 2011, 09:42:51 PM »
This article has been published by Ralph Grabowsky in his UpFront newsletter on march 2011.

Offline Kean

  • Newbie
  • *
  • Posts: 1
  • Karma: +2/-0
    • prefered language: C
    • Prog expertise: Very good
    • View Profile
  • Twitter: @keanw
Re: Programming languages and AutoCAD
« Reply #8 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

Offline Patriiick

  • Administrator
  • *****
  • Posts: 130
  • Karma: +1/-0
  • Gender: Male
    • prefered language: VB
    • Prog expertise: Good
    • View Profile
  • Twitter: @Patriiick
Re: Programming languages and AutoCAD
« Reply #9 on: April 26, 2011, 08:03:10 AM »
Terry Priest reaction on Ralph Grabovsky newsletter:

"The author has a good point, but a bit wordy. Autodesk does not ship in the AutoCAD box a programming language it intends to develop, or has done anything with for the last 10 years. The out-of-box solution is nearly beyond the abilities of amateur programmers."