4 ms·

About 15 years ago or so, back when I still did web development gigs and the like (because I hadn't accepted yet that the low level system development I loved w

by anyfoo 4y ago

About 15 years ago or so, back when I still did web development gigs and the like (because I hadn't accepted yet that the low level system development I loved was what I should do for a job, hard to imagine now), I got requests to build complex or not so complex systems, but with the restriction that "it has to be written in Excel". Most of the time, what they really needed was a CRUD app and a database. Needless to say, I never accepted any of them.

Vt71fcAqt7 4y ago
I'm torn on this. I think many saas type services can be a spreadsheet, but excel is only 98% of the way there. Because the main issue with excel is that it is local only and even then cannot be accessed even by other local programs. Hence all the wacky VBA "scripts" that turn into full flegded programs. I wish excel _would_ become a database, that is, a frontend to a postgres instance that could be run locally or on a server. Then we just set the postgresql srting in our app and everything just works: excel is the frontend, special features run in a sane programming language, can be updated seperately ect. Since that will nerver happen, someone needs to make an open source speadsheet that runs on postgres. And yes, it does have to be open source because otherwise nobody will learn it. And it needs at least 80% feature parity with excel.
- eternityforest 4y ago
  The trouble with that is it's a central server which means an IT department to fuss with it. Better would be something like Excel but that works P2P like SyncThing, or even directly using SyncThing itself. I don't think it would actually be too hard as long as you didn't need truly realtime collaboration if you used file sync as your backend, and gave up on the 2D sheet model in favor of a table/records model that lends itself to conflict free operations instead of edits to specific numbered cells.
- accountinhn 4y ago
  Excel can connect to postgres - https://www.youtube.com/watch?v=o2T7xdNZ3Qc https://www.youtube.com/watch?v=o2T7xdNZ3Qc That combined with some thing like Office365 or Dropbox type service and we have what you might be describing.
  - Vt71fcAqt7 4y ago
    I am well aware of ODBC. Critically you cannot edit the database itself, only copy from it. This makes sense so as not to let some sales guy tank an entire company becuase he misspelled a formula. What I mean is a spreadsheet that literally runs on a database. It could even be sqlite, _anything_ that allows two way communication between the slreadsheet and the application. spreadsheet gui <--> database <--> application The spreadsheet does simple data manipulation and acts as a GUI The database can be mysql, postgres, sqlite (even JSON...) The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do. This stack could solve, in my opinion, >50% of all business software. I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.
    - rblatz 4y ago
      Google sheets, maybe excel, can make http post and get requests. It’s trivial to write an api that can read/write to a database on behalf of the spreadsheet.
    - throwaway2037 4y ago
      You wrote: <<Critically you cannot edit the database itself, only copy from it.>> I'm confused. I have written Excel workbooks that write (insert/update/delete) to a database using VBA w/ ODBC.
      - Vt71fcAqt7 4y ago
        That sounds interesting. Would you be willing to post the VBA code?
- WalterBright 4y ago
  Sometimes I'll write a D program when I really should just use sed :-)
uni_rule 4y ago
Isn't that somewhat the usecase of Microsoft Access?
- pmontra 4y ago
  Yes, but from the point of view of an office (lowercase o) worker Access is that thing that, in decreasing order of importance 1) it's not clear what it does 2) it doesn't show them all the data at once all the time 3) it doesn't let them write formulas to work on the data 4) the few that saw Access in action say that they have to call a programmer to do what any Joe can do in Excel So whatever Access is doing Excel does it better and they can't understand why Microsoft developed a crippled version of Excel to manage tables of data. At this point I almost don't understand it myself anymore despite having seen all the years of Access and Excel ;-)
  - indemnity 4y ago
    In a past life the most “fun” I had as a developer on a CAD file processing solution was discovering that engineers loved linking Excel sheets to the CAD files so crucial calculations could be done there. And then having to make this work on Linux servers.
    - pmontra 4y ago
      I had to run a very large accounting Excel file inside a web service about ten years ago. The service was born as manually operated Excel sheet plus interaction by email/phone and they wanted to scale it on the web. I run it on Windows Server and paid somebody to write the Windows service to manage the Excel sheet. I can't remember which language I used for the web service itself. They eventually gave up, commercial problems, not technical ones.

