It's mostly a personal preference, but I've always recommended C# for someone that is new to programming and has no prior experience with VB.
There are several reasons for that.
First, you will find more and better quality source code and examples written in C#, because it is the overwhelming choice of more experienced and professional programmers, most of whom have prior, extensive C++ experience. IOW, people who write code for a living, generally choose C# as their .NET langauge.
The other reason relates to another aspect of learning .NET, which is its object oriented nature. and the fact that .NET is an object-oriented API. Both VB.NET and C# are true object-oriented programming langauges. Taking full advantage of either requires a reasonable understanding of the basic principles and concepts of OOP. VBA and VB6 only 'flirt' with those concepts, and are not true OOP langauges, so a big hurdle in transitioning from either of those languages to any .NET langauge, is learning OOP concepts.
If you're just starting out, IMO, it's far easier to grasp the basic concepts of OOP with C#, as compared to VB.NET. So, if you've never coded in any form of VB, my advice is to go the C# route.
Additionlly, the latest version of C# uses functional programming to a greater extent (Functional programming is where code or functions that contain code, is treated just like other kinds of data). Since LISP is the premere functional programming langauge, if you are coming from a LISP background and are reasonably familiar with LISP's functional programming aspects (e.g, things like the (mapcar) and (foreach) fuctions), you can apply those same concepts in C#:
For example:
(setq mylist '(100 200 300 400))
(setq result (mapcar '(lambda (x) (+ x 1)) mylist))
(print result)
-> (101 201 301 401)
In C#:
List mylist = {100, 200, 300, 400}; // C# 3.0 only.
List result = mylist.ConvertAll(delegate(int x) {return x+1;});
Console.WriteLine(result.ToArray().ToString());
-> {101, 201, 301, 401}
In the above, these are functionally equivalent:
(lambda (x) (+ x 1))
delegate(int x) { return x + 1;}
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
"Bob Quinn" wrote in message news:5806834@discussion.autodesk.com...
Thanks Tony!
What about the vb.net versus c++.net thing?
--
Robert Quinn
President RCM,Inc., Revcam, LLC, Heliforming Technologies
Tel: 586-336-1237
Fax: 586-336-1287
"Tony Tanzillo" wrote in message
news:5806149@discussion.autodesk.com...
For starters, my advice would be to not put too much stock in the AUGI
thread you were pointed you to, because the participants make it clear in
that thread, that they're somewhat misinformed, and its also a known fact
that some of them have little-to-no practical experience with .NET, which
means they are basically guessing and speculating, and are unable to offer a
qualified opinion.
It isn't always a question of what is 'easier'. It's also a question of what
is the best investment in terms of the future.
I fully expect a large number of AutoCADs to be running on 64 bit machines
in the not-too-distant future, mainly because of its ability to address
greater amounts of RAM, and the many benefits that offers to AutoCAD users,
most of whom are pushing their current 32 bit hardware to its limits.
Microsoft has already made it clear that there will be no port of VBA to 64
bit, and if we consider just that one simple fact, I think the choice is a
no-brainer. The 'hack' that Autodesk and others have resorted to in 64 bit
versions of their applications, essentially amonts to running VBA as a
seperate 32-bit process, which means that performance suffers to the extent
that any use of VBA is like dragging around a ball and chain, and completely
unacceptable for most.
If you look in the VBA newsgroup, you will see many who experience the same
set of common problems, and the kind of 'kludges' they are forced to use to
work around them. Some of them are not only ugly, but they also don't work
all of the time, and only tend to create as many or more problems than they
attempt to solve.
For example, .NET lets you use the AutoCAD command line in the exact same
way you can with LISP's (command) function, which for many things,
represents the shortest distance between two points, and a much easier way
to just get something done without all the headaches you have doing the
equvalent in VBA with it's hideous 'SendCommand' kludge-o-rama.
Another important factor is that .NET allows you to use the same ActiveX API
that VBA uses, which means that you can use it from .NET and avoid the more
difficult-to-use managed ObjectARX API until you are comfortable with it.
You can also freely mix both ActiveX and managed APIs in the same code,
which means that you can gradually tap into the managed API in small and
measured ways, and use it to solve problems that ActiveX doesn't offer good
solutions for.
What that means is that with .NET, you have access to the best features and
aspects of each of AutoCAD's APIs, rolled into one seamless environment:
1. The ability to script the command line easily
and synchronously as you can do from LISP.
2. Access to the same ActiveX API that VBA is based on.
3. Access to the much more powerful managed ObjectARX
API for cases where its power is warranted.
Finally, you also have all the power which the .NET framework offers for all
types of development, like much richer user interfaces; database access;
internet and XML development, and you get that without any of the hideous
'baggage' that comparable ActiveX-based applications written in VB or VBA
must tow around with them.
Is the VB.NET language more difficult to learn than VBA? I don't think it
is.
Many people tend to confuse languages and the APIs used with them. In terms
of the language alone, VB.NET was designed to make it easy for VB
programmers to migrate to, and isn't much more difficult to learn.
However, the .NET framework is a very large _API_ that VBA does not have
access to in the first place. And yes, learning to use that API is certainly
something that VBA programmers don't have to contend with. Learning to drive
a Formula 1 race car also takes longer than learning to ride a three-wheeled
tricycle.
As far as VBA goes, I would summarize it thusly:
"No pain, no gain".
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com
