331–340 of 435 posts
Earlier quoted context omitted.
Maybe I did not appreciate it properly, but I remember using Lotus Notes at my work a few years ago, and I can remember it being the most awful piece of software I have ever used. Admittingly I am not a specialist, more an employee trying to use it to do my job.
It was pretty awesome for enterprise software in the mid-90s, but the world caught up with it soon after.
In the mid-90's, I thought I was helping by bringing Notes in to the company I worked at, and people seemed to agree. A ticket tracking database we set up seemed to help. Many years later, after I left, I saw a presentation where Notes was cast as the problem, with a website proposed as the solution.
Earlier quoted context omitted.
1,048,576 rows to be precise. ;) Though you'll run into performance issues in more complex spreadsheets once you get into the 100,000 row area, or even 10,000 or so. Then you'll see power user departments switch to the more opaque but more performant Access.
They switch to Access until they hit the data size limit of 2GB. Then they come back to IT who has to deal with the mess that you get when you allow domain experts to build databases.
When faced with a decision b/w using a RAD tool to create something outside of IT, or spending $500,000 and waiting 6 months so real devs can deliver something Finance needed yesterday, that may not be needed tomorrow, the choice is an easy one.
Your generalization isn't entirely unfair; IT is often called on to fix a mess, but some Access solutions are built by people who understand database design/normalization and can put together a easily-maintainable application that never hits storage limits or requires upgrading to a SQL Server-managed back-end.
Corporate IT never lays eyes on many Access projects that aren't crap.
Earlier quoted context omitted.
The issue isn't that you can't program in excel the issue is that excel lacks many of the safeguards that have been built around programming in the last few years. Version control for excel is terrible at best. Code review is basically non-existent and how could it be when logic is split over several cells and variables are named $A17 or B23. I think the win with excel is its super simple interface, that said there i…
> variables are named $A17 or B23. Excel lets you name tables, cell ranges, or individual cells. I have seen spreadsheets put together by people who take the time to do this, and they are remarkably readable!
Some HN comments here: https://news.ycombinator.com/item?id=12448545
I would argue that the most commonly used programming language is Excel. But few of the people using it realize they're programming. It's a brilliant reactive data programming model that makes intuitive sense to non-technical users. They feel empowered to use it to solve problems right now with a computer. They experiment with it, try things, Google how to do more things- just like any programmer does. And they feel…
Anytime another programmer asks me what language they should learn I tell them Excel and they think I'm joking. Besides being a quick and dirty way to solve a variety of problems it helps you speak in the language of your users (if you work in B2B)
Earlier quoted context omitted.
I personally think that a lot of notoriety from Perl stemmed from insane overuse of regular expressions. I'm not talking simple and concise expressions doing ordinary useful things, but rather insanely long and intricate ones which one had to be at a god-expert-level on regex just to attempt to understand. These kinds of expressions are what ultimately caused the derisive terming of Perl as "line noise". It was reall…
> I personally think that a lot of notoriety from Perl stemmed from insane overuse of regular expressions. The problem was that Perl's performance on builtins(sorting and regular expressions in particular) was stunningly good while its performance on anything else was stunningly bad. The idea that you would Decorate-Sort-Undecorate an enormous array because the overhead of passing a function to sort() was so much slo…
The key, as you mentioned, is to use builtins, or more generally to use canonical expressions. There's always more than one way to write an expression, but Perl definitely has opinions about the correct way(s), and the Perl compiler does pattern-matching against the code to recognize many of the canonical expressions. They then get compiled to higher-performing IL code. This is why using things like the spaceship operator, , will run much faster than equivalent verbose comparison code.
This is over-simplified, but I always thought about it this way: the Perl compiler generates "assembly code" for the "Perl CPU" to run. It can generate verbose assembly code using lots of low-level assembly commands, but it can also recognize commonly-used expressions and compile them to a single high-level assembly command, which can then run in a single "CPU cycle" instead of stepping through verbose code. Therefore, it was always worthwhile to learn how to write the commonly-used expressions in the common way, so that the compiler can recognize and optimize them.
I don't know if other languages have this kind of optimization. JIT compiling, as I understand it, does a quick and rough compile without optimizing on the first pass in order to start execution quickly, and then recompiles with more optimization on code blocks that are consuming a lot of runtime. I don't think any of the JIT compilers look for common expressions and apply pre-determined, hand-coded optimized function calls to them.
Earlier quoted context omitted.
> my career in business software has still mostly been about converting spreadsheets into more "proper" applications. Still true for many people in 2017. @patio11 probably said it best: > Every spreadsheet shared in a business is an angel announcing another SaaS app still needs to be built. https://twitter.com/patio11/status/655674551615942657 FWIW we ended up in business software after one of our open source librari…
True but there is a threshold. If the problem is small enough, you can't beat an Excel spreadsheet's flexibility and low startup cost. Having worked with a number of finance teams, the biggest problem is not when Excel is used as an analytics tool but as a financial database. Excel as a source of truth for financial data is truly terrifying. Even financial audits are still often handled with custom data pulls exchang…
I am a programmer and I use csv/Excel as the single-entry financial database for a small healthcare business ($500k revenue). The accountant is fine with it. Filtering and pivot tables are a joy in Excel, and I can still run Python scripts whenever I need (mainly to auto-categorize bank transactions). Most other businesses around here use QuickBooks, which has a proper system of accounts, but then I can't play with the data.
The thing is, I never use Excel because the data I work with every day is almost always multidimensional, so I work with xarray[1]. It drives me crazy to see coworkers using Excel for things that it is not suitable for and having crazy solutions like multiple tables per sheet, multiple sheets, multiple files or other hacks to describe another dimension of data.
Earlier quoted context omitted.
I used to be a Lotus Notes specialist, and one interesting thing I noticed is that from the earliest versions it was designed specifically to be a "step up" from a spreadsheet (Lotus of course also made Lotus 1-2-3, which was the original killer-app spreadsheet before Excel took over). Notes still let you see data as rows and columns and had very spreadsheet-like functions, many of which could be transferred directly…
Maybe I did not appreciate it properly, but I remember using Lotus Notes at my work a few years ago, and I can remember it being the most awful piece of software I have ever used. Admittingly I am not a specialist, more an employee trying to use it to do my job.
Many people seem to say the same thing but the only problem I could ever see (in occasional use) was a non-standard UI which non-technical users had trouble grasping. What made it so awful?