Hackers' alternatives to spreadsheets?
12 comments
I have been playing with Resolver One http://www.resolversystems.com/ It is a Python Powered Spreadsheet.
If you like perl, and want expression compactness, try the perl data language. To quote
"One can write simple perl expressions to manipulate entire numerical arrays all at once. For example, using PDL the Perl variable $a can hold a 1024x1024 floating point image, it only takes 4MB of memory to store it and expressions like $a=sqrt($a)+2 manipulate the whole image in a few milliseconds. "
http://pdl.perl.org/
"One can write simple perl expressions to manipulate entire numerical arrays all at once. For example, using PDL the Perl variable $a can hold a 1024x1024 floating point image, it only takes 4MB of memory to store it and expressions like $a=sqrt($a)+2 manipulate the whole image in a few milliseconds. "
http://pdl.perl.org/
I've always been annoyed at Excel and always wanted to build something better. I think generally one wants something halfway between a database and a spreadsheet...
There's also SAS, which I like, but took years of brain-twisting to understand. There's always R/splus as well.
Supposedly Tableau is good, but I've never tried it.
There's also SAS, which I like, but took years of brain-twisting to understand. There's always R/splus as well.
Supposedly Tableau is good, but I've never tried it.
You can have my Excel when you pry it from my cold dead hands.
But seriously, like with any programming language, once you get used to the syntax it becomes intuitive. The advantage I see for using spreadsheets is that they are portable. You can send someone an Excel spreadsheet and they can look at it, play with it a little, and send it back.
R or Mathematica can do the calculations (and are more powerful than spreadsheets), but you lose the portability.
For simple stuff that I don't need to share I often use interactive Ruby from the Terminal too.
But seriously, like with any programming language, once you get used to the syntax it becomes intuitive. The advantage I see for using spreadsheets is that they are portable. You can send someone an Excel spreadsheet and they can look at it, play with it a little, and send it back.
R or Mathematica can do the calculations (and are more powerful than spreadsheets), but you lose the portability.
For simple stuff that I don't need to share I often use interactive Ruby from the Terminal too.
Not what you were looking for, but Excel has long had a feature that allows you to assign names to ranges, and it's a big time saver. alternatively, you might like to check out Mathematica.
Yes. A friend pointed it out to me just now :)
Still, it really doesn't seem to make much difference (or maybe, I'm not using Excel (actually OpenOffice) right).
Haven't tried Mathematica yet; though it has sounded interesting for a long time.
Still, it really doesn't seem to make much difference (or maybe, I'm not using Excel (actually OpenOffice) right).
Haven't tried Mathematica yet; though it has sounded interesting for a long time.
awk? I have been messing with this project: http://aql.googlecode.com so that I can quickly do sql-like things with flat files/output where ever it suits me. I need to check in latest code but it is coming along nicely! I believe it fits your description as I built it with the intention of it becoming part of my "unix eco system" in that I can pipe to it etc.
Very very interesting :)
I actually don't use SQL for querying anything (as I said, I'm more looking for seeing how much values deviate from the mean etc), but this looks cool.
One question in relation to your project is why not simply use awk, filter data, pipe to a sqlite db and then query with "real" SQL? I'm curious to know why you choose to write a parser for SQL rather than a lint-thing for CSV..
I actually don't use SQL for querying anything (as I said, I'm more looking for seeing how much values deviate from the mean etc), but this looks cool.
One question in relation to your project is why not simply use awk, filter data, pipe to a sqlite db and then query with "real" SQL? I'm curious to know why you choose to write a parser for SQL rather than a lint-thing for CSV..
Because a lot of what I do when profiling systems involves parsing through, joining and filtering massive (constantly changing) log files. Rather than pumping it into sql why not just leverage the unix command line tools? Basically all aql does is create the awk command for you but with the veneer of sql instead of AWKward (haha) syntax where I refer to fields as numbers etc.
Also writing the sql "parser" was entirely trivial in that I just match keywords then split it into a hash and build the command accordingly. I dug that approach because it means the sql can be in any order, commas are white space and I can easily extend the syntax i.e. "fields, separator, columns (for setting widths)" etc. without much work.
Also writing the sql "parser" was entirely trivial in that I just match keywords then split it into a hash and build the command accordingly. I dug that approach because it means the sql can be in any order, commas are white space and I can easily extend the syntax i.e. "fields, separator, columns (for setting widths)" etc. without much work.
I'm not looking at solutions that require writing scripts: the most I'm doing is juggling experimental data to look for trends anyway.
Really something to Excel what latex is to Word.
Thanks!