TheSwamp

Code Red => VB(A) => Topic started by: psuchewinner on October 08, 2008, 06:02:02 AM

Title: Can VBA do Everything that Vlisp can?
Post by: psuchewinner on October 08, 2008, 06:02:02 AM
Hi all,
VBA newbie here.....actually I am still learning.  Can VBA do more (or just as much) with ACAD that VisualLISP can?  Not sure if I am asking this correctly but...What are the advantages of VBA over VLisp?  Is it worth my time to learn?  Thanks






M-dub Edit: ficksed speelig misstake : )
Title: Re: Can VBA do Ecrything that Vlisp can?
Post by: Alan Cullen on October 08, 2008, 06:46:13 AM
I'll try again...last time I tried to reply, my computer froze....

From what I have been told by the programming gurus........

Lisp is very versatile, VBA is very exact. So....basically learn both.

I stick with lisp because it does all I need. But I'm sure the VBA troops here will fill you in very quickly with how it all really works.
Title: Re: Can VBA do Ecrything that Vlisp can?
Post by: It's Alive! on October 08, 2008, 06:55:13 AM
VBA's days are numbered according to the development documentation, you should consider learning C#.
Title: Re: Can VBA do Ecrything that Vlisp can?
Post by: David Hall on October 08, 2008, 12:56:28 PM
ditto what Daniel said
Title: Re: Can VBA do Ecrything that Vlisp can?
Post by: Spike Wilbury on October 08, 2008, 01:15:47 PM
ditto what Daniel said

^^^
and triple ditto of what both of you said....

edit/addition: and yes don't waste your time.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: New Shooz on October 08, 2008, 06:35:26 PM
VBA's days are numbered according to the development documentation, you should consider learning C#.

Wasn't this kind of propaganda / diatribe trotted out (with respect to LSP), when VBA was released ?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Swift on October 08, 2008, 09:55:39 PM
VBA's days are numbered according to the development documentation, you should consider learning C#.

Wasn't this kind of propaganda / diatribe trotted out (with respect to LSP), when VBA was released ?

But this one is more a Microsoft thing rather than an Autodesk thing.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: It's Alive! on October 08, 2008, 10:35:06 PM
VBA's days are numbered according to the development documentation, you should consider learning C#.

Wasn't this kind of propaganda / diatribe trotted out (with respect to LSP), when VBA was released ?

I don’t know about that, there is a warning in the documentation directing VBA developers to port their code to C#. Of course you may interpret it as propaganda if you wish  :laugh:
Title: Re: Can VBA do Everything that Vlisp can?
Post by: SEANT on October 09, 2008, 07:00:09 AM
On another forum, I had presented a case that AutoCAD coders (myself included) should not rush to convert their existing VB(A) routines to .NET.  That case was based on the premise that “if it ain’t broke, don’t fix it”, at least not until a significant comfort level with OOP was achieved. 

Ideally, the next rewrite would have all routines work within an enterprise wide structure, (Sales, Construction Docs, Accounting, et. al.) a process that may be the most daunting part of the VBA –> .NET paradigm shift. 

I didn’t realize, however, that such a definitive statement had been made with regard to the future of AutoCAD VBA.  I guess it’s time to turn up the burner.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: New Shooz on October 09, 2008, 07:14:45 AM
I doubt very much whether Autode$k will 'retire' the use of VBA from their products; given that they say on their website that VBA is the world's most popular programming language.
How could any worthwhile company turn their back on that many people ?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Draftek on October 09, 2008, 07:58:38 AM
Yeah, but since Microsoft is not supporting VBA, I believe Autodesk will be forced to move it outside the process and the performance is going to suck!
Title: Re: Can VBA do Everything that Vlisp can?
Post by: FengK on October 09, 2008, 01:02:28 PM

I don’t know about that, there is a warning in the documentation directing VBA developers to port their code to C#. Of course you may interpret it as propaganda if you wish  :laugh:


Daniel, which reference is this statement from?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Bob Wahr on October 09, 2008, 01:18:05 PM
Daniel is either citing a different source or misremembered, but from the AutoCAD 2009 ActiveX and VBA Developer's Guide

