5 ms·

The article doesn't get to the reason that it's doomed to fail. Software developers translate between what humans want and what computers can do. The second par

by adrusi 7y ago

The article doesn't get to the reason that it's doomed to fail. Software developers translate between what humans want and what computers can do. The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially. The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface. Tasks involving concepts in the domain of human desires can, too, be automated, but the technology needed to do so would be AI-complete. In other words, if we had a technology that could automate the work of software developers, the same technology, with relatively minor changes, could be applied to automate any human occupation, including those of the people who want to automate software development. Until then, what we can do is build abstraction on top of abstraction over what computers can do. But that is code. There's a lot of room to make application development easier, to make it require less knowledge. In a lot of cases there's no good reason it isn't easier already. But it can't really become easy until the target stops moving; what computers can do changes too fast for people who want to build a good unified set of abstractions over it.

mooreds 7y ago
> The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface. Yes, this! It's the inquiry into the way the data flows, what the application should do, and how to handle edge cases that is difficult for a lot of business applications. To say nothing of getting various stakeholders to agree. Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table (others can too, but I've seen it far more often with developers). That's not to say that there aren't more and more domains that will be codeless. As another commenter says, if you can stay in a box, a codeless solution like Wix or wordpress.com can solve your problems quite well. But as soon as you step out... Another issue that is never brought up is lifecycle and change management. This is a complex topic that developers spend a lot of time thinking about. Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.
- jiveturkey 7y ago
  > Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table. Well said.
  - mooreds 7y ago
    Thanks! I actually wrote a blog post about this years ago: http://www.mooreds.com/wordpress/archives/46 http://www.mooreds.com/wordpress/archives/46 I should revisit with more modern examples.
- laminar 7y ago
  > Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do. Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales? As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.
  - fragmede 7y ago
    When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs. What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper. Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product. Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.
