8 ms·

The other problem with low code is that the visual abstraction can often make it harder to grok. I've had the unfortunate experience of spending hours trying t

by cjonas 3y ago

The other problem with low code is that the visual abstraction can often make it harder to grok. I've had the unfortunate experience of spending hours trying to click through different nodes of a moderately complex Salesforce flow to piece together WTH it's doing. It's also impossible to diff two across revisions. If the same solution were written in code using high level libraries it would be a few hundred lines. I wish these low code solutions would build on top a traditional text based language and allow you to flip back and forth.

whstl 3y ago
To be fair, plenty of solutions involving code and high-level libraries can be incredibly difficult to grok too. I’m currently suffering through nested serializers and business objects that have too much custom metaprogramming. What’s worse: some of those would have been trivial when written in a more direct manner and would benefit from no-code tools.
- hinkley 3y ago
  I hope the next evolution in software development includes caring about what your stack traces look like. Pattern based development is especially noisy that way. By the time you find a value going wrong you’ve forgotten why you needed to know that.
  - whstl 3y ago
    I totally agree. Lately I've been seeing "A Philosophy of Software Design" by John Ousterhout making waves with more experienced developers, and I definitely think it's going in the right direction of having richer abstractions and focus on DX rather than forcing the atomization of source code.
hinkley 3y ago
I’ve spent a good deal of time looking at code with other people, and one of the things I have seen first hand is how blind we are for a species with front facing eyeballs. I spent a good chunk of my childhood doing word searches and “find seven differences” puzzles. And a good chunk of college playing text based games with a friend who would run around so fast that the screen was a blur. Somehow he could still read it, and I eventually learned to barely keep up with him. I use that skill today every time I’m tailing logs. He wasn’t “unusual”. I was unusual, he was a genuine freak of nature. Almost nobody spots bugs as fast as I do, and getting them so see a line I’ve described verbally is a chore (line numbers are always on when I pair now) and I am far from infallible. So when people tell me we are going to have non technical people look at a picture and determine what’s wrong with it, or two pictures and tell me the difference, well I am extremely skeptical. Every time graphical programming comes up, I assert that visual diff tools are the main thing blocking them from being feasible, and that assertion is generally well received. Today there are a couple companies who might eventually get there, but they are focused on browser testing. I think that means commodification will have to happen first, as there’s not much money in dev tools.
ralphc 3y ago
I tried to do that with Salesforce flows, back when I did work in Salesforce. I started off with Scheme macros, got as far as variables and constants but it quickly got too complicated. Right before losing interest I was exploring using BabelJS to parse JavaScript into AST's then generate Flow XML from an AST. I think this approach would have more legs.

by cjonas 3y ago

whstl 3y ago

To be fair, plenty of solutions involving code and high-level libraries can be incredibly difficult to grok too. I’m currently suffering through nested serializers and business objects that have too much custom metaprogramming. What’s worse: some of those would have been trivial when written in a more direct manner and would benefit from no-code tools.

hinkley 3y ago
I hope the next evolution in software development includes caring about what your stack traces look like. Pattern based development is especially noisy that way. By the time you find a value going wrong you’ve forgotten why you needed to know that.
- whstl 3y ago
  I totally agree. Lately I've been seeing "A Philosophy of Software Design" by John Ousterhout making waves with more experienced developers, and I definitely think it's going in the right direction of having richer abstractions and focus on DX rather than forcing the atomization of source code.

hinkley 3y ago

I’ve spent a good deal of time looking at code with other people, and one of the things I have seen first hand is how blind we are for a species with front facing eyeballs. I spent a good chunk of my childhood doing word searches and “find seven differences” puzzles. And a good chunk of college playing text based games with a friend who would run around so fast that the screen was a blur. Somehow he could still read it, and I eventually learned to barely keep up with him. I use that skill today every time I’m tailing logs. He wasn’t “unusual”. I was unusual, he was a genuine freak of nature. Almost nobody spots bugs as fast as I do, and getting them so see a line I’ve described verbally is a chore (line numbers are always on when I pair now) and I am far from infallible. So when people tell me we are going to have non technical people look at a picture and determine what’s wrong with it, or two pictures and tell me the difference, well I am extremely skeptical. Every time graphical programming comes up, I assert that visual diff tools are the main thing blocking them from being feasible, and that assertion is generally well received. Today there are a couple companies who might eventually get there, but they are focused on browser testing. I think that means commodification will have to happen first, as there’s not much money in dev tools.

ralphc 3y ago

I tried to do that with Salesforce flows, back when I did work in Salesforce. I started off with Scheme macros, got as far as variables and constants but it quickly got too complicated. Right before losing interest I was exploring using BabelJS to parse JavaScript into AST's then generate Flow XML from an AST. I think this approach would have more legs.