Quote from: Page 2, AutoCAD 2009 ActiveX and VBA Developer's Guide
NOTE Microsoft has not promised to provide 64-bit VBA SDK libraries (.dll).  Subsequently, 64-bit AutoCAD can no longer run VBA as an in-proc component; VBA components now run as 32-bit out-of-process COM components, and provides a stopgap arrangement for 64-bit AutoCAD VBA users.  This arrangement might require a few changes to existing VBA code.  This stopgap provision would be deprecated in future versions of AutoCAD and it is advisable for the users to port their existing code to VB. NET.[/b][/b]
Of course, there's no real reason to choose VB.net over C#, and there are a few to recommend the other.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: rkmcswain on October 09, 2008, 01:25:58 PM
Quote from: Chortle
I doubt very much whether Autode$k will 'retire' the use of VBA from their products
Given that we should expect AutoCAD 2010 out in about 6 months, I'm sure it's in Alpha or Beta right now. Of course anyone who has seen it couldn't comment anyway, but it wouldn't surprise me to learn that VBA was not included. On the other hand it may hang around for a few more releases as long as Microsoft doesn't object. But there will certainly be no development towards it. Everything it going .NET.

As it is, VBA code runs about 10X slower in 64-bit AutoCAD.

Title: Re: Can VBA do Everything that Vlisp can?
Post by: rkmcswain on October 09, 2008, 01:34:43 PM
Quote from: psuchewinner
Can VBA do more (or just as much) with ACAD that VisualLISP can?  Not sure if I am asking this correctly but...What are the advantages of VBA over VLisp?  Is it worth my time to learn?  Thanks

IMO - If you already knew VB, and were writing a project specific application with a lot of GUI, and you knew you were going to get a good ROI on the application, then VBA would be OK to use. Otherwise, you might as well move on to .NET.

As far as lisp, there are a few things that lisp can do that cannot be done in VBA without a workaround hack, like (grread), but generally speaking, they overlap.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: It's Alive! on October 09, 2008, 02:25:45 PM

I don’t know about that, there is a warning in the documentation directing VBA developers to port their code to C#. Of course you may interpret it as propaganda if you wish  :laugh:


Daniel, which reference is this statement from?

It's in the ARX docs

Title: Re: Can VBA do Everything that Vlisp can?
Post by: Bryco on October 09, 2008, 05:16:23 PM
Although I don't lisp, if vba goes I'm glad lisp is still going to work as net is so difficult to learn, I think we would have a lot less people being able to tinker with their cad programs. It's almost like be a professional or don't bother. I found vba very easy to learn and use and vb net is a step up but not a replacement.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: SEANT on October 10, 2008, 05:26:46 AM
In addition to the time to proficiency issue; will any of the .NET languages allow for the “quickie fix” possible with VBA or Lisp?  How long has the Minimum Task Length Savings become with .NET

For example, if I had a specific repetitive task – say 15 or 20 minutes by hand – but it had a readily discernable logic flow, then I’d be tempted to automate with VBA, even if the task was not likely to ever be required again.

Obviously, this is depends heavily on proficiency.  As it stands, even a readily discernable logic flow would have to save me several weeks for me to tackle it in C# :realmad:.  I hope to have the MTLS down to one week by the end of the year.  :-)

With the integrated IDE and immediate debugging features of VBA, it may even be faster than Lisp for the +12 line “quickies”.   I don’t know enough about VisualLisp, and its IDE to extend the comparison (for that matter, does the warning about VBA also apply to the ActiveX component of VisualLisp)

For those of you who have achieved a good level of .NET proficiency:  With the added overhead of firing up VS, the not quite immediate debugging, what do you think would be the best MTLS?   
Title: Re: Can VBA do Everything that Vlisp can?
Post by: It's Alive! on October 10, 2008, 06:57:47 AM
I am sure when VBA is dropped, it will be replaced by VSTA.  Also one has to remember that VBA uses the COM API which C#/VB.NET is certainly compatible with.
Long time users of VBA “should” feel right at home using VB.NET with COM.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: jbuzbee on October 10, 2008, 01:15:35 PM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: David Hall on October 10, 2008, 02:58:26 PM
In addition to the time to proficiency issue; will any of the .NET languages allow for the “quickie fix” possible with VBA or Lisp?  How long has the Minimum Task Length Savings become with .NET

