Another reason you should learn to code: Python for Excel
gigaom.com
gigaom.com
Here's a shortlist:
- VBA is case-insensitive. If you don't know the significance of this, you've never taught beginners - VBA hides event binding and namespaces for the user. Major obstacles removed - VBA has full autocomplete - VBA has F1 context-sensitive help - VBA automatically formats and indents your code - VBA is more verbose, and verbosity aids comprehension - VBA finishes most of what you type, so you don't actually have to type much more than in Python - VBA was designed for Excel, and vice versa. The object models fit - There's tons of online resources for using VBA in Excel
And finally, VBA is dead-easy to learn, even for Microsoft-hating open source hackers. You just have to learn to get over yourself.
Actually it depends, if those beginners are supposed to become programmers then you're wrong, if they just want to write one piece of software once in their life and never do it again then maybe you're right.
1. http://www.trollope.org/scheme.html
I find this unlikely; are there any studies that back up your point?
using IronPython to access COM components seems another unnecessary layer. And in my experience what is useful is calling from excel to python and then using vba to manipulate it. (VBA inside excel is fine. Might I suggest that if you are Reading this and thinking "great, anoter way I can program exclusively in Pythin everywhere" you have fallen victim to the yet to be named syndrome and should forcibly use any other language. I still get relapses
But the main selling point for this on the linked page and video is that the resulting code is shorter, and the code is only really shorter because the VBA code declares its variables. The video narrator even says that writing VBA is slower because you have to declare variables before use. I'm sure HN has had plenty of debates about declaring variables in the past, but personally I don't feel it slows me down much more than just thinking of a variable. Anyway, by default you don't have to declare variables in VBA, though it is good practice, especially for larger projects.
Also, that 40-line+ heap of VBA they show being changed into 14 lines of Python is rather unfair. They've written a function for finding the minimum in a range and then loop through a range when they could use worksheet functions (also accessible via VBA) for both. I make it around 12 lines of VBA if you do it that way. Or you could just use 3 worksheet functions and no macros at all.
OK, so these hypothetical beginners may not know the best way to do things in VBA - but they probably aren't going to use lambdas in Python as in the example, either. (Though I do like the possibilities of lambdas for various Excel tasks I've done in the past!)
I'm almost disappointed that so many people think this is an impressive new thing.
No instantiating a COM object, no opening a workbook, no selecting a worksheet, etc.
It lets you write Excel addins in Python in a very straightforward way. Python functions can implement functions, menu items, macros. Supports asynchronous functions in the latest Excel.
See examples here: http://pyxll.com/introduction.html
If you use Excel and want to take it a bit further I would suggest that RExcel is probably a better choice. The R environment has abundant, relevant functionality for those who use Excel frequently.
When I encountered tasks that were tedious in Excel or beyond the abilities of Excel I went searching for a solution. After looking at VBA I eventually tried RExcel. I barely used RExcel as I found it more convenient to work in R itself. Now I use R and a database via ODBC far more than I use Excel. I can see using R as a gateway to other programming languages.
So true. A fairly common path is Excel to VBA to RExcel to R to C++. R is great for exploring and prototyping but then C++ is often used to hard-wire the final R code for speed.
This post talks about switching from (VB to Python). That only happening after they've learned to code.
At that time, I found it most convenient to use Perl for some things, e.g. condensing a "ton" of raw data down into an Excel representation, and VBA for others (manipulating extant worksheets/workbooks).
I also wrote a object-oriented API wrapper in VBA. VBA's fine for doing real work, when you're in the MS Office environment -- or when you have a "plain Jane" Windows machine with no ability/authority to add another toolset.
https://www.google.com/#q=perl+excel
seems to surface both a bunch of links from the beginning of the last decade, and some current stuff. I would be more familiar with the former, so it may be best to form your own opinion on the current state of things. But I'm commenting here, to the effect that there is much information readily available.
P.S. At least of a decade ago, it helped to have a good understanding of Excel and its programmatic interface. One or more Perl modules made it easy to call into this interface, but you still needed to know what was available and what it would do.
Excuse me, but shouldn't we expect hackers to already know that (or at least be knee deep in Thinking in Java or it's like)?