>It's hard to experiment with a toolbar in Excel because millions of non-computer-geek users
Excel is another of my favorite "Why did they do that?" examples. In my opinion, MS absolutely ruined Excel somewhere in the transition from Office 2003 to 2007. If you were a power user with Excel'03 you felt like a total idiot with Excel'07. And, this wasn't a matter of a few buttons here and there. The thing was almost utterly unusable compared to what you could do with the '03 version. Furthermore, they complicated the usage of VBA modules. If you had a library of VBA work that you used regularly you, all of a sudden, found yourself scratching your head trying to figure out how to do some pretty basic stuff.
I use Excel extensively for automated code generation. Simple examples are the generation of repetitive lookup table code in various languages. Or code to pre-stuff database tables. Or maintaining a complex LUT-driven state machine. I have custom Excel tools that have taken months to develop that do increase productivity in a measurable way. For example, one tool uses Excel to auto-magically write the code (LUT, callbacks, etc.) for a menu system on an embedded device with an LCD display. Before the tool it'd take hours, if not a couple of days, to maintain. After the custom VBA tool it was a matter of minutes.
Anyhow, upon switching to '07 (mostly a forced switch because I needed to migrate to a 64 bit OS for Finite Element Analysis work) I went from light speed to crawling. That, to me, is not an improvement. I am OK with learning new things, you have to be open to it if you want to remain in this game, but sometimes you can't help but scratch your head and try to figure out what the hell they were thinking.
Thankfully that was easily solved with a VM running XP and Excel'03.
I use Excel extensively for automated code generation.
I'm not going to argue if this is a good thing or a bad thing to do, but even you have to agree that this is an extremely rare thing to do, and something that would be more or less impossible for Microsoft to anticipate you doing.
Of course. This was just one illustration of Excel as an augmentation tool. There are probably thousands of such special applications out there, some commercial, some not, that used Excel this way.
The greater point, perhaps, is that making things prettier at the expense of raw functionality isn't always the best idea.
For the record, on first inspection I like the outer appearance of VS 2011. I like the pictographic icons and clean uncluttered appearance. I hope that this effort did not come at the expense of function elsewhere. We'll upgrade when it comes out of beta and see.
I will argue, as I don't know who the submitter is, or even what this site is. HackerNews I think? I just got here via a Twitter post. So I have nothing to lose.
If you're using Excel for automated code generation, YOU'RE DOING IT WRONG
Surely there are better tools out there for the task.
That's really funny partner. Using Excel for generating code fragments that can be cut and pasted into your compiler is powerful and fast. Nothing wrong with it. But, go ahead and don't. I love compete with others doing thing less efficiently. Makes me smile.
May I humbly suggest that you are mixing your data up with your code? Could you not just put the data in an external Excel file (or *.txt file, whatever) and read that in when you run your code?
This has a number of advantages:
- you don't need to change your code every time the data changes.
- you can version the data and the code seperately within your source control management system.
- you don't need to write any VBA. (always a winner, that one)
- current developers will be able to understand and change the code without being forced to use the macro you developed, or have it explained to them.
- future developers will be able to understand where all the code came from, and be able to effectively understand and change it.
- you will be less affected by changes to future versions of Excel.
He mentioned generating code for an embedded system. In that particular situation what you suggest may not be possible.
On the other hand what would be possible (and I've done this a few times before) is write a program or script (I like writing it in Python) that takes the .xls/.csv/.txt/.json file (which is pure data, can be edited in many programs etc) and generates the C/C++/whatever code from that. Basically the best of both worlds.
I couldn't agree more. '07 excel is a major change from '03. I know that they are trying more of a shotgun approach to reach deeper into business but I'm not sure if MS considered how they have alienated the power users. '10 is much more SharePoint focused which I love but SharePoint out of the box is very very limited.
Dunno about 03 but I recently installed Office XP (2002) almost without pb on a Windows 7 64bits. The only pb was with the companion help API that doesn't exist anymore on Vista/7 but is downloadable as a hotfix from Microsoft.
So I'm perplex about the need of a VM to run Excel 03 and won't debate about the use of it to generate code as anyone have different habits for his workflow.
Excel is another of my favorite "Why did they do that?" examples. In my opinion, MS absolutely ruined Excel somewhere in the transition from Office 2003 to 2007. If you were a power user with Excel'03 you felt like a total idiot with Excel'07. And, this wasn't a matter of a few buttons here and there. The thing was almost utterly unusable compared to what you could do with the '03 version. Furthermore, they complicated the usage of VBA modules. If you had a library of VBA work that you used regularly you, all of a sudden, found yourself scratching your head trying to figure out how to do some pretty basic stuff.
I use Excel extensively for automated code generation. Simple examples are the generation of repetitive lookup table code in various languages. Or code to pre-stuff database tables. Or maintaining a complex LUT-driven state machine. I have custom Excel tools that have taken months to develop that do increase productivity in a measurable way. For example, one tool uses Excel to auto-magically write the code (LUT, callbacks, etc.) for a menu system on an embedded device with an LCD display. Before the tool it'd take hours, if not a couple of days, to maintain. After the custom VBA tool it was a matter of minutes.
Anyhow, upon switching to '07 (mostly a forced switch because I needed to migrate to a 64 bit OS for Finite Element Analysis work) I went from light speed to crawling. That, to me, is not an improvement. I am OK with learning new things, you have to be open to it if you want to remain in this game, but sometimes you can't help but scratch your head and try to figure out what the hell they were thinking.
Thankfully that was easily solved with a VM running XP and Excel'03.