3 ms·
I've seen end-user-built-app Excel code enough times to have a distaste. Maintenance is 2/3 of average software cost, and that [bleep] ain't maintainable. It's
by tabtab 6y ago
I've seen end-user-built-app Excel code enough times to have a distaste. Maintenance is 2/3 of average software cost, and that [bleep] ain't maintainable. It's good for prototyping, but shouldn't remain in production for anything of importance.
As far as general "low code" or "no code", I've seen that promise for many decades. They keep reinventing failed ideas under new names. Clickable wizards, rule lists, and drag-able flow-charts can only take you so far. The devil is in the details, and these don't handle details well. And they are hard to factor.
Your Uncle Bob may be able remodel your house for cheap, but what do you do when rain leaks in and the lights stop working? Or worse, catch on fire?
Remember: Total Cost of Ownership.
- samhain 6y agoThere was a post on here a few weeks ago that discussed code as the translation between the desire for a particular behavior from the person coding, and the machine instruction that needs to be executed. The comment section had a video of Guy Steele talking about growing computer languages, and was trying to make an argument for Computer Science Metanotation being one of them. [1] He started of the talk describing Regex, and how it came to be, and basically showed how that functions have been/could be formally described in papers the same way that Regex is used. In the same way regex formalized the notation for string parsing, so too will the next language regular function expression formalize. Perhaps computer meta notation is the source of true no-code solutions? Perhaps instead of reading articles about "The Unreasonable Effectiveness of Regex," in the future, we'll be reading about "The Unreasonable Effectiveness of Computer Science Metanotation." I also understand that what no-code solutions we are typically talking about is a user interface that is graphical, drag-and drop. But who is to say we don't create a tool that does that with CSM? [1]: https://www.youtube.com/watch?v=qNPlDnX6Mio&ab_channel=ErlangSolutions https://www.youtube.com/watch?v=qNPlDnX6Mio&ab_channel=Erlan...
- tabtab 6y agoI find declarative and functional (D/F) code is often difficult to debug. It's generally easier to break imperative code into fractal-like steps, sub-steps, sub-sub-steps etc. D/F just can't be dissected fractal-ish like that nearly as easy. It's just a magic property of imperative code that's hard to replicate in other paradigms. It's why imperative still dominates after 50+ years of D/F attempts. Someone once said that D/F makes it easier to express what you intend, but imperative makes it easier to figure out what's actually happening. One improves writing, the other improves reading (or at least debugging).
- michaelmrose 6y agoOne can still break a larger function into smaller ones and use a debugger to see intermediate values.
- ssivark 6y agoOn the other hand, imperative code sometimes makes it very difficult to compare what is happening with what you want to happen (problem specification).