Slashdot Mirror
VBA Going Away, Macs Now, PCs Soon
Nom du Keyboard writes "As Microsoft drops support for older Office file formats, it looks like Visual Basic for Applications is also going soon. Mac Office 2008 has dropped VBA in favor of enhanced support for AppleScript, and Office 2009 is scheduled to lose it in favor of Mac incompatible Visual Studio Tools for Applications (VSTA) or Visual Studio Tools for Office (VSTO). This sounds like the Mother of All Backwards and Cross-Platform Incompatibilities — especially since there appears to be no transition period where both the old and new scripting languages will be simultaneously supported. And as past experience with Visual Studio .NET has shown, upgrade tools are far less than perfect."
As Microsoft drops support for older Office file formats, it looks like Visual Basic for Applications is also going soon
Unless... what if there were only some alternative, open-source project that already supports it on Mac and a similar ongoing Windows/Linux project...
Oh well, I can dream.
W
-------------------
This is my SIG. There are many like it, but this one is mine.
Not a troll.
Java has a scripting extension. No, not Javascript(only), but you can plug various Scripting languages into it, or use Judo which is the real endgame for this problem.
Website Hosting
So Mac you thought you where so funny. Well take this! "PC throws a chair label Cross platform compatability right out a Window".
So what you going to do about Mister I am so much cooler than a PC!.
Mac pick up the phone.
"Hello Open Office org?, Yea this is Mac I have a message from Steve for you. How would you like a big pile of cash and about a hundred programers? Really great they will be right over."
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Let me know when they dump Windows.
More than 60,000 Windows programs won't run on Linux.
This could be good news! We currently have to support MS Office versions of our customizations for Windows, and OOo versions for Linux / Unix. Since Microsoft is forcing us to go back and rewrite the MS Office versions if we upgrade our Windows apps - why not just upgrade to OOo on all platforms, avoid the rewrite cost, and maintain just one set of customizations going forward!
Yes, yes, I see a great "employee suggestion" fattening my wallet this year...
One word.... RAD. Well, ok, it's really three words.
;)
With the PHBs having been promised projects developed in half the time with a smaller team, I can see how VB got it's bloated non-type-safe foot in the door.
And rewriting projects now that are a VB fiasco is making for lots of development jobs
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
I find it amazing how MS is eager to cut the branch it's sitting on these times.
I thought VBA was one of the major reasons for businesses to not switch to alternatives : because they developped in-house lots of VBA code to achieve some tasks, that would tie them to the MS-Office suite.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Screwed over and locked in, with no cross-platform support?
Flippancy aside, Microsoft trots out what they decree is the Next Big Thing about every 4-5 years. In the process, they act like what they used to call the New Hotness is a smelly pile they want to get away from, and drop support for it. Of course, it was a smelly pile in the first place, but it was their smelly pile and they wanted you to buy it and spent a lot of money convincing you it was good.
In the mean time, companies have spent a lot of money supporting and implementing the technologies, buying training, books, etc. Then you re-start the cycle all over again. This is just the next in a long-line of technologies that Microsoft has swept under the rug and moved on. Then a whole new gravy train starts.
Of course, they get the added benefit that you will have even less support and functionality on Mac OS. And, if that is the case, then why would someone by a Mac when they need Office?
I suspect this is 1/3 "technical", 1/3 "strategic", and 1/3 "because we can, bitches".
In the end, who is to stop them? The customers never leave en masse like people have been predicting for as long as I can remember. People adopt the technologies. And, everyone just sucks it up and gets on with their day.
Trotting new, unfinished technologies and dropping older, unfinished technologies and charging for it is Microsoft's bread and butter. It's one big hamster wheel.
Cheers
Lost at C:>. Found at C.
Only less than fully informed because I didn't qualify it.
The rewrite projects I've seen regarding VB to [insert your own language of choice here] seem to be wrapped around a common theme... unsupportable code. While I'm sure there are plenty of enterprise level applications out there written in VB and well-written, the majority of what I've seen takes form level code and spaghetti to a whole new level.
My only guess as to why this happens with such frequency is the environment in the late 90s where there were more jobs than programmers, too many "Sam's Teach Yourself Visual Basic in 21 Hours" books, and a lack of architecural knowledge leading VB teams down the path of no return.
What many companies are left with are legacy apps that nobody wants to support, much less enhance. And with webServices, AJAX and all that is Web 2.0, and a bevy of other technologies that people want to utilize, enhancing kludgy enterprise VB apps with no architecture tends to be more expensive than a proper rewrite.
A funny note: I'm currently contracted to a company that lost all of it's Java/Jade developers when part of the company was sold. In an effort to get the software on supported technology, phase 1 of this project is to reverse engineer the (completely undocumented) application and recreate it in C#. No changes allowed, regardless of best practices. Phase 2 is to completely rewrite it. By reading this could you guess this company is in the oil and gas industry?
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
All the UNIX skills I developed over the last 20 years are still useful. So glad I haven't bothered to spend any time on the MS treadmill. Heck, all the software I wrote over the last 20 years can still be compiled and runs happily on a modern machine that is hundreds of times faster than the SPARCstation 1 I used to run on.
Do you think the PHBs will ever learn that using proprietary systems like Windows may seem cheaper in the short term but in the long run you open your wallet and let them take take take?
"I have the attention span of a strobe lit goldfish, please get to the point quickly!"
I think you are criticizing an organic process for choosing the path of least resistance.
Futile and somewhat incompletely informed spring to mind.
VB is successful because most of the potential applications for computers are not terribly time or resource constrained, most applications are cost-of-development constrained. VB is chosen because it consistently provides the path of least resistance to the first deliverable result, and executives will always bet on the horse that makes it to the first turn - first.
I'm suggesting these executives are not silly - they realize that in the rare case that a software becomes truly important, they will invest in an upgrade - but they avoid the upgrade costs on all the other trial balloons that fill the long spans between truly-imperative-software.
In any cases, engineers who race to the first pole, do so because it keeps them employed, and that ain't so silly either.
Criticizing a platform for being popular is what is silly in my humble opinion.
AIK
Python Power baby !!
MS is not trying to improve their product by removing/upgrading VBA.. They just want to kill Mac. By providing different scripting languages for the two platforms, they are going to eliminate Macs from being used for business. Since most of your customers don't have Macs, you can't use a Mac to write a document with macros in it. So, you have to buy Windows.
echo 'cat sig | sh' > sig
"There is no macro language specified in ODF. Users and developers differ on whether inclusion of a standard scripting language would be desirable." So, I'm afraid not.
However, OOo defines a Universal Developer's Kit that allows development of scripts in any supported language. The one's we have written are in Basic, though our current choice would be Java or Python (we us a lot of both).
My current version of OOo (2.3 in Ubuntu Gutsy) lists Basic, Python, Javascript, and Beanshell as available by default. I'd have to check to verify that these same options are available on 2.3 on Windows and Unix.
Wrong question. ODF is a document format, it defines the form of the data. The data does not determine what tools must be used to process it, except in cases of proprietary formats, where the only tools are the vendor supplied ones. Tying the format closely to the tools meant to process it, to the point of embedding the processing code in the data, is one of the design blunders perpetuated by Microsoft, which gave us such wonderful 'innovations' as Word Macro Viruses.
ODF can in principle be processed by any language that has a decent XML processing library available, or through the API of the document editing tools. The leading API at the moment is OpenOffice.org's, which is open to any language with bindings to its UNO component model, including the language shipping with OpenOffice.org, a version of BASIC resembling VBA.
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
I'm not all corporations, but I've been around a few decades. Here's my 2 cents worth.
All of the OOo code is licensed under the LGPL, and can be freely downloaded, built and customized. So yes, it's possible. The sky's the limit; it's just software. :-) Several factors make it less likely that a corporation would take this approach, however.
One is that such a customization would very likely be deemed a "derivative work" by Legal, in which case if it were distributed (e.g., to suppliers for a given project, or even arguably to contractors working for the corporation), then the source must be made available as well. Non-software corporations tend to be allergic to releasing their source code, in my experience, because their lawyers tend to be very conservative. Some manager somewhere will likely have to bet his career by accepting legal liability for the corporation. Will the risk to his career if Something Bad Happens justify the benefit he perceives?
The issue of support will also likely be raised. What if the customized version breaks - who will "support" it? Yes, yes, we all know the internal team of developers will - assuming they weren't laid off in the last "shareholder value" improvement exercise (a constant risk in corporate America). But IT directors tend to go the other direction, from what I've seen - they want to outsource support (and legal indemnification) for open source software, so it can be treated as if it were proprietary. Proprietary means comfort; a target at which the finger can point if Something Bad Happens. This tendency is likely the foundation of IBM's business case for Symphony, by the way.
Finally, if a support team were to be established in a corporation to produce a custom version of OOo, they would need to have some type of development environment. As much fun as bashing Microsoft may be, Visual Studio and .NET are not technically inferior products. So a corporation is unlikely to consider that an inferior option to, say, Eclipse technology. Sure, it costs a lot more - but it's a small number of licenses. They probably wouldn't hesitate.
But in the end, I suspect a lot of corporations just want to write scripts and such without mucking around in the source code proper. The issues most likely to resonate are: (1) How do you efficiently distribute the customizations? (2) How hard are they to develop and maintain? and (3) Can we use them on all of our platforms as is, or do we have to port or (ack!) redevelop for each platform? The third is where Microsoft's "Windows Everywhere" bias may hurt them with this decision to abandon VBA. (Gee, now I'm sure glad we chose to use Python as the scripting language in our internal applications! :-)
VB was the first language which offered RAD - while at the same time offering the technical breadth and reach of 3rd-party add-ons and access to the Windows API.
.Net - The benefits of natural language, and minimal punctuation will continue to accelerate learning of VB over contrived syntaxes.
The language is absent the jargon-punctuation cruft of c {};
And instead closely follows a language with worldwide recognition.
In some respects c can be compared to latin, or perhaps better to esperanto, which is a contrived language which doesn't resonate with any significant population from birth.
VB, on the other hand, recognizes and embraces the symbolic similarities between branching in code, and branching in languages. It turns out that the advantage of shadowing a natural language are born out in adoption rates and learning curves.
I agree, that VB6 had some issues, limitations etc, but notwithstanding the pain of starting over in
- Again, I am impressed, and you should be as well, that 168-form VB apps could even be written by people who are obviously ill-equipped to produce similar software in any other language. This feat must, at some level, be taken as a complement of the degree to which VB has papered-over a great deal of the complexity of code-writing. I suggest it is a criticism that java, ruby, or perl, hasn't been nearly as effective in bringing systems-design to a broader audience.
AIK
Are you suggesting that Redmond use a tool whose original author is a Google employee?
Have this madman removed.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear