- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
but is it wrong?
Admin
Appalling.
puh-LEEZE.
or whatever the nitwit syntax is of this kiddie-tool.
Admin
But then you're restricted to displaying months in sequential order. The original code doesn't have this limitation.
Admin
Very sensible. Of course you wouldn't, because you'd raise the ire of the I-can-do-that-in-Excel crowd.
Admin
https://twitter.com/RemyPorter/status/752913168624746497
Admin
Shock headline: someone who is not a professional developer writes very slight smelly code.
Honestly if this is the worst code in the application, this person is probably better than at least 50% of people who call themselves devs, let alone most of those whose code is immortalised on this site.
Admin
If you think Excel is low-code, you haven't seen some of the things I've had to maintain.
Admin
"I can do that in my lunch hour." -- A lady non-developer who felt her Lotus Notes skills along with the Notes RAD environment meant that creating a mission critical application would be a breeze.
Admin
Stares at god awful Excel macros that only work under the most specific of circumstances and weeps silent tears
Admin
Right tool, Right Job.... Did some fantastic work with 4GL back in the mid 1980's .... but there were also spectacular failures across the industry...
Admin
I've developed applications in a day using a low/no code tool that would have taken months to get a development team to put together, since what the users wanted was a better version of Excel.
Admin
I don't understand what is with all the hatred toward Excel. Excel and VBA are powerful useful tools that a good developer can use to magnificent effect. I should know as I have. And they are equally good at allowing a low skilled person to easily automate low complexity tasks.
And yes, there are always going to be those idiots that have low skill and high ambitions that are going to try and make things more complex than they are qualified for. But that's true for any tool. Just think how many a front yard has been ruined by an idiot that think they can use a shovel right.
Admin
The use of these tools is because too often the alternative is six months of meetings and raising a budget to get something which only does what you want in certain circumstances and is too fragile to be touched.
Admin
A lot of line-of-business apps can indeed be put together in that sort of time. If you know exactly what you want already. And if you also don't need to handle any failure modes at all. And if you don't want a highly custom GUI or any security. The stuff that takes the time is working out what should be done, dealing with what should happen when things go wrong, making the results look pretty, and not exposing everything to random passing idiots who know how to
Inspect Element.Admin
Excel = good; it's aimed at non-IT people to solve simple to medium level math tasks, together with some database-like features. It works because it's intuitive, mostly reliable, feature rich, and relatively cheap.
Low-code development tools = bad; it's also aimed at non-IT people, more on the database side and less on the math side. But it DOES NOT work because it's hard to configure, limited to basic features (without writing code in some terrible home-grown script language), and the worst part - very expensive.
Admin
Not that it matters much in this case, but the FirstN code is arguably more readable, depending on how familiar you are with PowerFX. Probably a sign that the coder wasn't too familiar with the available debug tools (or they are bad). Plus you have to read through half a page of the Sequence documentation until you see the start option.
Admin
The hatred of Excel would be obvious to you if you ever compared it to , ya know, actual programming. If you've got a N-by-M array of data and you want to do something to it, like say take the sine, you now have N*M formulas in separate Excel cells. Write a program in a real software language, and you have a loop or two and ONE SINGLE formuls. That's just for starters. Since there's no way to display Excel cells in a "dependency order," it's impossible to trace and debug someone else's sheets. I haven't even got to the mess that is Excel VB, and how I can pretty much guarantee anything anyone writes for Excel macros will break when someone inserts a column, or hides a row, or leaves a filter turned on or off.
Admin
It's not that bad. Often times, users want to see intermediate steps in a multi step calculation. There's a dependency visualizer feature, it doesn't reorder cells but it does draw arrow lines. Yes VBA is terrible but it's not that bad, relatively speaking; there are worse languages in use today. And cell references can be created in a way that they're resilient to insertions/etc.
Again, we're talking about non-IT staff getting stuff done without waiting for months until their request is prioritized. Excel is a great tool, for challenges it was designed to solve, and some adjacent ones, too.
Admin
"That's just for starters".... A few years ago, worked with a 50,000 row by "triple letter" spreadsheet... ot a massive array minuind you.. Invots in the middle of nowhere (wounded by tabular data (expand and you crashed the sheet destructively)...At lead 70 different "tables"...
Admin
I think the point was that it was one of their developers who produced that code, and hence should have known better
Admin
Being a PowerApps developer, because that is what I am called now after the, uhm how many times have they changed the name of Microsoft Dynamics CRM now?
Sorry, I lost count, I am a PowerApps developer, yay me! The one thing that strikes me is that it takes an experienced developer time to understand and learn the environment and language(s) of PowerApps. Oh hold on just a second, is this PowerApps Canvas or Model driven? Because that is two different things that use different languages and paradigms.
What I'm trying to say is, good luck citizen developer, you are going to need it. I'll be there if you need a guide, for a fee of course.
Admin
I think I would classify as one of those bad developers. You slag off Excel saying you need n*m formula when you can use array formula. Any good developer has more than a single hammer in their back pocket 9e.g. a 4GL, 3GL, and an assembler) and they know when you need to write code (and choose the correct language) and when you can avoid writing code. The thing about writing no/less code is that you end up having no/less bugs plus you know what you immediately deliver more quickly and affect the bottom line.
Admin
The hatred you might observe probably is because Excel does not really seperate data and code, and even more, does not really separate input, processing, and output. That limitation on one hand is its strength on the other hand, i. e., the hand of non-IT users. They don't do what programmers often do: change the input to test something, analyze the processing code, exchange the code as an experiment, apply standardized tests to the code, or create different outputs from one and the same input, using different or parameterized processing. But from a different point of view, it still provides those non-IT persons programmer-like views and abilities, like table cells instead of variables, formulas instead of functions, and tables instead of structured input data. However, it starts showing significant limitations when you need to process several millions of data lines. Another core problem is that Excel is primarily used within Microsoft Office environments; interoperability and compatibility, except a limited CSV support, does not really exist. And always remember macros: for malware and viruses - very important. Proprietary binary formats that combine input data, processing code, and output data, are often inferior to text representations. There are tasks that Excel users can easily solve, often on their own, but there are tasks that Excel just cannot solve, despite any "But I insist!" or "But I want it!" or "Do what I tell you to do!" or even "We always use Excel for everything, stop arguing!" screaming of the PHB...
Admin
Excel had a declarative functional scripting language you could enter into cells. It was replaced with VBA, but was, for many years, available as a hidden feature if you loaded old pre-VBA script sheets. Can you still load Excel 4 script sheets? I don't know. The more the world changes, the more it stays the same.
Admin
Devil's advocate hat here, but between looking up the function (I want a list of numbers, so I google "list", right?) and finding that it probably gives you not a list/tuple/whatever, but a generator (and there's open-right and closed-right versions of it) which works seamlessly in most cases (which is why all the StackOverflow answers don't make the distinction) but not the case you have, this is a solution that works and is reasonably readable, as opposed to [map (x)->x, (1...37)][:17] or whatnot.
Admin
From Microsoft's Power Fx docs:
My immediate thought was "you'd have people who build spreadsheets building apps the way they build spreadsheets".
Admin
This is the problem with creating an development environment with which you can tell any idiot that they can program: Any idiot then thinks that they can program.
Admin
I think the problem is that it's such a crappy database program, you have to fight it all the way to get anything done. Anyone would think Microsoft were trying do create something almost like a sort of spreadsheet when the wrote it.
Admin
Well of course it's going to break. Take any application and insert or delete random lines of code and it'll break as well. This is not terribly surprising. I mean, take say a C# windows form application, delete half the buttons on the GUI and add new ones without changing the code. See how far that gets you.
Again, don't get me wrong here. I have seen what abuses of excel look like. I just believe that it's not the tool that's the problem but the user. Because in the case of Excel the philosophy behind it is sound and its implementation for that philosophy is good. And problems only arise when people who don't know what they are doing try and abuse it for things or in ways that it violate that philosophy.
It's kind of like how you have tractors and you have F1 race cars. Both have a sound reason for existing and are implemented well for that role. But if you try and race with a tractor or plow with an F1 car the results are predictable. And it was newer the vehicle that was to blame.
Contrast this to as Mr. TA said most low code development tools. Their design philosophy is inherently bad because it boils down to "Lets take a complex skill that is more art than science and automate it away." And as we all know that does not really work without going into machine learning or stuff like that. Thus their implementations inevitably, even if executed well are going to produce questionable results.
And I only stay reserved because I consider GUI editors such as the one in Visual studio or Dreamviewer (anyone remember that one) to be a part of the low code DT category. And those were actually good or at least decent.
Admin
You could wrap it in a RAND function!
Admin
I don't know why people knock Excel. Granted that recent developments to the IO make it more difficult to work out how to get stuff done, once you've got your feet under the desk it's actually really useful.
Never hurts to keep your skills fresh, either, you neevr know when someone's going to ask you to quickly hang a function together to convert times expressed in a weird format into elapsed seconds or milliseconds, or whatever, to interpret run times. Which is what I was asked not too long ago.
In days of old when knights were bold and Java hadn't been invented, we wrote our astrology divination programs in Excel, and had to be contented.
Admin
Apart from, as said, "good spreadsheet, bad database", one reason why I hate Excel is that for some Cthulhu-worshiping reason Microsoft chose to make it insist on adapting to the system locale. With no way around it. I cannot tell Excel "yes, my system is set to Dutch for Company Reasons, but I want CSVs with actual Commas, not SCSVs". And I can change the date format for a cell to, say, ISO (useful for sorting), but I cannot set this as the default: the next sheet will have Dutch dates again. I can set the default locale for spell checking (useful in Word, not so much in Excel), and for the menus - but not for the actual data!
What's worse, this applies not only to the data, but for the formulae! Want to add a bunch of cells with a function? Easy in Excel, right?
=SUM(start:end). Wrong! In a Dutch Excel sheet, that has to be=SOM(start:end). Which means that I cannot send a spreadsheet with formulae in it to someone in England, or Germany, because it will not work. Madness, sheer idiocy.Admin
Well that's oddly specific. What does the gender of the non-developer have to do with anything?
Admin
You're supposed to keep track of those things now in detail because they don't matter.
Admin
Yea, joke's on the identity police. We computer scientists only ever recognize two categories of people "developers" and "non developers".