• Industrial Automation Engineer (unregistered)

    but is it wrong?

  • Prime Mover (unregistered)


    NUM_MONTHS = 17;
    Sequence(NUM_MONTHS, 0)


    or whatever the nitwit syntax is of this kiddie-tool.

  • Pag (unregistered)

    But then you're restricted to displaying months in sequential order. The original code doesn't have this limitation.

  • Hanzito (unregistered)

    I don't want to imply that low-code tools are automatically bad

    Very sensible. Of course you wouldn't, because you'd raise the ire of the I-can-do-that-in-Excel crowd.

  • (author) in reply to Hanzito

    Remy's Law of Requirements Gathering: no matter what the actual requirements, what your users really want is for you to implement Excel.


  • Robin (unregistered)

    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.

  • (nodebb) in reply to Hanzito

    If you think Excel is low-code, you haven't seen some of the things I've had to maintain.

  • Duston (unregistered)

    "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.

  • Gubbo (unregistered)

    Stares at god awful Excel macros that only work under the most specific of circumstances and weeps silent tears

  • (nodebb)

    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...

  • Tree (unregistered) in reply to Duston

    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.

  • 516052 (unregistered)

    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.

  • The Shadow Knows (unregistered)

    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.

  • (nodebb) in reply to Duston

    "I can do that in my lunch hour."

    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.

  • (nodebb)

    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.

  • Readable (unregistered)

    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.

  • Carl Witthoft (google) in reply to 516052

    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.

  • (nodebb) in reply to Carl Witthoft

    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.

  • (nodebb) in reply to Carl Witthoft

    "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"...

  • Fizzlecist (unregistered) in reply to Robin

    I think the point was that it was one of their developers who produced that code, and hence should have known better

  • Jacob (unregistered)

    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.

  • Grunthos the Flatulent (unregistered) in reply to Carl Witthoft
    Comment held for moderation.
  • Officer Johnny Holzkopf (unregistered) in reply to 516052

    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...

  • Old timer (unregistered)

    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.

  • löchlein deluxe (unregistered)

    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.

  • (nodebb) in reply to Hanzito

    From Microsoft's Power Fx docs:

    What if you could build an app as easily as you build a worksheet in Excel? What if you could take advantage of your existing spreadsheet knowledge?

    My immediate thought was "you'd have people who build spreadsheets building apps the way they build spreadsheets".

  • (nodebb)

    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.

  • (nodebb)

    I don't understand what is with all the hatred toward Excel.

    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.

  • 516052 (unregistered) in reply to Carl Witthoft

    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.

  • Cratig (unregistered) in reply to Pag
    Comment held for moderation.
  • Prime Mover (unregistered)
    Comment held for moderation.
  • RLB (unregistered) in reply to 516052
    Comment held for moderation.
  • (nodebb) in reply to Duston

    "I can do that in my lunch hour." -- A lady non-developer...

    Well that's oddly specific. What does the gender of the non-developer have to do with anything?

  • Compliance (unregistered) in reply to jkshapiro

    You're supposed to keep track of those things now in detail because they don't matter.

  • 516052 (unregistered) in reply to jkshapiro

    Yea, joke's on the identity police. We computer scientists only ever recognize two categories of people "developers" and "non developers".

Leave a comment on “Low (Quality) Code”

Log In or post as a guest

Replying to comment #:

« Return to Article