For example, if I had a specific repetitive task – say 15 or 20 minutes by hand – but it had a readily discernable logic flow, then I’d be tempted to automate with VBA, even if the task was not likely to ever be required again.

Obviously, this is depends heavily on proficiency.  As it stands, even a readily discernable logic flow would have to save me several weeks for me to tackle it in C# :realmad:.  I hope to have the MTLS down to one week by the end of the year.  :-)

With the integrated IDE and immediate debugging features of VBA, it may even be faster than Lisp for the +12 line “quickies”.   I don’t know enough about VisualLisp, and its IDE to extend the comparison (for that matter, does the warning about VBA also apply to the ActiveX component of VisualLisp)

For those of you who have achieved a good level of .NET proficiency:  With the added overhead of firing up VS, the not quite immediate debugging, what do you think would be the best MTLS?   

As I continue to learn c#, I find myself doing just what you are describing.  And to the debugging, I keep a spare file that just needs to be renamed and placed in the folder, and debugging works fine.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: David Hall on October 10, 2008, 03:05:12 PM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?
I don't have an exact answer for that, but the way I see it is if you have to learn a new language, AND your proficient in VBA, then .Net is a better choice than Lisp/ODCL.  Back 8-10 years ago, when I didn't know VBA at all, and was marginally dangerous with LISP, ODCL would have been a good choice.  But now that I have learned VBA, learning .Net was a pretty easy transition.  Had I chosen VB.Net instead of C#, it would have been even easier.  My point is, if I had to choose b/t LISP and .Net right now, IMO .Net is easier to learn because of my VBA experience.  I have a very hard time using all the new LISP stuff because I have never learned it properly.  Add ODCL on top of that, and that to me is a steep learning curve.  All this is biased in that I have NEVER looked at ODCL, nor have I learned the advanced VL- commands of Vlisp.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: spiff88 on November 09, 2008, 10:26:42 AM
So...if VBA is not present in AutoCAD anymore, does that mean that you will have to have Visual Studio to write code for AutoCAD?  Or will a VBE for .NET be included?  Ideas anyone?  Or is this all just random speculation?

My coding is usually to get data from Excel into AutoCAD in some manner.  If VBA is not around to use - how can I do some of these simple things like "place this MText object here at coordinates in columns A and B with the text in column C, using font size in column D, etc..."

Will I have to write a complete application in VS to do these things?  And if so - why would I have to use C# and not VB.net?

Am I missing something in this discussion that makes my questions irrelevant?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: It's Alive! on November 09, 2008, 10:58:24 AM
So...if VBA is not present in AutoCAD anymore, does that mean that you will have to have Visual Studio to write code for AutoCAD?  Or will a VBE for .NET be included?  Ideas anyone?  Or is this all just random speculation?

My coding is usually to get data from Excel into AutoCAD in some manner.  If VBA is not around to use - how can I do some of these simple things like "place this MText object here at coordinates in columns A and B with the text in column C, using font size in column D, etc..."

Will I have to write a complete application in VS to do these things?  And if so - why would I have to use C# and not VB.net?

Am I missing something in this discussion that makes my questions irrelevant?


VBA will be replaced by VSTA, which has its own IDE. The VSTA IDE will allow users to program in either VB .NET or C# maybe other languages too (I’m not sure).  Also from what I have read, it’s possible that the host application can have both VBA and VSTA side by side, which might help ease migration pains. .. Google VSTA

Also I would assume that while VBA might/will be removed from AutoCAD, I don’t think the COM API is going anywhere as other languages rely on it too  I.e. Visual Lisp


Ps Welcome to TheSwamp
Title: Re: Can VBA do Everything that Vlisp can?
Post by: It's Alive! on November 09, 2008, 11:25:32 AM
here is a link http://msdn.microsoft.com/en-us/vs2005/aa700828.aspx
watch the vids at the bottom..
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Dave R on November 10, 2008, 08:22:47 AM

VBA will be replaced by VSTA...

Daniel are you sure about this? From everything I have read VSTA must be purchased from MS, whereas the Express versions of Visual Studio are freely available. MS Office isn't even shipping with VSTA yet.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Bryco on November 10, 2008, 09:20:55 AM
that macro recorder could save a lot of time, if it works.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Chuck Gabriel on November 10, 2008, 09:29:48 AM
Revit ships with VSTA, so it's not too much of a stretch to believe that AutoCAD will eventually include it as well.  I haven't heard it straight from the horse's mouth yet, though.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: spiff88 on November 10, 2008, 10:50:32 AM
that macro recorder could save a lot of time, if it works.

