[HN Gopher] The worst of the two worlds: Excel meets Outlook
___________________________________________________________________
The worst of the two worlds: Excel meets Outlook
Author : mooreds
Score : 100 points
Date : 2021-02-13 19:35 UTC (3 hours ago)
(HTM) web link (adepts.of0x.cc)
(TXT) w3m dump (adepts.of0x.cc)
| richx wrote:
| I love VBA, it's so easy and powerful. My first job was being a
| developer/consultant at a big 4 firm, developing a disclosure
| management software with VB6. It even had a ORM to map objects
| from SQL queries. It was lightning fast, Office integration so
| superb. Later it was ported to .NET with a proper client/server
| architecture, still it never reached the speed and simplicity of
| the VB6 version.
| dccoolgai wrote:
| 20 years later it seems I spend months fighting overwrought
| frameworks like Webpack and React to get the equivalent
| productivity I could get in one day with VBA.
| sokoloff wrote:
| My frustration with VBA is that it didn't seem very well
| documented.
|
| If I could record a macro that was "close" and examine it, the
| ecosystem was very productive. Once I wanted to go beyond that,
| it seemed like there was an undocumented chasm to cross.
| Pasorrijer wrote:
| This has gotten a lot better with the internet.
|
| Almost everything in VBA can be found with a simple Google
| search, and Microsoft's technical documentation online has
| gotten very good.
| airstrike wrote:
| VBA is great for many things but it has its flaws.
|
| The biggest problem with it is really that the tooling around
| it is decades old so it hurts your productivity. Maintaining
| VBA code bases is a painful experience, the IDE sucks and the
| language has enough quirks and shortcomings that it forces you
| to take long detours to accomplish what would be very simple
| tasks in more modern languages
|
| The loving part of VBA is its interoperability across the
| Office suite, but there's no reason why that couldn't be done
| in, say, Python
|
| Oh, I almost forgot. VBA classes are absolute misery.
| ddingus wrote:
| This is the part which saves crazy time:
|
| The loving part of VBA is its interoperability across the
| Office suite, but there's no reason why that couldn't be done
| in, say, Python
|
| I agree with you, but Python and pretty much every code
| environment is missing a few things that create a pretty high
| barrier to entry:
|
| For a whole lot of cases, VBA is not even needed. People put
| data into cells, operate on it with formulas in other cells
| that drop output into still other cells which are then used
| to get output.
|
| Input can be almost anything these days.
|
| Formulas have a well defined, easy to understand syntax that
| work across a wide variety of operators. Simple copy / paste
| operations make sense, often with the intended data mapped
| right in. (given people are a little organized)
|
| Output can be almost anything these days too.
|
| And it's live. Make a change, see it happen.
|
| That's real power! People don't have to know much to make it
| all work either.
|
| I have been using Excel to transform business data for years,
| model business and a lot of other things, and as a rapid
| prototype system. I can write code too. Often I do, but the
| more specific and or variable the task is, like a one off
| need to solve yesterday, the more attractive just banging it
| out in Excel becomes.
|
| Should one get super crazy, have one of those outputs from
| Excel be a working program. No joke. A script file is one of
| my favorite outputs. Mash the data up in Excel, and once the
| plan of attack is clear, execute the script and watch it run
| on the real system.
|
| Check this thing out:
|
| https://github.com/tilleul/apple2/tree/master/tools/6502_ass.
| ..
|
| It's a perfectly usable, and I would suggest one of the
| easiest, assemblers I've ever seen! I ran it on my mobile.
| Crazy.
|
| I just used it to knock out a little routine for a retro-game
| project I'm working on and was kind of stunned at how lean,
| accessible, functional this really is.
|
| For Clarity: Replacing VBA with something else costs more
| than the value add at present, and it's because Excel is the
| gateway drug into VBA. By the time people reach for VBA, they
| already are familiar with a lot of it.
| airstrike wrote:
| You misunderstand me. I'm not arguing one should replace
| Excel with Python, I'm merely talking about VBA and the VBE
| ddingus wrote:
| Perhaps we misunderstand one another.
|
| VBA and VBE being replaced with Python would require so
| much work... and there is a crazy amount of code out
| there doing an equally crazy amount of work too.
|
| All the points I put here are why doing that replacement
| work doesn't really add much value.
|
| Which is why VBA is still a thing.
| foepys wrote:
| People are downvoting you but are overlooking the fact that
| it's not always about making things in the newest tech but more
| often than not about making things work. Most software will
| only be seen by industry specific users that don't care that
| the program is React Native and runs on AWS. A simple VBA
| script is sometimes completely sufficient to input the data
| into a spreadsheet. Scott Hanselman called devs doing this
| "Dark Matter Developers" [1].
|
| 32bit VB6 programs are still able to run on modern Windows 10
| machines, even on x64. The hours that would've been lost on
| porting everything to the newest macOS can be spent on new
| features or customer wishes. With the .NET Framework it's even
| possible to seamlessly use VB and .NET in the same program
| which combines old and modern technology. It's officially
| unsupported but it works and even gets bugfixes sometimes.
|
| 1: https://www.hanselman.com/blog/dark-matter-developers-the-
| un...
| bgroat wrote:
| I don't want to say "anti-pattern" because that's not what I
| mean...
|
| But new tech _should_ be the _last_ resort.
|
| If _nothing_ stable, decades old, and well documented can
| solve the problem _then_ reach for hot new-ness
| Retric wrote:
| That's a little far, old doesn't mean good. The bleeding
| edge often gets abandoned, but tech has generally been
| improving over time. IMO, the sweet spot starts when
| something was a fad ~5 years ago and is still reasonably
| popular.
| DaiPlusPlus wrote:
| > IMO, the sweet spot starts when something was a fad ~5
| years ago and is still reasonably popular.
|
| That would mean it's okay to use Angular today, but dev
| trends (and Google's support "policy") would advise
| against that.
| yen223 wrote:
| A good reason to wait a few years is precisely so that we
| have a clearer picture of what strengths and deficiencies
| a piece of tech brings to the table, especially out in
| the real world.
|
| We have a good picture of how Angular and React works in
| production now. We cannot say the same for something like
| Svelte.
| nicoburns wrote:
| > If nothing stable, decades old, and well documented can
| solve the problem then reach for hot new-ness
|
| I think it's a little more nuanced than that. _Usually_ the
| older technology is more stable and better documented. But
| not always. Sometimes the new hotness is the new hotness
| precisely because it 's better in these kind of categories.
| tl wrote:
| It's 100% true, but only in broad strokes. My personal
| ladder is
|
| - paper
|
| - text files / spreadsheets
|
| - desktop apps / local db
|
| - SSR web apps / single database
|
| - SPA or mobile app / cloud storage
|
| The only thing that challenges that is the reality that
| around a decade ago smartphones with tiny screens and no
| filesystem access eclipsed desktop computer, and we're
| still reeling over how much more expensive that makes
| development.
| bgroat wrote:
| You and Retric are right. I'm imagining a checklist of: -
| Stable - Well Documented - Age
|
| In descending order of importance.
|
| When choosing between _any_ technology choose the one
| that is most stable.
|
| If multiple options are on a stable release, choose the
| one that is best documented.
|
| If multiple stable releases have excellent documentation,
| choose whichever is oldest.
|
| I don't think this framework is always (or even often)
| right. But it works for me
| makapuf wrote:
| My checklist would be (I'm eager to know other people
| correct me) suitable (does it some my needs) , stable,
| available (including documentation, live q&a resources
| like stackoverflow, blog posts explaining how- not new
| ones but existing and up to date regarding the version
| available), and simple.
| smitty1e wrote:
| I've never ever tried VBA.Net.
|
| But my private NVBC (NecroVisualBasiCon) repo has some great
| stylings that I tap into at least once a year.
|
| Nevertheless, when are they going to relase Office with
| Python bindings included?
| snomad wrote:
| BTW, they do have a JS API. Been using it a lot recently, fairly
| easy and straightforward
|
| https://docs.microsoft.com/en-us/office/dev/add-ins/develop/...
| smitty1e wrote:
| > First of all we have to say that you can interact with Outlook
| directly from other Microsoft Office apps via VBA using the
| object Outlook.Application.
|
| I haven't seen any corporate deployments that permit jacking
| around directly with Outlook in years.
|
| In particular, the transition to .*x file extensions some years
| ago marked the a heavy lockdown of all my favorite VBA stylings.
|
| To give a customer an .xltm with the capability to import .json
| files with tidy formatting, it was necessary to package
| everything as a .docx and then construct the target on his
| machine.
|
| It's one way to do security, I suppose
| mooreds wrote:
| I thought this was a great examination of unintended consequences
| and a problematic (or unevolved) security model. I am sure it was
| useful to allow Excel to manipulate other Office programs, but in
| a networked world the surprise applications of this are
| dangerous.
|
| I mean, being able to search for "password" in emails from Excel?
| What could go wrong?
| anonymfus wrote:
| As with other Office applications, if internet originated
| document contains VBA code, Excel opens it in read-only mode
| with disabled code execution and displays warning.
|
| _> I am sure it was useful to allow Excel to manipulate other
| Office programs_
|
| Your understanding is backwards. Other Office programs are not
| special, Excel can manipulate absolutely anything as VBA has a
| complete access to full Win32 API, that Outlook.Application is
| a COM object that can be accessed by any other Windows
| application including VBScript and PowerShell in about the same
| way.
| Pasorrijer wrote:
| I think the biggest thing a lot of developers miss with the
| bashing of Excel and VBA is just the simplicity to the end user.
|
| As a consultant, a lot of time the solution has to be able to be
| given to anyone, on computers with no admin rights or
| installation privileges, and just work with no other
| dependencies, installation or special skills required.
|
| Very, very few other methods meet that requirement as well as a
| plain old Excel file.
| tempodox wrote:
| On Error Resume Next
|
| The pinnacle of error handling!
| edoceo wrote:
| When I did VB (loads of it!) my handler was was always labeled
| "hell". On Error Goto Hell
| corry wrote:
| Excel elicits some equivalent of Stages of Grief in technical
| people. First, some version "it's so dumb the world runs this
| way, I'll just port a few of <use case> into a modern CRUD web
| app and people will prefer it since it will reduce errors and be
| in the cloud". Then, "oh hmmm the flexibility Excel brings to the
| user is really hard to replicate in my CRUD app. But I'll try.".
| Then despair - "arrrg if only these dumb users would realize that
| the flexibility and power of Excel lead to lots of problems! Use
| my simple CRUD app, please!!!". Then acceptance (and awe) -
| "Excel is UI, a DB, and business logic all wrapped in 1 thing
| that everyone already knows how to use."
|
| Not saying Excel is perfect. Lots of us have built or are
| building products that do a better job at specific workflows. But
| surely it is one of the best pieces of software we have, and if I
| could only use 1 piece of software forever, it's probably Excel.
| scythe wrote:
| The painful thing about Excel is that it's a self-fulfilling
| prophecy. It's built on extensive UX research that tries to
| support the existing corporate culture and workflow. In so
| being it reinforces that norm, which generally encodes the
| assumption: _the people handling this data don 't understand
| how or want to write code_. It's extremely difficult to build a
| spreadsheet that gives those people as much power as Excel
| does.
|
| This is frustrating for people working in an Excel shop who
| know how to code. Most of them realize their coworkers don't
| want to learn to code. They just wish their skills could be
| useful.
| kqvamxurcagg wrote:
| You hit the nail right on the head there.
| droopyEyelids wrote:
| Feels like he's confusing "Excel" for "spreadsheet program
| with scripting abilities"
| tylerrobinson wrote:
| Can you think of another "spreadsheet program with
| scripting abilities" that is already installed on every
| business computer on the planet?
| ddingus wrote:
| It's more like conflating spreadsheet program with
| scripting abilities into just being Excel.
|
| :D
| RcouF1uZ4gsC wrote:
| I think a lot of the love for Excel by office workers comes
| down to empowerment. Workers like being empowered to solve
| their own problems. Excel does very well. You as a non-
| programmer office worker can quickly make a spreadsheet that
| solves your problem. You can update it on your schedule as your
| problem changes or to explore new possibilities. You give that
| up as soon as you go to a CRUD app. Need to change something,
| put in a a request to IT who might get around to it in a week
| if you are lucky. Wheat would have been a few minute feedback
| loop with Excel is a multi-week slog.
|
| There is no other tool of which I am aware that enables the
| common person to sit down at a computer and make the computer
| do useful real world work work for them in a flexible way than
| Excel. I have used it for budgets, lists, form entry, and
| reports. In addition, it provides a very smooth on ramp into
| programming via the record macro button, which will write the
| VBA function that does what you are doing in the GUI. Most of
| my VBA functions started out as record macro, and then were
| edited to generalize. Truly an amazing piece of software.
| Spooky23 wrote:
| Exactly.
|
| As a service owner of some fairly significant technology
| services, every time one of my colleagues "fixes" some
| business problem with an enterprise IT system, it's
| measurably worse than a well-defined excel driven process.
|
| My favorite was when our travel and expense system moved to
| some Oracle monstrosity, and we literally hired full time
| staff to data enter expenses that were submitted on paper
| because field service folks were spending 5-10 hours a week
| on expense submission.
|
| Another great example is when almost anything is "improved"
| by some sort of quick and dirty interim servicenow task.
| fpoling wrote:
| Well, I observed the opposite effect when a complex Excel
| spreadsheet was replaced by an Access DB that allowed a
| small company to discover that they had extra assets for
| like 200K USD. And the original Excel author realized how
| much more sense the data made once he saw visualization of
| data constraints and relations.
|
| But then IT of bigger companies treats Access as not a real
| DB and often disregards it with the same contempt as Excel.
| techsupporter wrote:
| > Need to change something, put in a a request to IT who
| might get around to it in a week if you are lucky.
|
| If the change happens at all. The IT department might say "we
| don't have the time to do that," or "other users depend on
| the app being like this so we can't change it to be like
| that," or even "why do you need that, your justification
| isn't good enough."
|
| Excel is the non-programmer or non-admin equivalent of "I'll
| just bang that out in [php | python | perl | powershell]."
| We've all done it, we will all _continue_ to do it, and yes
| it will look like an absolute mess...that probably winds up
| powering a Fortune 50 company.
| uncledave wrote:
| A point to note on Excel's empowerment I have discovered. The
| main reason for its ubiquity is because it's mostly already
| there and doesn't require the odious _purchase order process_
| to be navigated and then an odious _IT onboarding process_
| navigated. So fuck that, let 's just cram another turd into
| Excel. That sort of overlaps with your IT request thing but
| at a higher level I think.
| coderintherye wrote:
| Yes, but Google Sheets or shared Excel files in OneDrive.
| Otherwise the magic that is Excel gets lost in various versions
| in people's email attachments. Collaboration + Spreadsheet
| though truly is a versatile tool.
| ddingus wrote:
| This isn't the problem you think it is.
|
| The most common use case is via seed document. People grab
| the seed doc, modify for their specific case, input data, get
| results, stuff into Powerpoint, done, next.
| jjoske wrote:
| Excel is great until you need to fix/extend an app that is now
| integral to all company operations that was made 20 years ago
| by that guy in sales that was good at computers and has long
| left.
| pbronez wrote:
| Sure, but that has nothing to do with Excel. You could say
| the same thing about basically any legacy application on any
| stack.
| corry wrote:
| I just realized something. Riffing on how Excel is UI/DB/biz
| logic in a huge unbounded zone, I think the reason it's so
| popular is that people use it to build PRODUCTS. They don't
| call them products, don't sell them, but a well-built and
| complex spreadsheet is basically a mini app.
|
| What else do we have that's this powerful? And don't say
| Airtable, although they clearly "get it" - it's not about
| files, it's about building mini products.
| saberdancer wrote:
| I knew an accountant that built an accounting software in
| Excel. He had different tables for different invoices, and
| Excel spreadsheet would take that data, do whatever
| accounting needs to be done and prepare all the reports that
| need to be sent to various institutions. If I remember
| correctly, he had a Excel file for each customer he had and
| just used Excel for all.
|
| It wasn't a mini app, it was a complex application used in
| "production" for at least 5-10 years. It's likely it is used
| today as well.
|
| When I saw this, I was blown away.
| walrus01 wrote:
| If you really want to hit your face on a desk, wait until you
| encounter a user who doesn't know how to tabulate or sum
| anything in Excel, and uses it as a big grid-based text editor,
| manually using a desk calculator to sum up columns, or perform
| various other formulas on some selection of cells.
|
| also, prepare for the user to suffer some sort of existential
| crisis or breakdown, possible tantrum after you show them how
| to do these tasks automatically with a simple excel formula.
| enjeyw wrote:
| Building on this, when purist engineers trash Excel, I point
| out that Excel cell formulas are the only case of Functional
| Programming going truly mainstream.
| ggrrhh_ta wrote:
| This is the talk that I first saw that builds on that:
| https://www.youtube.com/watch?v=0yKf8TrLUOw
|
| I found it interesting, fun and great. Still, I would stick
| to using Excel for the personal analysis of data and not as
| the language/tool on which software is developed: data &
| programming logic intermixed, the default way to index cells,
| the difference between normal cells and array cells, and
| tables, etc., the fact that some things are just not possible
| to do fully programmatically without creating your own VB
| functions and therefore asking recipients of what looks like
| data to accept running arbitrary code in their machines, etc.
___________________________________________________________________
(page generated 2021-02-13 23:00 UTC)