indigochill 7y ago
>what computers can do changes too fast for people who want to build a good unified set of abstractions over it. I was with you until this line. Is it really the case? x86 has been with us for... a while, and x64 is backwards compatible. We built an abstraction on top of that, a compiler that can take high level languages and turn it into machine instructions. I think what people are looking for next is a compiler that can take something even higher level and "compile" it into high level language. The issue is that if you get too abstract, a standard compiler stops being able to make good guesses about your intent. However, if you built a "high level compiler" around specialized domain-specific use cases, then you might be able to make reasonable higher-level guesses about intent (though as with normal compilers, you'd need support for advanced developers to work around those assumptions).
- jacobush 7y ago
  I was also hesitating over that line. Maybe it's implied that computers enter new business areas all the time, which certainly is true. I have been in the game long enough to notice the same patterns of explosive growth and associated API chaos etc etc. Nowadays you can do everything in Node.Js for instance, but first you had to "reimplement all things!" except in many cases they didn't know (or care) they were reimplementing. I usually snark on Node.js but not really in this case, I understand well when the platform imposes a moat and it's easier to just re-do than integrate. Ain't nobody got time for that... it's still something of a tragedy but it's not something we have an easy fix for.
- adrusi 7y ago
  Not only advances in hardware affect what computers can do. Advances in software let computers do more things, but we can't count those when considering automating all software development, it wouldn't make sense. But there are advances in the capabilities of computers that are neither hardware developments nor the job of software developers, namely business/legal and theoretical advancements. So some new "things computers can do" from the last 20 years: - Fit in our pockets - Communicate wirelessly between any two major population centers on the planet, with high bandwidth - Store exabytes of data - Do excellent pattern-matching of all sorts of data - Be close to your customers, wherever they are on the planet, without you needing to have a ton of capital upfront - Cost as little as $7 while still being compatible with our complex software stacks - Be powerful enough to run an Electron application - Monitor your blood glucose levels and deliver the right amount of insulin in real time
kabdib 7y ago
> The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially I have a chipset that I'd like modeled, and can I have some trivial drivers by next Tuesday? Modern computers are not trivial. They are probably the most complicated devices on the planet, full of features, edge conditions and screw cases that are not obvious even to very skilled developers. I've done some very fast platform bring-ups and gotten them to ship, projects organized to be very light-weight and agile (in the non-political sense) and it's still many person-years of effort and a bunch of time on the phone with vendor support, discussing chip-level bugs (can that model please include the bugs? That would help a lot!) No talk at all about pleasant abstractions, we need to ship this pile of silicon. Visual interfaces are for toy programs that spend resources on making pretty illusions of how the world should work. Underneath the pretty glitz are piles of slain dragons and machinery that people take for granted and apparently think can be wished away. That's fine for end-users and application level folks, assuming they can get their jobs done without resorting to breaking the abstractions (and any sufficiently large or long-lived project will). But someone has to worry about memory management, concurrency and synchronization, all the drivers for fucked-up hardware that (say) locks up when you fire data at it too fast, what happens when the file system fills up or that configuration file is mangled by an upgrade. All that nasty stuff that the "drag a blue wire from point A to point B -- see, easy!" doesn't handle, and never will. On one project we had a clock that would, very occasionally, go backwards in time. It took a calendar year of going back-and-forth with support and ultimately a phone call with the chip architect to figure out the problem (the workaround for the bug was unpleasantly expensive). It's easy to model a clock and come up with a set of expectations. It is much, much harder to make a clock work in the real world. You would not believe how hardfought some of this stuff is, for features that are "trivial". Visual programming is great when it works -- I've certainly done my share of it -- but we should not mistake ease-of-use in some domains for revolutionizing programming in general, or (worse) expecting the paradigm to work when things get complicated and large.
- edmundsauto 7y ago
  Note that the "trivial", as used in this context, probably means something more like "we know the domain pretty well", versus "can be completed in 5 days". There are still some ghosts, but I believe OPs point was that pales in comparison to the demons invoked when trying to "calcify the business process".
sametmax 7y ago
That and also: - dealing with the environment. My program always works perfectly until it moves away from my laptop. - debugging. If you don't know how to code, good luck to find the error in your system. - interfacing. Your codeless stuff is going to work fine for everything that it already know. But new stuff are coming. Somebody will need to code for that. Now I do think that eventually AI will be able to manage all that. And that it will give human a fuzzy codeless experience. But it will take A LOT of time before we get there.

by adrusi 7y ago

mooreds 7y ago

> The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface. Yes, this! It's the inquiry into the way the data flows, what the application should do, and how to handle edge cases that is difficult for a lot of business applications. To say nothing of getting various stakeholders to agree. Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table (others can too, but I've seen it far more often with developers). That's not to say that there aren't more and more domains that will be codeless. As another commenter says, if you can stay in a box, a codeless solution like Wix or wordpress.com can solve your problems quite well. But as soon as you step out... Another issue that is never brought up is lifecycle and change management. This is a complex topic that developers spend a lot of time thinking about. Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.

jiveturkey 7y ago
> Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table. Well said.
- mooreds 7y ago
  Thanks! I actually wrote a blog post about this years ago: http://www.mooreds.com/wordpress/archives/46 http://www.mooreds.com/wordpress/archives/46 I should revisit with more modern examples.
laminar 7y ago
> Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do. Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales? As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.
- fragmede 7y ago
  When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs. What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper. Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product. Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.

indigochill 7y ago