Exactly.

The Action Recorder built into ACAD 2009 was just not enough (http://www.blog.cadnauseam.com/2008/04/09/autocad-2009-action-recorder-needs-action/ (http://www.blog.cadnauseam.com/2008/04/09/autocad-2009-action-recorder-needs-action/)).  I've been waiting for a macro recorder in AutoCAD for just about forever.  It is incredibly helpful when learning which objects you really want to code.  The macro recorder in Excel saves me time with every use - and I continue to expand my knowledge of the Excel object module.

Maybe I am just not the programmer I imagine myself to be... ^-^
Title: Re: Can VBA do Everything that Vlisp can?
Post by: tjr on November 10, 2008, 11:52:30 PM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?
Legible code? :)

All kidding aside the .NET framework and from what little I know about AutoCAD's lisp variants, they are so different it's hard to compare. Language features aside .NET blows AutoCAD's lisp away in libraries alone. This is big to a lot of people.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Dave R on November 11, 2008, 08:05:46 AM
Revit ships with VSTA, so it's not too much of a stretch to believe that AutoCAD will eventually include it as well.  I haven't heard it straight from the horse's mouth yet, though.

Thanks for the info Chuck. Hopefully Autodesk will let us know well before the switch actually happens.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Glenn R on November 11, 2008, 11:54:37 AM
VB has been retired by MS -> welcome to VB.NET.

It makes sense that they will retire VBA as well -> welcome VSTA.

The model is pretty much the same - MS licenses VBA to app developers (Autodesk includes it in AutoCAD etc.) for the app developers to enable 'scripting' of their application. MS is not supporting VBA on 64 bit, which is the way computing is heading and Adesk is providing a 'fix' that makes it operate in a separate 32 bit process. This is akin to an external VB exe controlling AutoCAD - VERY, VERY slow.

VSTA will be licensed by Autodesk and included in AutoCAD in much the same way that VBA is now (with in-built IDE etc. etc.)

Investing in either autolisp/odcl and/or .NET now would be a wise thing ;)
Title: Re: Can VBA do Everything that Vlisp can?
Post by: sinc on November 13, 2008, 06:04:31 PM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?

The big difference is that with .NET, you have the entire .NET framework available.

Net result is that it can take far less time to develop practically anything in .NET than in VBA or Lisp.  It also tends to be far more readable and maintainable than, say, a Lisp program, which can save more time down the road, if you ever revise your code.  This means it is much easier to write much more complex things with .NET than with Lisp, or even with VBA.

The .NET savings, however, are proportional to the complexity of the task.  There are some simple tasks where Lisp is better than .NET.  In fact, I tend to think of Lisp as "Autodesk's macro language" these days.  But for pretty much anything else, .NET is superior.

Unfortunately, with a rich framework, you also have a lot to learn.  Your effectiveness with the .NET framework is proportional to your familiarity with the framework.  Luckily, the .NET framework can be used from a variety of programming languages, though, so you can use your .NET knowledge with a wide variety of programming languages.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: dgorsman on November 13, 2008, 07:43:20 PM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?

The big difference is that with .NET, you have the entire .NET framework available.

Net result is that it can take far less time to develop practically anything in .NET than in VBA or Lisp.  It also tends to be far more readable and maintainable than, say, a Lisp program, which can save more time down the road, if you ever revise your code.  This means it is much easier to write much more complex things with .NET than with Lisp, or even with VBA.

The .NET savings, however, are proportional to the complexity of the task.  There are some simple tasks where Lisp is better than .NET.  In fact, I tend to think of Lisp as "Autodesk's macro language" these days.  But for pretty much anything else, .NET is superior.

Unfortunately, with a rich framework, you also have a lot to learn.  Your effectiveness with the .NET framework is proportional to your familiarity with the framework.  Luckily, the .NET framework can be used from a variety of programming languages, though, so you can use your .NET knowledge with a wide variety of programming languages.

