(For English-only speakers: Excel's translation to other languages goes as far as translating function names, thus rendering non-English Excel users' knowledge useless when confronted with an English Excel. E.g., IF(ROUND(A1)=1,B1,C1) in English Excel is JEŻELI(ZAOKR.DO.CAŁK(A1)=1,B1,C1) in Polish Excel -- yes, with all those funky non-ASCII letters.)
That's the reason I always use the English version of Office. But then it's so weird when I go help some colleague and they're using the local version, and I'm suddenly a beginner... A remainder of the old world in today's hyper-globalized world.
That's the reason I always use the English version of everything. What I find most ridiculous is when hotkeys get translated, ex. Ctrl+S is Underline in Spanish (Subrayar)
It never occurred to me that other languages would have different hot-keys. Intuitively it makes sense, but damn I imagine a lot of programs don't do it so it must be a horribly inconsistent experience (I get angry when a program fails to support something like CTRL-W to close windows or CTRL-A for select all or the inconsistency between some using ctrl-shift-Z or ctrl-Y for redo).
I guess that's the advantage to the old Word Perfect approach of function-keys for everything (provided you have one of those nifty overlays that show you all the key-commands).
Not only PT, that happens in most languages where the dot is not the decimal separator. It might have been the case in English as well if they used commas.
This also includes changing argument separators according to the locale. In France, for instance, where commas are used as decimal separators, function arguments must be separated by semicolons. Faithful i18n should take both into account.
Luckily this is a UI thing and the files themself normalize to English. So the project could still be useful for opening Excel files on the web (theoretically).
As far as I know it's still text, but the function names are stored in English and are only localised within the Excel UI.
Fun fact: Some old versions of Excel even had a localised VBA ... using ZeichenF instead of String and other oddities made that a very weird experience.
Every time I read some comment about how people shouldn't use excel for complex calculations and should use relational databases or Python or whatever else, I'll know why it will never happen.
It's really easy to implement the easy parts of spreadsheets, getting the hard parts right is why Excel continues to dominate the space.
There is a good reason why no one has unseated excel: it's easy to build the really easy 80%, but the last 20% is incredibly difficult and time consuming.
Most spreadsheets I've dealt with don't hold relational data. Are there people who use them as such? Sure. But I don't think that's the typical use case.
I would say relational data is the dominant use case for spreadsheets. It's a natural fit given the rows and columns. What other kind of data do you see in spreadsheets? Hierarchical data is not a great fit for spreadsheets.
Spreadsheets are a pretty useful and powerful tool when it comes to doing ad-hoc data analysis, but it's kind of annoying to get data in and out of them from command line tools.
I'm actually working on this, although for various reasons I had to reimplement the formula parser (corner cases are a pain). Screenshot (in progress): http://i.imgur.com/snyBhYH.png
I honestly admire the thought and effort that went into it.
I fear that JavaScript's use of floating point as its single numeric type is likely to create surprising results for the unwary. I have come to the suspicion that the longevity of Excel's dominance is in part due to a sophisticated system for inferring numeric types.
Excel only supports numbers that fit in an IEEE754 double, just like JavaScript.
There is some fancy logic to format numbers, however (including some mess for date codes). http://oss.sheetjs.com/ssf/ is a pretty decent implementation in JavaScript.
Excel is dominant because it runs on Windows and is supplied with MS Office.
Many people would be fine to use other spreadsheet software but why bother going through the bother of researching and downloading and learning that software when your company probably has Excel licences and you've got some entry level training that used Excel?
That dominance has other effects. There is a huge amoun of support (training courses; books; Usenet groups and forums; Magazine articles; other people in the office; etc) for Excel that don't translate immediately to Excel. There are very many third party tools to help you do stuff in Excel if you really need it to. And Excel is probably some people's first introduction to programming. (Which is perhaps a bit scary.)
I speak as someone who loves gnumeric and LibreOffice btw.
> I have come to the suspicion that the longevity of Excel's dominance is in part due to a sophisticated system for inferring numeric types.
Huh? Doesn't Excel just treat everything computationally as doubles and sometimes display them as integers? As far as "sophisticated systems" for dealing with numeric types go, that's fairly weak sauce (and quite easily doable in JavaScript, which already does the first part).
I've been trying to find which js file has the actual meat of the implementation, but didn't manage to find it. function.js seems the biggest candidate, but didn't contain that much. The rest are all minified other JS libraries or bootstrapping. Any hint on where the actual mapping of names to formulas, and implementation of the formulas, is? Thanks.
As for the unimplemented.js formulas, for Gamma you could use the lanczos approximation, it's easy to convert the C code of it which you can find on the internet, to JS.
This reminds me of my college days. At Statistical Computing Facility at UC Berkeley, a grad student and I (I just finished 1st year at the time) built a web-based spreadsheet for tracking students' homework and exam scores. We called it StatGrades. One feature that it had was that you could write javascript for each column for calculation/validation. I looked at the excel help docs and implemented most of the relevant/useful functions, so people could do something like:
for the final grade. We used rhino for javascript and the service was built on jsp/servlet. It also had access controls so different readers/GSIs had access to different students and columns, and students could see their own grades. Everyone hated Blackboard and loved what we built, but unfortunately they couldn't find anyone to maintain it after I graduated (I was the only person working on it shortly after I joined). The service was shutdown a couple years after I left.
I've done some work where I've implemented some stuff in code that was originally done via excel formulas (some traders do things that way). I wrote some python to do symbolic substitution on formulas operating over many columns of data to reduce functions to single line definitions over just the data input, making my job much easier. Any programming language implementing the excel formula functions would make it super easy to automate taking prototyped multi-column excel functions to code.
IRR is one of those things that is remarkably simple to calculate and grok, but is made difficult in the number of horrendous instructions across the web, many of them simply wrong. Until I corrected it the NPV entry on Wikipedia (NPV being a dependency of IRR) sat with incorrect input / result data.
It all makes me think that some in the financial industry think this is some sort of trade secret.
It's somewhat confusing. The structure is MIT licenses but the individual implementations have different licenses (for example, many functions were copied from OpenOffice (which is under Apache2 license)
(For English-only speakers: Excel's translation to other languages goes as far as translating function names, thus rendering non-English Excel users' knowledge useless when confronted with an English Excel. E.g., IF(ROUND(A1)=1,B1,C1) in English Excel is JEŻELI(ZAOKR.DO.CAŁK(A1)=1,B1,C1) in Polish Excel -- yes, with all those funky non-ASCII letters.)