Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Microsoft IT

Microsoft Says VBA Is Here To Stay 116

Posted by kdawson from the thought-we'd-seen-the-back-of-it dept.
Angostura writes "Microsoft's team blog for Microsoft Excel and Excel Services has responded with a denial to the earlier report that Visual Basic for Applications will disappear from Windows Office in 2009. The Slashdot discussion on the report on Tuesday got pretty animated."
This discussion has been archived. No new comments can be posted.

Microsoft Says VBA Is Here To Stay More

Microsoft Says VBA Is Here To Stay

Comments Filter:

  • So Microsoft is at least still a *little* evil (Score:5, Funny)

    by sapone ( 152094 ) on Friday January 18, 2008 @09:27AM (#22092598)
    If they had they rid the world of VBA on top of publishing their binary specs in an Open Source compatible way, their reputation bar might have ended up on the "good guy" side :).

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      And if it's true that VBA is sticking around, then the folks running the Mac BU are liars. Either way, Microsoft can't be trusted.

      • That is actually quite funny!

        InnerWeb

      • Re: (Score:3, Insightful)

        by smittyoneeach ( 243267 ) *
        Not necessarily. If the main VBA users are the PC-based ones, then MS could drop Mac support, retain PC, and the story is "reasonably" clear.
        In any case, with the number of people involved in frobnicating the decision, there really isn't a need to label anyone a liar. Policies are variables, not constants, and get new values assigned to them frequently during business execution.

      • Re: (Score:2)

        by cp.tar ( 871488 )
        Or the Slashdotter who predicted VBA will be "put back", making MS "the good guy", while at the same time screwing over their customers once again.

    • Re:So Microsoft is at least still a *little* evil (Score:5, Informative)

      by kestasjk ( 933987 ) on Friday January 18, 2008 @10:08AM (#22093230) Homepage
      There's no way they were going to release an Office suite without any macro capability, but the blow is that they aren't replacing it with .NET .

      • Re: (Score:3, Insightful)

        by Anonymous Coward
        I work with big banks on the fixed income side, and most traders have some excel spreadsheets with custom macros developed by internal IT. MS has to keep new version backward compatible. There is no way MS will break these spreadsheets, or else they'll piss off plenty of rich people and big companies.
        • I was hoping they'd have some sort of transitional .NET language. Remember that Office 2007 breaks plenty of 2003 macros, so forcing developers to update macros for new versions isn't out of the question by any stretch.

          • Re: (Score:1, Interesting)

            by Schmodus ( 875649 )
            Citation needed here.

            • Re: (Score:2)

              by Imsdal ( 930595 )
              I should probably have chosen a nick of ExcelFanBoyOne, as it seems like every other post I make here is about how great Excel is, but GP is actually right. Excel 2007 macros have a huge bunch of compatibility issues.

              The ones I have run into in particular are regarding charts. Stuff like changing background colours or patterns etc. Also, the macro recorder in 2K7 doesn't record a lot of things that were recorded earlier. Again, charts are a major problem. Start recording a macro, then drop the background

              • I have had issues with macro's (2003 vs 2007). I just copied and paste macro code from 2003 editor to the 2007 editor and it still worked. Recording the macro the same as I did in 2003 didn't work. Mine was a simple one. I have a shortcut key to quickly print 1 letter on letterhead paper and 2 on blank.

        • Re: (Score:3, Interesting)

          by rtb61 ( 674572 )
          Now that is an utter and total lie. M$ will with out any qualms or favour break every macro in every spreadsheet in they believe it will make them money and they have already done it once. I likeed the simple little macro language that cam with every spreadsheet program, sure there were some differences but it basically followed the same logic as the spreadsheet program itself.

          Then the asshats at M$ wanted to make more money selling software licences for Bills baby, VBA, so fuck all the customers using sp

    • "Publishing their binary specs in an Open Source compatible way"? Surely you're not referring to OOXML?

  • that was a close one. (Score:5, Insightful)

    by kellyb9 ( 954229 ) on Friday January 18, 2008 @09:30AM (#22092640)
    Oh thank god... don't know what I'd do without that!

  • ISOfication of OOXML vs VBA (Score:5, Interesting)

    by jkrise ( 535370 ) on Friday January 18, 2008 @09:32AM (#22092678) Journal
    If OOXML is to become an ISO standard fully implemented in Office 2009; VBA and binary blobs will have to be deprecated and removed from the feature list.

    Else, after ISO approval is sought and obtained, MS might claim it is deprecated but still provide support in Office..... either way, confused times ahead for the Office cash cow, methinks.

    • Re:ISOfication of OOXML vs VBA (Score:5, Insightful)

      by morgan_greywolf ( 835522 ) on Friday January 18, 2008 @09:46AM (#22092884) Homepage Journal
      Agreed. VBA obviously can't be part of the ISO-ificated OOXML. VBA is probably going to be considered a 'legacy' feature, with recommendations that customers do new development on VSTA/VSTO.

      If history is any judge, many VBA apps will one day not work in future versions of Office anyhow. MSFT does plenty to break compatibility between releases. In fact, some VBA apps developed for Office 97 won't work on Office 2000 or later.

      • Re:ISOfication of OOXML vs VBA (Score:4, Insightful)

        by ozmanjusri ( 601766 ) <.moc.liamtoh. .ta. .bob_eissua.> on Friday January 18, 2008 @10:25AM (#22093486) Journal
        If history is any judge, many VBA apps will one day not work in future versions of Office anyhow.

        Actually, that should happen sooner rather than later, so this announcement is a retrograde step.

        DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now. VBA is heavily tied into that same flawed architecture.

        Microsoft has tried to address the exposures by disabling macros by default in Office, but the control they provide isn't fine-grained enough to do more than pass the buck to the customers who have to enable the lower security levels to get their documents working.

        They do have an answer in .NET, but until Office is re-written for that platform, and until there's some sort of converter for the massive collection of existing VBA to VBA.NET, they're stuck with the risky and clunky security fix.

        • Re: (Score:2)

          by samkass ( 174571 )
          DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now.

          And in a much more resource-constrained environment. There were definitely models that worked much better, such as CORBA, SOM, etc., but doing things right consumes a lot more resources, so tends to be less performant. It's only when we got gobs of extra computing power, bandwidth, etc., that we're able to make interfaces that are both secure and performant. I suspect i

        • DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now.

          How is this insightful? DDE has been deprecated for ages, and has no connection whatsoever with COM, and only in part a common goal with OLE. COM and OLE are also very different things, though the latter certainly uses the former (similar to how, say, JSP relies on Java). There is nothing "fundamentally flawed" about COM, most certainly not anything that has to do with se

        • Re: (Score:2)

          by sco08y ( 615665 )
          Microsoft has tried to address the exposures by disabling macros by default in Office, but the control they provide isn't fine-grained enough to do more than pass the buck to the customers who have to enable the lower security levels to get their documents working.

          I have a few macro-enabled Office documents that I signed with a CAC. It's actually pretty easy to do, and any time I save an update to the macros it automatically prompts me for my CAC. It works pretty nicely.

      • Re: (Score:3, Informative)

        by MightyYar ( 622222 )
        I've got no problem with them revamping VBA and breaking things here and there to make everything more robust. I'd much rather fix existing macros than start from scratch.

        We're smarter now and we typically make web apps, but when Excel 5.0 (IIRC) came out with VBA, it was like geek crack. We made so many VBA macros that it seems like that was all I did for a few years. Now, practically our whole measurement lab relies on VBA in some way or another. It would be quite a bit of work to re-write all of those li

      • Re: (Score:2)

        by Dan667 ( 564390 )
        All of my perl scripts still work. I build a bunch of vba crap and then they broke with new office versions so I built the same functionality with perl (Excel::spreadsheets) and you know what, they still work. Yea for perl!
    • Good freakin' point. An ISO standard cannot implement OS specific code.
    • VBA is very nice and helps implement little features that come in handy, especially in Excel.

      I don't think there is any reason VBA cannot be part of the standard, as long as it itself is standardized. There is no reason that this tool should be removed because of dumb users. The default setting in office is to not allow macros and if you want to use them you have to turn them on, I'm perfectly fine with that.
    • Can someone more familiar with theses document formats please clarify:

      Surely the only sensible place to implement a macro runtime is in the application itself, and just use a meta-object to store the code in the doc itself...? Wouldn't it make more sense for the doc to just have a standardidsed API that any macro-enabled application that supported the format could interact with?

      Apologies if this is already what it does, but saying "removing support for VBA from OOXML" seems to suggest that OOXML needs to ha

  • Of course,MS is catering to their real customers (Score:5, Interesting)

    by Coopjust ( 872796 ) on Friday January 18, 2008 @09:34AM (#22092704)
    And despite the security problems that have plagued users for years due to VBA viruses, Microsoft won't remove VBA from Office.

    Interestingly enough:...

    While it's true that VBA isn't supported in the latest version of Office for the Mac and the VBA licensing program did close to new customers last year, we have no plans to remove VBA from future versions of Office for Windows


    Looks like MS may be crippling the Mac version to stop enterprises from moving on from Windows.

  • That's not the problem (Score:4, Insightful)

    by Apocalypse111 ( 597674 ) on Friday January 18, 2008 @09:39AM (#22092776) Journal
    Customers don't want VBA to go away.

    They want the damn ribbon to go away!

    • Re: (Score:3, Informative)

      by ChefInnocent ( 667809 )
      I don't know why you were modded 'Troll'. I think your statements are accurate. There are way too many lines of VB code written for businesses to want it to go away. If they had to re-write those lines (no matter what new language will be, or what the quality of the VB is), they would more likely abandon the need to upgrade. As for the ribbon, I haven't seen it, but that might be because my company didn't think it was necessary to upgrade to the current version of Office.

      Whether we like it or not VB is

    • Re: (Score:2)

      by Tacvek ( 948259 )

      Customers don't want VBA to go away.

      They want the damn ribbon to go away!

      Indeed, or at least make the ribbon easy to customize, like the toolbars (and menus) used to be. My understanding is that the system can be customized using .net assemblies, but doing that is difficult even for the few users that know how to do it. It is all but impossible for the average user.

      • I believe there are even third party tools out there that will write the necessary RibbonX for you to get the customizations.

  • VBA for Mac (Score:5, Interesting)

    by christurkel ( 520220 ) on Friday January 18, 2008 @09:40AM (#22092800) Homepage Journal
    VBA for Office Mac was dropped because AppleScript is far more powerful for the task and by dropping VBA you hinder cross platform compatibility. Devious.
    • Devious but now VBA is not cross platform anymore, which makes it even less appealing for people who cater to a mixed audience. Not that I see many cases where passing around documents with embedded scripts is the way to go, but YMMV.

      Unless, maybe, openoffice support of VB/VBA is decent.
    • "by dropping VBA you hinder cross platform compatibility."

      Cross-platform compatibility has never been terribly good anyway. I'm a non-programmer Joe Schmoe user who knocks up Excel macros because it's a convenient platform - everyone in my office has it. When I started I had a hell of a job figuring out why my macros worked in - if memory serves - Office 2000 for Win but not Mac Office 2001. Turned out there were functions that were simply missing from the Mac version, even though it was released later.

      Tha

  • Would have been a mixed blessing (Score:4, Insightful)

    by HangingChad ( 677530 ) on Friday January 18, 2008 @09:41AM (#22092814) Homepage

    I absolutely hate VBA but it's conflicted because I've made so much money untangling some spaghetti coded VBA nightmare cobbled together as a spare time project that became a legacy application no one can live without.

    Hate the language, love the money from fixing it.

    • Re: (Score:2)

      by S.O.B. ( 136083 )
      Now you can make money converting VBA macros to AppleScript for all those Mac users out there.

      And the money train keeps chugging along...

    • Re: (Score:1)

      by DKelley ( 939789 )
      Don't worry, HangingChad, there are *plenty* of .NET "programmers" out there banging out spaghetti code in .NET. You'll have the joy of being paid to fix crap code for a LOOOONG time....
    • I once had an old boss who loved WindowsNT over Netware back in 99. Because it was a piece of crap it would mean a bigger budget for his department and more jobs for IT professionals and larger salaries.

      Not being able to find IT work again when the .com crash happened I empathize with him in disbelief because it makes alot of sense.

      I should have learned more .NET and ASP rather than Java. Thats where more nursin gis needed but it goes agaisnt the ethics of why IT exists in teh first place and the goal of wo

  • Actually, no. Did you RTFA before submitting? (Score:5, Informative)

    by BobMcD ( 601576 ) on Friday January 18, 2008 @09:55AM (#22093006)
    The link that _I_ clicked took me to a blog that said that VBA was no longer supported, and that the licensing program had gone away. To me this means 'dead'. No support and no license means that no reputable vendor is going to nail any new shingles to this product. Any future offerings using VBA are destined to be either snakeoil or shareware.

    Am I missing something here?

    • Re:Actually, no. Did you RTFA before submitting? (Score:4, Insightful)

      by HiredMan ( 5546 ) on Friday January 18, 2008 @10:05AM (#22093162) Journal
      VBA is gone from Office for the Mac and VBA developers is closed. Microsoft is acknowledging that both these "clues" that made people conclude that VBA in Office was going away are true - but they contend that VBA in Office is not going away.

      "The facts you cited are right - but your logical conclusion was wrong. We're Microsoft and we are not bound by logic."

      Basically.

      =tkk

    • Re: (Score:3, Informative)

      by Richard_at_work ( 517087 )
      The entire article is thus -

      Following MacWorld earlier this week, there has been some inaccurate information circulating online regarding VBA support in Office for Windows. While it's true that VBA isn't supported in the latest version of Office for the Mac and the VBA licensing program did close to new customers last year, we have no plans to remove VBA from future versions of Office for Windows. We understand that VBA is a critical capability for large numbers of our customers; accordingly, there is no pl

    • Re: (Score:2)

      by Westley ( 99238 )
      Where exactly did you read that it was no longer supported? The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported".

      The way I read it, the message is "If you're on Windows and depend on VBA, don't worry - you can still upgrade to the latest version of Office (for Windows). That said, we're strongly discouraging future VBA development."

      • Re: (Score:2)

        by BobMcD ( 601576 )

        The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported".
        RIIIIIIGHT. Cause NOBODY owns a Mac. ;)

        (Not on the Mac)+(No new licenses)= Dead

        They won't put a gun to your head, or otherwise force you to remove the documents from your computer, but rest assured that this offering will soon be cruising down 'sunset' strip.

        • Re: (Score:2)

          by Westley ( 99238 )
          Yes, people own Macs. But not *everyone* is running on a Mac, are they?

          There are plenty of places where the impact of VBA not running on a Mac will be zero. The fact that it's not supported on Macs doesn't make it dead at all.

          • Re: (Score:2)

            by BobMcD ( 601576 )
            You are ignoring the second factor. Whether on purpose or by mistake remains to be seen, but the two of them together create context.

            • Re: (Score:2)

              by Westley ( 99238 )
              Okay, the second factor: no new licences.

              It's far from uncommon for a company to stop selling licences for a particular version of software, but to keep supporting it. That certainly discourages green-field development and should encourage migration to an alternative solution over time, but it's not the same as the solution no longer being supported.

              Jon
  • We bashed them when we read that they wante to drop it. let's bash them because they don't. Hell, this is Slashdor, isn't it?
    • Why is this insightful?

      There are no comments bashing Microsoft at all so far, let alone claiming they should retain VBA.

      Pandering to shills may get you mod points here, but let's keep it real, hey?

    • Re: (Score:2)

      by Hatta ( 162192 )
      We bashed them when we read that they wante to drop it. let's bash them because they don't. Hell, this is Slashdor, isn't it?

      No, it's not.
  • VBA Will continue to be supported by future versions of Office for Windows, just not Macs. Also, no more new Licensing. Really, to me, it sounds like Microsoft is about to do something with VBA it doesn't want Mac users to have right after launch.

    Conspiracy theories aside it could just be they are going to keep the support for Legacy systems but don't want to keep up with that junk for mac users, maybe it's harder to implement on the back end?

    • Re: (Score:3, Informative)

      by cnettel ( 836611 )
      VBA relies on COM and parts of the original (up to VB6) VB engine to do its job. The Mac layer was based on a COM implementation on Mac. To continue the licensing scheme, they would have to maintain the complete library and eventually port it to 64-bitness. Just keeping the bits needed for Office can be simpler. At least, they won't have to maintain an external-product quality interface to the host application developers anymore. VBA support in a future Office release might be done through process separatio

  • How about using .Net? (Score:4, Insightful)

    by mallardtheduck ( 760315 ) <stuartbrockman@ h o t m a i l .com> on Friday January 18, 2008 @10:09AM (#22093246)
    What I would like to see would be a .net based macro system in Office. Something where we could write macros in VB, C#, Python, or any other CLR language.

    Since .Net has built-in support for different trust levels, code signing, etc., security should be more manageable.

    Most of the work is in fact already done. The Microsoft.Office.* hierarchy already exists in .Net, all that is really needed is a way to embed .Net code in MS Office documents.

    • Re: (Score:3, Interesting)

      by Shados ( 741919 )
      It won't be long... I mean, SSIS's script components already use VB.NET (and in the next version can use more languages), so the scaffold is already there.

    • Re:How about using .Net? (Score:4, Informative)

      by andy9701 ( 112808 ) on Friday January 18, 2008 @12:17PM (#22095686) Homepage Journal
      Isn't that what Visual Studio Tools for Office [microsoft.com] does? I've never really looked into it much, but my understanding was that it was a .NET replacement for writing Office apps with VBA.
    • I don't see why they wouldn't just bundle Visual Studio Tools for Office (VSTO) runtime within Office 2009 and provide the opportunity to use that or OOXML. I think I would have more confidence in a VB.NET macro written by someone who doesn't have a clue about object-oriented development, rather than hang on to insecure and deprecated technology. Careful what you say about writing the code in any CLR language. I doubt that anyone would like to see a macro written in a .NET rendition of COBOL or Fortran. LI
  • Once there was a language called VBA,
    Microsoft said it was here to stay,
    First they denied it, the community despised it, we can only home its deprecated.
    • There once was a poet named Banner
      Who composed in a god-awful manner
      With hardly a rhyme
      Or awareness of time
      He'd do well with some Lear and a scanner!

  • Still... (Score:3, Insightful)

    by Nom du Keyboard ( 633989 ) on Friday January 18, 2008 @10:46AM (#22093836)
    Still, even if they keep in in Windows Office, there's no question that it's gone in Mac Office 2008, and that's a huge monkey wrench in mixed business environments. While I'm sure that the Microsoft "solution" is to just have you dual-boot into Vista when you need to run VBA on your Mac, this seems to clearly be an attack on Apple's recent success, and could be a deal-breaker in a significant number of environments.

    Or Mac users could refuse en masse to "upgrade" to this "downgrade".

  • VBA sucks anyways. And OS X users get AppleScript which is far more efficient than that awful mess in Office.

    • Re: (Score:3, Insightful)

      by thePowerOfGrayskull ( 905905 )
      ...which is great until they want to share a document w/ macros with someone on Windows...

      • Yes, that is a limitation of having people using Windows on the network...

        ...all the more reason to wipe Windows off it and install Fedora or Ubuntu...

        • Or mail a document to someone at another company... I mean, I agree, it would be great to wipe out Windows and Office universally... but until that happens, we really are more or less stuck with the need to have interoperable macros in a business environment.

  • Boggled (Score:5, Insightful)

    by samael ( 12612 ) * <Andrew@Ducker.org.uk> on Friday January 18, 2008 @11:04AM (#22094198) Homepage
    Has anyone actually read the original explanation for why Office 2008 isn't getting VBA?

    http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/ [schwieb.com]

    Which makes it very clear that there are good technological reasons for dropping it. Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

    I mean, sure, some people at MS may be happy about it vanishing, but it doesn't sound like a conspiracy to me...
    • Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

      At one time in the past, Microsoft considered it worthwhile to port VBA from Intel and Win32 to PowerPC and the Classic Mac Toolbox.

      Today, it's too much effort to either 1) update the existing VBA engine or 2. Replicate the previous clean-sheet effort. Despite the fact that the Mac is growing in market share, and Office sales are very healthy [microsoft-watch.com]       --something that could hardly be said back in the l
      • What if, hypothetically, they are not removing VBA from Windows Office but are deprecating it? Let's follow this idea along. This means that VBA scripting is no longer encouraged on any platform and has a limited lifetime -- how limited? More limited than it was for the original port, anyway.

        Further, Office sales being healthy anyway seems like a good reason (not good TECHNICALLY, but good in business terms without being morally questionable) to me that they don't feel they need to port VBA this time.

    • Re: (Score:2, Insightful)

      by SpaceHamster ( 253491 )

      Which makes it very clear that there are good technological reasons for dropping it.

      Horseshit. His post says, at great length, that they didn't want to write a whole new jitter for the mac-intel platform. Fine, sounds tough. Wouldn't interpreting the VBA opcodes be worlds easier (and more future-proof)? Or just running the good ole legacy vba engine under a mac-ppc emulator?

      The real problem is that the company has lost its consumer market lock-in and is desperate to staunch Apple uptake in the enterprise, and removing VBA support is as close to a guaranteed deal breaker as they'll ever ge

      • Re: (Score:2)

        by treeves ( 963993 )
        I'd vote for this being the right answer but I didn't see the evidence that enterprise is switching to Apple in the first place.
  • It might take a few years, but I believe VBA is on it's way out. It's just Mac developers tend to jump the gun a few years early. (Dropping serial ports for only USB, dropping the floppy drives, dropping the cdrom bay...)

    If VBA is actually here to stay, I say the telltale sign will be if VBA support is included in the NEXT version of Mac Office X. That is called backtracking.

  • My thoughts in lyrical form (Score:3, Funny)

    by Philotechnia ( 1131943 ) on Friday January 18, 2008 @11:29AM (#22094720)
    Sung to the tune of "Chocolate Rain" by Tay Zonday
    http://www.youtube.com/watch?v=EwTZ2xpQwpA [youtube.com]
    (If you don't know, now you know)


    VBA
    So many people writing code in vain
    VBA
    Debugging apps is really quite a pain

    VBA
    Microsoft says it will not support
    VBA
    To C#, functionality we'll port

    VBA
    No rhyme or reason to deploy this mess
    VBA
    A seasoned coder really could care less

    VBA
    Slashdot will flame Microsoft either way
    VBA
    Now I'm confused why it is here to stay

  • VBScript is the core language of VBA and was the only extant language omitted with the release of .NET. Microsoft's language development groups didn't want to support the language - classic VB and VBA were held to be hacks. So it was proposed that VB/VBA be killed.

    In a most unusual display of synchronicity, Microsoft's marketing group also wanted VBScript killed because:

    • it was a "free language" - VBScript & ASP enabled web development in Notepad - selling Visual Studio development tools was next to
    • Is it not possible to replace VBScript with JScript?

    • Today .NET is on life-support: half a decade after the release of .NET there remain more .ASP pages on the WWW than .ASPX.

      Source? I see plenty of .aspx pages daily, and only occasionally stumble onto a plain .asp.

      On a side note, have you watched the number of .NET vacancies posted in the last few years? It's not exactly falling, you know. Quite the opposite. For new product lines being started today, .NET/WinForms is essentially a default choice for a Win32 GUI application, and one of the major options f

  • ...then why was it just cut out of Microsoft Office 2008 for Mac? If we Mac users are supposed to use Applescript instead of VBA, then where are the Microsoft supplied tools to convert VBA to Applescript? Does Microsoft not care about their customers enough to ensure compatibility between their most recent Office release?

    • Re: (Score:2)

      by sherriw ( 794536 )
      If you aren't running your MS sofware on an MS operating system, then you aren't a real customer. Heh.
  • This is exciting news! Wait, the only VBA I use plays my copy of Final Fantasy Tactics Advance, nevermind.
  • VBA in Excel case is a major advantage Excel has over most competitors. For many engineers capability to write custom programs using popular programming language within the spreadsheet makes Excel the spreadsheet of choice that has no viable competition. This drives rest of the company and cooperating suppliers into the MS Office as a standard. Dropping VBA would be in case of Excel poor decision. Such spreadsheet would lose support it has between technical professionals today. On the other hand I haven't s

  • VBA Went Too Far (Score:2, Insightful)

    by cjb110 ( 200521 )
    Personally I think VBA went too far, it wasn't a simple macro language.

    Which meant it was ripe for abuse and overuse. Too many companies have important, business critical functions/logic entombed in Excel 'macros', or Access 'applications'.

    If I've understood MS's intentions, they want all office programming to be done within .net, which is fine. But I think they should then 'freely' distribute an Office specific version of say C# Express. I can't see many customers being happy if they forced to also buy

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close