You're kidding about the "practically anything"... right?  Writing anything short of a major application is going to take longer and a *lot* more code than LISP, and be unreadable to anybody without a .NET IDE installed (I doubt anybody these days is writing .NET -based code in a text editor).  There is also legacy issues to consider - who is going to look after the code when you aren't there?  How easy is it to get somebody who can do .NET vs. somebody who can do LISP?  Will you have to hire in a professional programmer just to keep your system running?  How easy is it to lose the source code?  How easy is it to deploy to users and keep them all up to date?  What about compatibility with each new version (very important with the yearly release cycle)?

Yeah, .NET is perfect for the big complex stuff but doesn't make much sense for most of the typical automation tasks a company will need.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: sinc on November 13, 2008, 08:21:50 PM
I don't really understand most of your complaints...

There are a number of free IDEs.  The code is often a lot more readable and maintainable than a lot of CADR CAR MAPCAR labyrinths with esoteric DXF manipulations.  Don't know about how easy it is to find programmers for one vs. the other...  Haven't lost any source code yet...  Deploying to users is no harder than deploying Lisp...  Some .NET code can be compiled to run on any version of Autocad after a certain year, without needing to be recompiled...

In my experience, a .NET language works better than Lisp for all but the simplest tasks, so not sure why you insist it doesn't make sense.

But it does take some effort to learn the .NET framework.  But since it is so widely-used, .NET experience seems to be getting rather common, from what I've seen.  And the .NET framework often saves huge amounts of time compared to Lisp programmers, who often spend lots of time writing relatively low-level stuff that is already there in .NET.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: tjr on November 14, 2008, 01:10:55 AM
Another question would be: what can C# / VB.net do that AutoLISP / VisualLISP / OpenDCL can't do?

The big difference is that with .NET, you have the entire .NET framework available.

Net result is that it can take far less time to develop practically anything in .NET than in VBA or Lisp.  It also tends to be far more readable and maintainable than, say, a Lisp program, which can save more time down the road, if you ever revise your code.  This means it is much easier to write much more complex things with .NET than with Lisp, or even with VBA.

The .NET savings, however, are proportional to the complexity of the task.  There are some simple tasks where Lisp is better than .NET.  In fact, I tend to think of Lisp as "Autodesk's macro language" these days.  But for pretty much anything else, .NET is superior.

Unfortunately, with a rich framework, you also have a lot to learn.  Your effectiveness with the .NET framework is proportional to your familiarity with the framework.  Luckily, the .NET framework can be used from a variety of programming languages, though, so you can use your .NET knowledge with a wide variety of programming languages.

You're kidding about the "practically anything"... right?  Writing anything short of a major application is going to take longer and a *lot* more code than LISP, and be unreadable to anybody without a .NET IDE installed (I doubt anybody these days is writing .NET -based code in a text editor).  There is also legacy issues to consider - who is going to look after the code when you aren't there?  How easy is it to get somebody who can do .NET vs. somebody who can do LISP?  Will you have to hire in a professional programmer just to keep your system running?  How easy is it to lose the source code?  How easy is it to deploy to users and keep them all up to date?  What about compatibility with each new version (very important with the yearly release cycle)?

Yeah, .NET is perfect for the big complex stuff but doesn't make much sense for most of the typical automation tasks a company will need.
AutoLisp is no easier for things slightly more complex than a macro than C# is. In fact C# makes things 100000x easier to perform simple tasks like display a treeview. Can you even do that in AutoLisp without using a 3rd party tool like objectdcl?

The one thing people fail to realize when they grasp at the "autolisp can do whatever X can do" straws is AutoLisp knowledge is completely useless outside of the AutoCAD world. From what I understand it's not even comparable in features to modern common lisp or scheme.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: dgorsman on November 14, 2008, 02:41:20 PM
No arguments to any of the above, aside from the fact I'm looking at the comparison from the standpoint of a CAD adiministrator, not a dedicated programmer.  Most engineering companies don't or won't have a dedicated programmer on staff and put the AutoCAD customization onto the same person who is responsible for...