>what computers can do changes too fast for people who want to build a good unified set of abstractions over it. I was with you until this line. Is it really the case? x86 has been with us for... a while, and x64 is backwards compatible. We built an abstraction on top of that, a compiler that can take high level languages and turn it into machine instructions. I think what people are looking for next is a compiler that can take something even higher level and "compile" it into high level language. The issue is that if you get too abstract, a standard compiler stops being able to make good guesses about your intent. However, if you built a "high level compiler" around specialized domain-specific use cases, then you might be able to make reasonable higher-level guesses about intent (though as with normal compilers, you'd need support for advanced developers to work around those assumptions).

jacobush 7y ago
I was also hesitating over that line. Maybe it's implied that computers enter new business areas all the time, which certainly is true. I have been in the game long enough to notice the same patterns of explosive growth and associated API chaos etc etc. Nowadays you can do everything in Node.Js for instance, but first you had to "reimplement all things!" except in many cases they didn't know (or care) they were reimplementing. I usually snark on Node.js but not really in this case, I understand well when the platform imposes a moat and it's easier to just re-do than integrate. Ain't nobody got time for that... it's still something of a tragedy but it's not something we have an easy fix for.
adrusi 7y ago
Not only advances in hardware affect what computers can do. Advances in software let computers do more things, but we can't count those when considering automating all software development, it wouldn't make sense. But there are advances in the capabilities of computers that are neither hardware developments nor the job of software developers, namely business/legal and theoretical advancements. So some new "things computers can do" from the last 20 years: - Fit in our pockets - Communicate wirelessly between any two major population centers on the planet, with high bandwidth - Store exabytes of data - Do excellent pattern-matching of all sorts of data - Be close to your customers, wherever they are on the planet, without you needing to have a ton of capital upfront - Cost as little as $7 while still being compatible with our complex software stacks - Be powerful enough to run an Electron application - Monitor your blood glucose levels and deliver the right amount of insulin in real time

kabdib 7y ago

> The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially I have a chipset that I'd like modeled, and can I have some trivial drivers by next Tuesday? Modern computers are not trivial. They are probably the most complicated devices on the planet, full of features, edge conditions and screw cases that are not obvious even to very skilled developers. I've done some very fast platform bring-ups and gotten them to ship, projects organized to be very light-weight and agile (in the non-political sense) and it's still many person-years of effort and a bunch of time on the phone with vendor support, discussing chip-level bugs (can that model please include the bugs? That would help a lot!) No talk at all about pleasant abstractions, we need to ship this pile of silicon. Visual interfaces are for toy programs that spend resources on making pretty illusions of how the world should work. Underneath the pretty glitz are piles of slain dragons and machinery that people take for granted and apparently think can be wished away. That's fine for end-users and application level folks, assuming they can get their jobs done without resorting to breaking the abstractions (and any sufficiently large or long-lived project will). But someone has to worry about memory management, concurrency and synchronization, all the drivers for fucked-up hardware that (say) locks up when you fire data at it too fast, what happens when the file system fills up or that configuration file is mangled by an upgrade. All that nasty stuff that the "drag a blue wire from point A to point B -- see, easy!" doesn't handle, and never will. On one project we had a clock that would, very occasionally, go backwards in time. It took a calendar year of going back-and-forth with support and ultimately a phone call with the chip architect to figure out the problem (the workaround for the bug was unpleasantly expensive). It's easy to model a clock and come up with a set of expectations. It is much, much harder to make a clock work in the real world. You would not believe how hardfought some of this stuff is, for features that are "trivial". Visual programming is great when it works -- I've certainly done my share of it -- but we should not mistake ease-of-use in some domains for revolutionizing programming in general, or (worse) expecting the paradigm to work when things get complicated and large.

edmundsauto 7y ago
Note that the "trivial", as used in this context, probably means something more like "we know the domain pretty well", versus "can be completed in 5 days". There are still some ghosts, but I believe OPs point was that pales in comparison to the demons invoked when trying to "calcify the business process".

sametmax 7y ago

That and also: - dealing with the environment. My program always works perfectly until it moves away from my laptop. - debugging. If you don't know how to code, good luck to find the error in your system. - interfacing. Your codeless stuff is going to work fine for everything that it already know. But new stuff are coming. Somebody will need to code for that. Now I do think that eventually AI will be able to manage all that. And that it will give human a fuzzy codeless experience. But it will take A LOT of time before we get there.