by anyfoo 4y ago

Vt71fcAqt7 4y ago

I'm torn on this. I think many saas type services can be a spreadsheet, but excel is only 98% of the way there. Because the main issue with excel is that it is local only and even then cannot be accessed even by other local programs. Hence all the wacky VBA "scripts" that turn into full flegded programs. I wish excel _would_ become a database, that is, a frontend to a postgres instance that could be run locally or on a server. Then we just set the postgresql srting in our app and everything just works: excel is the frontend, special features run in a sane programming language, can be updated seperately ect. Since that will nerver happen, someone needs to make an open source speadsheet that runs on postgres. And yes, it does have to be open source because otherwise nobody will learn it. And it needs at least 80% feature parity with excel.

eternityforest 4y ago
The trouble with that is it's a central server which means an IT department to fuss with it. Better would be something like Excel but that works P2P like SyncThing, or even directly using SyncThing itself. I don't think it would actually be too hard as long as you didn't need truly realtime collaboration if you used file sync as your backend, and gave up on the 2D sheet model in favor of a table/records model that lends itself to conflict free operations instead of edits to specific numbered cells.
accountinhn 4y ago
Excel can connect to postgres - https://www.youtube.com/watch?v=o2T7xdNZ3Qc https://www.youtube.com/watch?v=o2T7xdNZ3Qc That combined with some thing like Office365 or Dropbox type service and we have what you might be describing.
- Vt71fcAqt7 4y ago
  I am well aware of ODBC. Critically you cannot edit the database itself, only copy from it. This makes sense so as not to let some sales guy tank an entire company becuase he misspelled a formula. What I mean is a spreadsheet that literally runs on a database. It could even be sqlite, _anything_ that allows two way communication between the slreadsheet and the application. spreadsheet gui <--> database <--> application The spreadsheet does simple data manipulation and acts as a GUI The database can be mysql, postgres, sqlite (even JSON...) The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do. This stack could solve, in my opinion, >50% of all business software. I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.
  - rblatz 4y ago
    Google sheets, maybe excel, can make http post and get requests. It’s trivial to write an api that can read/write to a database on behalf of the spreadsheet.
  - throwaway2037 4y ago
    You wrote: <<Critically you cannot edit the database itself, only copy from it.>> I'm confused. I have written Excel workbooks that write (insert/update/delete) to a database using VBA w/ ODBC.
    - Vt71fcAqt7 4y ago
      That sounds interesting. Would you be willing to post the VBA code?
WalterBright 4y ago
Sometimes I'll write a D program when I really should just use sed :-)

uni_rule 4y ago

Isn't that somewhat the usecase of Microsoft Access?

pmontra 4y ago
Yes, but from the point of view of an office (lowercase o) worker Access is that thing that, in decreasing order of importance 1) it's not clear what it does 2) it doesn't show them all the data at once all the time 3) it doesn't let them write formulas to work on the data 4) the few that saw Access in action say that they have to call a programmer to do what any Joe can do in Excel So whatever Access is doing Excel does it better and they can't understand why Microsoft developed a crippled version of Excel to manage tables of data. At this point I almost don't understand it myself anymore despite having seen all the years of Access and Excel ;-)
- indemnity 4y ago
  In a past life the most “fun” I had as a developer on a CAD file processing solution was discovering that engineers loved linking Excel sheets to the CAD files so crucial calculations could be done there. And then having to make this work on Linux servers.
  - pmontra 4y ago
    I had to run a very large accounting Excel file inside a web service about ten years ago. The service was born as manually operated Excel sheet plus interaction by email/phone and they wanted to scale it on the web. I run it on Windows Server and paid somebody to write the Windows service to manage the Excel sheet. I can't remember which language I used for the web service itself. They eventually gave up, commercial problems, not technical ones.