- knowing all the little corners of AutoCAD, including known bugs and "gotchas"
- setting up and enforcing standards
- data entry for all the programs (for my part, that means piping specs, data files for piping, steel, electrical programs)
- adjusting the support system to handle differing requirements from various clients
- basic support for supporting programs such as Word and Excel
- evaluating new software and new releases
- planning and executing upgrades and licensing
- knowing the basics of the profession (I need to be part stress engineer, part materials engineer, part piping designer, part civil/structural designer, part IT professional, the list goes on)

... and a bunch of other miscellaneous stuff.  Not a lot of time left over to be learning a dedicated programming language such as C#.  The only reason I have gotten as far as I have is with previous programming experience with C, Java, and machine code (after which LISP is a breeze).  Trying to justify to management the hours spent on converting all of the existing support code would be a hard row to hoe as well especially with a downturn in the economy and the reluctance to spend money for little realized returns.

The problem as I see it is one of time management and diminishing returns.  As both AutoCAD and programming tools increase in complexity the amount of time required to be proficient at both increases as well.  Eventually a "critical mass" is reached where people can only be proficient at one or the other.  I'm sure we would have no problems finding .NET programmers, but their knowledge of the ins and outs of AutoCAD *and* the industry we are in *and* .NET programming as it applies to AutoCAD?  Highly unlikely - it took us 3-4 months just to find somebody with sufficient AutoCAD experience (not even programming) to back me up.  In fact, I see this as the reason why AutoCAD products are on a slow decline in terms of useability.  The programmers that write the software do not have the time to gain the industry experience of actually using the product, while those that are very familiar with using the product in the chosen industry don't have the time to get proficient at the programming tools used to customize AutoCAD to the nth degree.

I still maintain, again from the standpoint of a CAD administrator rather than a programmer, that for most of the common automation tasks needed by engineering companies LISP is the better tool in terms of time spent developing, deployment, and upkeep.  .NET is better for large, full-service-program type automation where the company is unwilling to spend money on a product developed by a software company or no product is available.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Bryco on November 14, 2008, 04:54:36 PM
If the help on net was as good as that in vba net would be a lot easier to learn.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: tjr on November 14, 2008, 07:14:12 PM
No arguments to any of the above, aside from the fact I'm looking at the comparison from the standpoint of a CAD adiministrator, not a dedicated programmer.  Most engineering companies don't or won't have a dedicated programmer on staff and put the AutoCAD customization onto the same person who is responsible for...

- knowing all the little corners of AutoCAD, including known bugs and "gotchas"
- setting up and enforcing standards
- data entry for all the programs (for my part, that means piping specs, data files for piping, steel, electrical programs)
- adjusting the support system to handle differing requirements from various clients
- basic support for supporting programs such as Word and Excel
- evaluating new software and new releases
- planning and executing upgrades and licensing
- knowing the basics of the profession (I need to be part stress engineer, part materials engineer, part piping designer, part civil/structural designer, part IT professional, the list goes on)

... and a bunch of other miscellaneous stuff.  Not a lot of time left over to be learning a dedicated programming language such as C#.  The only reason I have gotten as far as I have is with previous programming experience with C, Java, and machine code (after which LISP is a breeze).  Trying to justify to management the hours spent on converting all of the existing support code would be a hard row to hoe as well especially with a downturn in the economy and the reluctance to spend money for little realized returns.

The problem as I see it is one of time management and diminishing returns.  As both AutoCAD and programming tools increase in complexity the amount of time required to be proficient at both increases as well.  Eventually a "critical mass" is reached where people can only be proficient at one or the other.  I'm sure we would have no problems finding .NET programmers, but their knowledge of the ins and outs of AutoCAD *and* the industry we are in *and* .NET programming as it applies to AutoCAD?  Highly unlikely - it took us 3-4 months just to find somebody with sufficient AutoCAD experience (not even programming) to back me up.  In fact, I see this as the reason why AutoCAD products are on a slow decline in terms of useability.  The programmers that write the software do not have the time to gain the industry experience of actually using the product, while those that are very familiar with using the product in the chosen industry don't have the time to get proficient at the programming tools used to customize AutoCAD to the nth degree.

I still maintain, again from the standpoint of a CAD administrator rather than a programmer, that for most of the common automation tasks needed by engineering companies LISP is the better tool in terms of time spent developing, deployment, and upkeep.  .NET is better for large, full-service-program type automation where the company is unwilling to spend money on a product developed by a software company or no product is available.

