Community
Factors to consider:
In-house customization may not always be supported by the same CAD support personnel; people quit, move away, get fired. Few CAD support personnel are hard-core programmers, and many don't even know the basics of .NET. Most CAD support personnel, however, *do* know at least the basics of LISP. Future supportability is key, and leaving behind programs that cannot be maintained by anyone else is bad form.
For professional 3rd party applications development, there really is no excuse for not using ObjectARX/.NET. Professional software companies employ programmers, not CAD support specialists (which is why some software doesn't work exactly as we would like), and they should have the skills to create efficient and robust code that includes proper source code protection (something which is lacking in LISP and VBA).
Speed is also an issue. I'm still learning .NET, but even if I knew it backwards and forwards I would still do the majority of support in LISP or VBA, simply due to the speed of creation and phenomal depth of resources for its use in AutoCAD. Compare the number of LISP entries here with the number of .NET entries.
Available development tools are also an issue. If it comes down to it, I can develop LISP programs on any computer with Notepad. I don't require the .NET framework, any kind of code compiler, not even AutoCAD. In theory, that could be done with say C#, but its much more difficult without the object browser, .NET references, word-completion, and all the other tools the IDE requires for good .NET programming. Also, because of the simplicity of LISP, debugging is much faster and simpler.
In-house customization may not always be supported by the same CAD support personnel; people quit, move away, get fired. Few CAD support personnel are hard-core programmers, and many don't even know the basics of .NET. Most CAD support personnel, however, *do* know at least the basics of LISP. Future supportability is key, and leaving behind programs that cannot be maintained by anyone else is bad form.
For professional 3rd party applications development, there really is no excuse for not using ObjectARX/.NET. Professional software companies employ programmers, not CAD support specialists (which is why some software doesn't work exactly as we would like), and they should have the skills to create efficient and robust code that includes proper source code protection (something which is lacking in LISP and VBA).
Speed is also an issue. I'm still learning .NET, but even if I knew it backwards and forwards I would still do the majority of support in LISP or VBA, simply due to the speed of creation and phenomal depth of resources for its use in AutoCAD. Compare the number of LISP entries here with the number of .NET entries.
Available development tools are also an issue. If it comes down to it, I can develop LISP programs on any computer with Notepad. I don't require the .NET framework, any kind of code compiler, not even AutoCAD. In theory, that could be done with say C#, but its much more difficult without the object browser, .NET references, word-completion, and all the other tools the IDE requires for good .NET programming. Also, because of the simplicity of LISP, debugging is much faster and simpler.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
I say debugging is faster not from experience, but from the simplicity. For example, making a layer current in LISP:
(command ".layer" "set" "LAYER_X1" "")
One line of code, fairly self-explanitory. If I wanted, that could be the entire program, it needs nothing else. Limited possiblities for errors, mostly from mis-spellings. Would you care to provide the equivalent complete code in your favorite .NET language so that I have something to compare with?
I agree that VBA can be used in other programs, and is my langauge of choice when I have to interact with them. If I have to, I can create ActiveX objects in LISP - but again, thats not my first choice.
(command ".layer" "set" "LAYER_X1" "")
One line of code, fairly self-explanitory. If I wanted, that could be the entire program, it needs nothing else. Limited possiblities for errors, mostly from mis-spellings. Would you care to provide the equivalent complete code in your favorite .NET language so that I have something to compare with?
I agree that VBA can be used in other programs, and is my langauge of choice when I have to interact with them. If I have to, I can create ActiveX objects in LISP - but again, thats not my first choice.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
Not entirely true though, is it? For VBA, you need to set that up in a sub/function call. In .NET, there is even more overhead, isn't there? You can't just simply put that string in a file and expect it to work, can you?
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
It seems that you are implying that 'lisp is easier to debug because there's less code'. However, it may be misleading to relate that to debugging itself. That example merely liimits the possible problems. Lisp can have all sorts of other problems, but Lisp has very few tools for debugging compared to Visual Studio or other IDE's. Also, its not always true that lisp is more concise. And my next statement is intended for the OP.
While lisp can do ActiveX, the IDE is not designed for it. That task is better handled by VBA because of Intellisense and other tools. Here, VBA is actually more consise than lisp. As far as other tasks that one language can perform that would force you to use that language, those cases are rare for most people, who are usually not professional developers. Some tasks may be more difficult, but usually there is a workaround to allow you to continue to use your favorite language.
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
How to post your code.
While lisp can do ActiveX, the IDE is not designed for it. That task is better handled by VBA because of Intellisense and other tools. Here, VBA is actually more consise than lisp. As far as other tasks that one language can perform that would force you to use that language, those cases are rare for most people, who are usually not professional developers. Some tasks may be more difficult, but usually there is a workaround to allow you to continue to use your favorite language.
Ed
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
How to post your code.
