Not anytime soon.

Someone at Novell worked on it for a couple of months, but VBA has plenty of IP not covered by the covenant not to sue. And a full implementation requires Windows (since VBA wraps OLE, COM, …)

As for Novell’s OpenOffice fork, it does not take an einstein to figure out why Novell (or should i call them Scovell ?) are doing that. Microsoft wants them to push an exclusive version of OpenOffice, to break the Linux interoperability apart.

I think Jon nailed it. Maybe I’m cynical, but I think there needs to be a 3rd category added:

3. Marketing performance

In the past, Microsoft has two things going for VBA:
(1) Customer lock-in.
(2) They could leverage off of the huge base of VB developers.

With OOo adding VBA support and the bulk of Windows programmers migrating to .NET, neither of these are as true anymore. I don’t know if there’s a big financial incentive for Microsoft to improve the VBA IDE.

Harlan - I really like Your historical reviews especially when it comes to Lotus 1-2-3 and Notes.

Kind regards,
Dennis

Disagree. I run a business on improving performance.

Symphony’s spreadsheet was actually better than 123. It provided all of 123R1’s built-in functions along with many additional functions (all of which were incorporated into 123R2). Symphony also provided multiple movable and resizable (though not overlapping) windows into documents. Character mode versions of 123 never came close to Symphony’s UI capabilities.

Symphony’s database and charting capabilities were fair in the context of the time, but it’s word processor was abominable, and its communications application (read Hyperterminal equivalent) was worse. That said, version 1.1 was the first DOS application to make use of EMS (i.e., EXPANDED rather than Extended) memory cards, even beating out 123.

As for 123, Joel spews more misinformation. 123R2 ran in just 256KB. That didn’t leave much memory for the spreadsheet, but it still provided for spreadsheets comparable to what could be crammed into VisiCalc, which loaded into less than 32KB but still only left 32KB left for spreadsheets on the 64KB machines on which it was originally targetted. Every high-end application through 1985 was hand-crafted in assembler because there was a very hard limit of 640KB for executable code on 8086/8 CPU PCs.

123R3 used extended memory - it WAS directed at AT and other 286 or better PCs. What Lotus gave up on was 3D functionality for 8086/8 PCs, so they made the mistake of marketing both 123R2.2 (2D) and 123R3 (3D) at the same time (both released in Summer 1989, more than 5 years after they released the original Symphony).

What killed Lotus was that they focused too closely on the character mode UI and their look & feel lawsuits. They underestimated the market for Windows, not the market for 286 and 386-based PCs. Their first Windows offering, 123 for Windows 1.0 was atrocious, and they took too long coming out with 123 Release 4 for Windows, which came out about the same time as Excel 5. But bundling into productivity suites killed Lotus. 123 and Freelance held their own against Excel and PowerPoint, but Word kicked the living sh*t out of AmiPro, and Access was a real database application development system while Approach was a toy.

I know he’s trying to make a bigger point, but he thoroughly screwed up the Lotus details. As for his bigger point, it’s a fine explanation of why so many believe mid-1980s software running on mid-1980s hardware performs about as well as mid-2000 software running on mid-2000 hardware. It’s certainly true for all together too many spreadsheets.

Some developer concern for economy in use of system resources would be a refreshing change from current standard development practices.

An extra 1000 Euro over 3 years is the difference between a powerful PC and an OK one. So providing power-users with decent client-side hardware is relatively painless.

Tom

Tom - performance, yes server-wise more hardware is cheaper/easier than s/w. When its many many client pcs that argument loses strength though.
Lotus/MS with their 3-5 year planning horizon are in a different situation than add-on vendors like us. I feel like I have to focus on the now, next week, next month time frame, and not years into the future.
I totally agree on the blank VBA point.

The same applies to the PCs that will be standard in the corporate world that Office 2007 will inherit in 3 to 5 years time; 64bit, dual processor machines with ‘lashings’ of memory will solve a lot of .NET interop/marshalling bottlenecks.

As for Access 2007 Macros. I think MS realised that Access had become a developer focused platform and are trying to refocus it as an end-user tool. End users tend to find the wide open plains of traditional VBA code intimidating but are happy enough to work with within the ‘constrained’ commands of Access Macros (and Excel cell formulae). The professional developer may sing “Don’t fence me in”, but the average user is more of the homesteader type.

Tom