Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was wrong about spreadsheets (2017)

reifyworks.com

Post reply on HN
Print view View original

141–150 of 378 posts

Re: I was wrong about spreadsheets (2017)

#141

Post by tluyben2 »

ChrisCinelli wrote: post #111
tonygrue wrote: post #43

Earlier quoted context omitted.

I'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is. Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water. I know MS has considered it, I'm still pretty su…

Google Sheet can run function and macro written in Javascript. That is what I use.

Although I don't like JS, I use that too, but it's pretty half-baked tooling compared to what Excel has. I would rather like to see just being able to point out some Google Cloud Functions and use those as spreadsheet commands. That would be powerful. Now you can but you have to do plumbing and you cannot reuse libs over sheets unless you make them public (last I checked, I could be wrong on this one but I read posts from as far back as 2011 where 'they are working on it'); you have to copy/paste. Yuck.

I wish someone (MS, ...) would do something, but I work on Linux so no Excel for me. And I do like very large datasets to be in the cloud anyway and not killing my laptop.

There should be more competitors in the space. I know there are a few, but they are not really competitors, just more niche / boutique products that attack a specific case, so you need to go back to Sheets or Excel anyway.

Re: I was wrong about spreadsheets (2017)

#142

Post by davedx »

thom wrote: post #138

I always like these threads where programmers talk about tools like Excel and say they’re fine for small stuff but grow out of hand, as if 90% of codebases built by professional programmers aren’t exactly the same.

But professional programmers (emphasis on professional) are well aware of how codebases can grow out of hand and employ entire categories of theories, strategies and tools to keep their software maintainable, even when under delivery/time pressure. Excel doesn't really have much in this category of theories and tools.

Re: I was wrong about spreadsheets (2017)

#143

Post by davedx »

sbuttgereit wrote: post #27
taneq wrote: post #8

I feel the same way about Access, too. It doesn't matter whether they're "real programming", it matters that they let real people solve real world problems for themselves, who otherwise would have to pay real programmers real money to develop real applications.

I'm in that category of people the regularly have to unwind the web of Excel or deconstruct the Access databases that grow to rival SAP in terms of intricacy... ... I actually agree with the overall premise that these tools do let non-tech types do real work and I think department power user types should have these things. But we must also recognize that these tools are a bit like a black hole, too. Not unlike many a…

This is a good take.

I once build a Rails app that translated a giant Google Sheets document into a web application.

What I found really fascinating was that:

95% of my development time was spent building CRUD, access control, UI that was already more-or-less provided for free in Sheets

5% of my development time was spent writing unit tests and services that implemented the actual logic and formulae in the spreadsheet. Even though this was the tricky, business critical "thinking carefully" part, it was also the least time consuming.

It just goes to show, even compared with Rails, applications like Excel and Sheets give you a LOT for free, out of the box, accessible to everyone.

Re: I was wrong about spreadsheets (2017)

#144

Post by kgwgk »

Xelbair wrote: post #127
halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

I just hate one single thing about Excel - all function names are localized - and in case of my native language - they are horrible and inconsistent.

Even worse, the token used to separate arguments is localized. So you may have to use semicolons instead of commas. But in some places you need to pass a string representation of a formula and there Excel will only understand the non-localized commas. Fun all around!

Re: I was wrong about spreadsheets (2017)

#145

Post by tonygrue »

dolmen wrote: post #79
tonygrue wrote: post #43

Earlier quoted context omitted.

I'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is. Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water. I know MS has considered it, I'm still pretty su…

MS hasn't just considered it. They have done it. This is called Visual Studio Tools for Office. https://en.wikipedia.org/wiki/Visual_Studio_Tools_for_Office...

I've built plugins with VSTO (for Outlook) when I was at MS, but my memory is that it’s dependent on a plugin being distributed and not available for native use embedded into the excel workbooks.

You have to install Visual Studio, compile a plugin, register the plugin, and then from VBA you can call out to that COM interface if you'd like. Even if Excel users could overcome those hurdles, you still break the collaboration flow (i.e. just sharing an excel file).

