In defense of VBA
September 28, 2009 26 Comments
You Maniacs! You blew it up! Ah, damn you! God damn you all to hell!
So the news that ESRI ArcGIS 9.4 will be the last version that includes VBA support has really stirred up some emotions. So sum up a couple comments in that post, “I can’t believe they are dropping VBA, I use it all the time”. Many of us have moved beyond VBA to other languages, but there seems to be a large percentage of ESRI developers that still rely on VBA to customize ArcGIS Desktop. geoGraphika has even written a blog post outlining 7 reasons why ESRI shouldn’t drop VBA.
Now before VBA devs get all worried that they have no time to prepare for the change. Take a look at the time between when ArcGIS 9.3 arrived and when 9.4 will come. ArcGIS 9.3 shipped June 26, 2008 and ArcGIS 9.4 earliest possible release date would be right before the ESRI UC which is July 12, 2010. That is almost 2 years between releases. Lets assume 9.5 takes that long to arrive (let alone the mythical 10.x release) it will be summer 2012. That is a lifetime to get ready to migrate off of VBA. Plus if VBA is mission critical, you can stick on ArcGIS 9.4.
Hey, don’t worry about VBA being depreciated. The future’s so bright, you gotta wear shades.
About James Fee
I also understand that they are beefing up their Python API to be the real successor to VBA.
Yes, was, is and will be the main help initial point of learn to Program with ArcObjects for many users as me.
I think that would be more extent and easy to learn the help for the new users that will be to learn to develop in .NET (VB.NET, CSharp, or C++), because the changes are very confuse.
Thanks for your note.
Francisco J.
They should drop VB.NET too. Do not waste time with it.
Go directly to C#.
Lori: No point in dropping VB.NET. If you support C# you automatically also support VB.NET (or any of the other 40+ .NET languages for that matter). That’s one of the beauties of .NET.
Whether you want to mess with VB or C# is the developers choice. There’s no reason for ESRI to prevent that (never mind that it’s not even possible to prevent).
VBA definitely has a place in development. If nothing else, it is a very quick way to prototype applications, or write a script to do things that Python cannot. I understand that as ESRI migrates more of their code base to .NET, that support of VBA cannot continue. Those objects simply can’t be accessed via VBA.
Because I understand it doesn’t mean I have to like it.
There is a need for VBA, I do understand it. But it’s an excellent point by James here. The at-least 2 years cycle given to people to migrate should be enough to create plans to either create new versions of applications in another supported language. Besides, there are excellent articles out there on how to migrate from VBA to VB.Net to save people a lot of hassle. Also, please remember that Microsoft itself stopped licensing the VBA to third-party applications in 2007, and stated that no further developments of the language, compiler and interpreter will be made (http://msdn.microsoft.com/en-us/isv/bb190538.aspx). I think ESRI is on the right track here trying to phase it out, at a cycle that is reasonable and acceptable by most users.
Is it just me, or is ESRI acting *almost* rationally these days? Can it be they’ve decided it’s time to move off protectionist market-share-grabbing and actually make it easy for their user base to work with the systems they’re locked into?
This is really, you know, kinda *open* of them. Sort of.
I don’t think this has anything to do with rationally.
The fact is they don’t want to support a dead scripting language since Microsoft has stop supporting it.
I really wish they would add some type of C# scripting.
That would make more sense then python which is a totally different language and needs another framework installed.
They could use this already built C# scripting engine.
http://www.codeproject.com/KB/cs/cs-script_for_cp.aspx
atanas enchev said w.r.t. Arc9.3 depreciation that “Win2K shows up in about 9% of my web logs”. I heard a similar % as a rule-of-thumb for old tech. Take another guesstimate # of ArcView licenses in the 6 figures, that still leaves # VBA &/or Win2K in the 5 figures, right? If so, that’s not insignificant…
I hope ESRI can make python work a little better to help smooth the transition. .NET is not the best replacement for VBA. I agree with Horsie, VBA is quick and easy. If you want to write a script to write some field values to a text file, for example, do you really want to have to write an application with an installer just to do it? I am fine making the move to python as long as I dont have use IDLE. I find anymore I dont really like or dislike languages as much as like or dislike IDEs(C excepted). If we can have a nice little IDE, it does not have to be much, intellisense, debugging and straitforward integration then Ill use magik if thats what they want to support(God forbid). Goodbye VBA, SOME of us will miss you.
A couple of UC’s ago I attended a presentation on Advanced Scripting with Python. I am by no means a developer, but I did notice that the guys giving the presentation used ActiveState’s Komodo.
There’s Komodo IDE which is the paid version and there’s Komodo Edit, their free-n-open version. Source for Edit is available at Open Komodo.
YMMV and all that.
Komodo is a clone of Eclipse, geared toward web development. I strongly suggest using Eclipse. I have not used anything else for my Python geoprocessing for ages, and I strongly recommend it to all.
Eclipse is a useful choice as an IDE for many non-Microsoft languages, as you will usually find a plugin to work with your language of choice. If you decide you like the free Eclipse e.g. with Python, then you can use it with other languages too as the skills are transferable. And there are paid-for versions that provide greater support for particular proprietary technologies. If you don’t like it, well, it’s cost you nothing, and may at least help you figure out what you really want from an IDE.
VBA is essentially the dark side – quick, seductive, and (in its domain) pretty powerful for a beginner to just pick up and use.
But it’s a very poor introduction to programming in general – VBA conventions, tight coupling with the MXD, etc. These are not things that should persist, but do in many large scale business applications. I’ve seen nightly batch jobs that open an MXD to execute some ancient VBA, and then close, because no one really wants to mess with it.
Hopefully the improved Python API will fulfill the need for the quick and seductive power, but with looser coupling to the MXD, and using a more modern supported programming language with a rich module environment.
I am pretty much forced into VBA being that my IT department won’t let me install and development environment on my machine.
Honestly though, I’d rather be programming in .net. Much easier for me.
“god” damn you?
why?
Why? It’s the aftermath of armageddon, and Charlton is walking in the wilderness, having left the Apes behind. He comes over a rise and what does he see rising from the sand…the Arm and Crown of the Statue of Liberty…and he says…
I expect Meister Gebühren was thinking how some folks must think this is a pretty big deal – imagine, ESRI abandoning VBA!
Well, it ain’t the end of the world, but I’m betting there’s folks what thinks it might be…
We can whine and complain and mutter all we’d like. ESRI will do what it wants while Jack laughs all the way to the bank:
http://www.forbes.com/lists/2009/54/rich-list-09_Jack-Dangermond_B4V2.html
Funny, i cant seem to find Emile Zola on this list.
I see some difficulties in colleges where VBA is a quick and easy way to introduce students to ArcObjects programming. Frankly, ESRI needs to replace the Getting to Know ArcObjects book with one written for Python or for C# or otherwise for a .NET environment in order to ease the transition. But really, I hope that scrapping VBA means that some of the geoprocessing stuff will finally get adequate documentation or better yet, dream of dreams, that ESRI will move to a fully .NET compliant API and away from COM. 10.0 should really include a whole new .NET API to replace the piecemeal half documented COM API.
The problem is they can’t document the geoprocessing stuff properly because it is such a mess – at least in Python. For example to read the type of an existing field you might return a value of “TEXT”. But you can’t add an field of type “TEXT”, it has to be “STRING”. Same with “INTEGER” versus “LONG”. What this points out is the team that wrote the module that reads a field never coordinated with the team that did the write module. How are you going to document that?
“ESRI needs to replace the Getting to Know ArcObjects book with one written for Python or for C# or otherwise for a .NET environment in order to ease the transition”
+1
Bruce, that may be so, but it’s no excuse. If necessary they should re-write the whole thing. The geoprocessing tools are really the biggest value add of using ESRI, the most powerful tools that are hardest to reproduce are there, but you basically have to just experiment with it or hope you can find someone else who has done what you are trying to do to figure it out.
@Gus: Amen to that.
It has pedagogical purpose to enable students to think critically about the issue of evaluation and rubrics, and therefore to think critically about their own submissions. ,
Pingback: Help with Visual C# for ArcGIS ! « Adventures in GIS