While I understand that this may be off topic to an extent, I am in a bit of a bind and could use some help directing my thought process and research.
I have little programming background aside from:
1) Scripting in a language similar to C
2) Practical use of Python for use in geoprocessing with ArcGIS
This has worked just fine for me so far, but there appears to be a need for me to move into a .NET-based language so that I can start making use of the tools exposed in ArcObjects that ESRI has not yet made available through Python. A decision is being made by my management (with some direction from me) on whether the company should move forward and create a standard for coding in ArcObjects that is aimed at using VB or C#. The main considerations (since I am the only person who will be taking part in this) are future extendability, "safety" of code, and readability. Most of these concerns appear to be things that can be dealt with in the writing of the code as opposed to the language itself, but I don't know enough to be certain.
I've read an article or two comparing C# to VB in terms of .NET, but I would like to ask for further reasoning to consider when deciding on one language over another for a person of my background. What are the most important things to keep in mind when choosing which of the two languages to begin study in for use with ArcObjects?
Sorry if this is too verbose! I simply want my need to be understood.
Thanks.
EDIT: Responses have been great. I went with Dan's answer since it covered all the ground I asked about and went the extra step to point me at IPython.
Answer
VB.NET vs C# really does come down to, mostly, a matter of opinion.
Mine would be strongly in the C# camp, as VB.NET's predecessors (VB & VBA) actively encouraged horrible coding practices ("On Error Resume Next", anyone?) and they live on, in the culture surrounding the language and in gestures towards backwards compatibility.
However, given your specific situation, I would actually float a different idea, specifically IronPython.
It seems a fantastic match for this need:
move into a .NET-based language so that I can start making use of the tools exposed in ArcObjects that ESRI has not yet made available through Python
Cons:
You will be living on an obscure and bleeding edge, especially within the ESRI community but even to some extent in the larger .NET community.
You'll spend some time troubleshooting obscure bugs that come from the impedance mismatch of several layers of abstraction: IronPython is almost exactly like Python; ESRI's .NET API is almost like the underlying COM it's all written in....
Pros:
You get to explore an obscure and bleeding edge, lighting the way for the ESRI and .NET communities to follow in your footsteps!
You can keep working in python (until you hit other limitations) and make the move to other .NET languages a gradual one instead of a sharp transition: you can mix and match the right language for the right need, in the same project.
Having a fast-and-loose scripting language at hand is extremely helpful even after you've moved most development to a more formal/structured language.
Your existing python geoprocessing scripts will be somewhat portable (the GP object is visible in .NET-land too, and IronPython supports IDispatch so there's a chance they might be directly portable with just a few code-line changes).
I really wish more people were doing this. (And if they are; I wish they were publicising it!)
Note: simply for learning the ArcObjects API & regardless of doing production development, IronPython gives you something neither C# nor VBA can: a REPL -- one of the best ways to explore an API by far.
No comments:
Post a Comment