Looking a little deeper, it looks like they're starting to support Javascript for the newer cross-platform add-in system (and also VSTO), but it looks like you still have to distribute your JS add-in via a web-service as opposed to being fully integrated into Excel and XLSM files.

The bit of just being able to share the XLSM file and users using Excel with no other installs or special network access, is really the make or break for me and non-professional programmer user scenarios I've seen.

Re: I was wrong about spreadsheets (2017)

#147

Post by makach »

Spreadsheets are great!

But some times it is necessary to extract the logic, processes, and behaviors from a spreadsheet into an application that can add necessary stability, traceability and redundancy that an expert concurrent enterprise tool requires from a legal, compliance and technical point of view.

I once was tasked with the unforgiving job to do exactly that.

Re: I was wrong about spreadsheets (2017)

#148

Post by kyberias »

dmitriid wrote: post #104
tsimionescu wrote: post #88

Earlier quoted context omitted.

Sharing Excel sheets is extremely easy - you just mail them, or host them in some online place, like SharePoint if you've bought into the whole MS ecosystem like many companies do. Not sure what your point is there. Versioning is of course more difficult, though Excel does support diffing in principle. I expect though that what most people end up doing is simply keeping track of versions manually, same as they would…

> Sharing Excel sheets is extremely easy - you just mail them Unless the other computer is set to a different locale and your data contains formatted numbers and dates. Then everything breaks.

Are you sure? I'm pretty sure Excel doesn't store numbers or dates in localized format.

Re: I was wrong about spreadsheets (2017)

#149

Post by fzumstein »

davedx wrote: post #142
thom wrote: post #138

I always like these threads where programmers talk about tools like Excel and say they’re fine for small stuff but grow out of hand, as if 90% of codebases built by professional programmers aren’t exactly the same.

But professional programmers (emphasis on professional) are well aware of how codebases can grow out of hand and employ entire categories of theories, strategies and tools to keep their software maintainable, even when under delivery/time pressure. Excel doesn't really have much in this category of theories and tools.

You can actually unit test your Spreadsheets surprisingly easily with Python: https://www.slideshare.net/xlwings/automated-testing-of-exce...

Re: I was wrong about spreadsheets (2017)

#150

Post by tluyben2 »

chaostheory wrote: post #63
Someone1234 wrote: post #20

Earlier quoted context omitted.

Has Access solved the corruption issue that plagued it for tens of years? While you can connect it to a "real" database engine trivially, a common use-case is via a single MDB file that could become damaged. You could damage the MDB a number of ways including: - Leave Access running before shutdown (or power loss) - Intermittent network outage to the file server - Multiple users trying to access the same MDB (or anti…

Access and FileMaker made sense before the advent of open source, specifically Rails. Django, Postgresql, and MySQL. Both products make little sense now.

Yeah, I hear this a lot, but that really does not make a lot of sense. I hear the same for wysiwyg builders, CMS and 'codeless/lowcode' platforms, but they are all alive and kicking despite programmers thinking that it is much more easier to whip up something with Rails/Django.

Those platforms are very far removed from 'the normal user'; you cannot just install ONE (!) installer file and then open a visual drag & drop editor and whip up what you want. In the worst case you have to install several things and some of this need to be configured; you already lost 99% of the business people there.

You forget 'little things' like; they have to know html/css/js as well, or at least know how to add and work with Bootstrap. For business use you need Bootstrap controls; you need to know how to add and integrate them (people are not going to understand what it means to just 'bind to the onclick event') while in the before mentioned packages that is jut drag & drop. Installing new controls is too.

Then, if they got as far that they run into having to securely deploy it somewhere. It is all just too hard.

The web made them less used, but not because of Rails/Django, but because they are, legacy wise, less well fit for the web, but there is still a huge market for them and there are more and more appearing that solve some of these issues for web and definitely quite a substantial group will choose them over hiring 'real coders' to make things quickly. There are plenty of web shops (with big clients) doing their db work with Filemaker (and Filemaker does support web).

Post reply on HN