I'm an electrical designer, not a programmer. I'm stuck with quite a few of the tasks you listed as well as putting out production drawings, specifying control panel components, specifying transmitters and gauges as well as PLC and HMI programming for our machines and all of it's auxiliary equipment. With all of that I still had time to start picking up C# and working with it.

Heck, you said you know Java. C# is essentially a better Java.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Glenn R on November 15, 2008, 01:35:46 PM
A good CAD admin, perse, knows the product well, how it's used in their field and AutoLISP. A VERY good CAD admin knows all this, PLUS multiple languages to enable them to choose the best tool for the job/task at hand.

IMO, engineers should NOT be using CAD, as their expertise is in engineering (number crunching if you will), NOT using CAD nor programming. I've been employed by some forward thinking companies as a dedicated 'problem solver' and I use my extensive experience with the software, plus all the programming experience I've gathered in multiple languages to provide the best solution for the project.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Bryco on November 15, 2008, 03:32:39 PM
Do  you  writie anything in lisp at work, Glenn?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: Glenn R on November 15, 2008, 06:14:39 PM
Bryco,

Occasionally, when it's warranted - Lisp is VERY good for the startup stuff.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: sinc on November 17, 2008, 11:36:05 AM
As both AutoCAD and programming tools increase in complexity the amount of time required to be proficient at both increases as well.  Eventually a "critical mass" is reached where people can only be proficient at one or the other.  I'm sure we would have no problems finding .NET programmers, but their knowledge of the ins and outs of AutoCAD *and* the industry we are in *and* .NET programming as it applies to AutoCAD?  Highly unlikely - it took us 3-4 months just to find somebody with sufficient AutoCAD experience (not even programming) to back me up.  In fact, I see this as the reason why AutoCAD products are on a slow decline in terms of useability.  The programmers that write the software do not have the time to gain the industry experience of actually using the product, while those that are very familiar with using the product in the chosen industry don't have the time to get proficient at the programming tools used to customize AutoCAD to the nth degree.

Were you seriously looking?  Or were you looking for someone who could do all this for $50K/year?
Title: Re: Can VBA do Everything that Vlisp can?
Post by: sinc on November 17, 2008, 11:41:07 AM
IMO, engineers should NOT be using CAD, as their expertise is in engineering (number crunching if you will), NOT using CAD nor programming. I've been employed by some forward thinking companies as a dedicated 'problem solver' and I use my extensive experience with the software, plus all the programming experience I've gathered in multiple languages to provide the best solution for the project.

That's the old-school methodology.  These days, it is making less and less sense for engineers to be "number crunchers" that don't know how to use Autocad.  With Revit and Civil 3D, it's becoming more and more of a design tool, where the drafting falls out of the design.  And the software is now reaching the point where it is possible to do a lot of "what if" modeling, and come up with better designs, because it is so fast and easy to try multiple designs.  The thing that doesn't make sense now is for an engineer to try to do a bunch of work outside of Autocad, so that someone else can take a bunch of hand-made drawings and try to create a CAD model out of it.
Title: Re: Can VBA do Everything that Vlisp can?
Post by: mjfarrell on November 17, 2008, 02:56:34 PM
IMO, engineers should NOT be using CAD, as their expertise is in engineering (number crunching if you will), NOT using CAD nor programming. I've been employed by some forward thinking companies as a dedicated 'problem solver' and I use my extensive experience with the software, plus all the programming experience I've gathered in multiple languages to provide the best solution for the project.

That's the old-school methodology.  These days, it is making less and less sense for engineers to be "number crunchers" that don't know how to use Autocad.  With Revit and Civil 3D, it's becoming more and more of a design tool, where the drafting falls out of the design.  And the software is now reaching the point where it is possible to do a lot of "what if" modeling, and come up with better designs, because it is so fast and easy to try multiple designs.  The thing that doesn't make sense now is for an engineer to try to do a bunch of work outside of Autocad, so that someone else can take a bunch of hand-made drawings and try to create a CAD model out of it.

THREADJACK


Here here, if one is still using the OLD design by hand, draft in cad,red line review by hand, redraft in cad, red line back check by hand, revising cad, and red line again methods you already losing more money than one would lose in training those users to use cad irrespective of their age, religion, or ethnic background.


THREADJACK OVER