6 ms·

After more than two decades in the industry, you start getting cynical towards these kind of "programming for non-programmers" tools. All of them are trying to

by bigato 8y ago

After more than two decades in the industry, you start getting cynical towards these kind of "programming for non-programmers" tools. All of them are trying to abstract away the complex parts of the programming problem. Guess what, it doesn't matter how many layers of abstraction you pile up, you never abstract away the need for consistent logic. You end up requiring the same kind of people that have the brain skills to actually program.

royjacobs 8y ago
But a lot of apps nowadays are essentially just forms to send data to a backend. If those apps can be 'trivially' made then that's a clear win, I'd say? It will certainly not replace a lot of complex applications, but if you just want a quick "order a mouse at the internal servicedesk" app then what's the harm?
- lostcolony 8y ago
  If the needs never change and are 100% addressed by the app maker, fine. In my experience that never happens, though, and you either have an incredibly painful process trying to work around the limitations of the app maker, or you end up with a rewrite anyway.
- commandlinefan 8y ago
  > a lot of apps nowadays are essentially just forms to send data to a backend That was true 30 years ago, when VB was popular, too. Heck, that was true 50 years ago, when CICS was popular. "Forms to send data to a backend" is deceptively complex.
fauigerzigerk 8y ago
True, but there are many people who can handle consistent logic but are not familiar with all the technical detail required for general purpose software development. There is a lot of complexity that is completely unrelated to the core logic of a solution to a particular problem.
- oblio 8y ago
  Is there any of these higher level languages that doesn't add its own accidental complexity? (essential complexity being the one included in the core logic of the solution to the problem). They usually have their own jargon/terminology and concepts to learn. So they just move the goal posts...
  - fauigerzigerk 8y ago
    No, I don't think it's just moving the goal posts if the difference between learning one or the other tool is measured in years. But I think it depends on what sorts of problems and solutions we're talking about. I don't believe for a second that all types of software can be created with this sort of end-user oriented wysiwyg + expressions tool.
- prepend 8y ago
  I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot. I’ve seen lots of demos (and bought lots) of reporting or automation tools intended for the “CEO” to make their own ad how reports only to have that mean that consultants are hired or someone else do it. At the end of the day, the hard part for many people is the idea of variables and abstraction and interfaces and looping and operators. Making a button vs a keyword to do this is maybe easier, but it doesn’t really Bridge very well to non-programmers. The closest I’ve seen is Excel with people who will not try R or Python but can write lots of stuff in Excel functions and pivots and maybe macros.
  - fauigerzigerk 8y ago
    >I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot. There have always been power user types in small and large organisations who are not developers but can create simple solutions, mostly using point and click with some expressions, macros or SQL added in. The ones I have personally met have used dBase, Excel or Access (one of them a non-tech CEO). Of course they had to learn how to do it. But it didn't take them years to learn nor is keeping the skills fresh a full-time commitment. I think this is largely a disagreement over definitions. Can something that doesn't involve writing loops and mutating variables be called "building business apps"? I would say yes, but I understand how reasonable people could disagree on that.
dgudkov 8y ago
It's all relative. One can argue that "true" programmers program in Assembly and languages like Python or Javascript are just high-level abstractions over Assembly. SQL is another type of abstraction which was originally intended to be used by business users (hence the English-like syntax) yet developers are happy with it now. There is a need for wide variety of programming tools, ranging from very low-level to very high-level. Any of them is a trade-off in terms of flexibility / cost of development. Picking the right tool for the right job will always be a problem to solve, but having more tools to choose from would never hurt.
- chasingthewind 8y ago
  >Picking the right tool for the right job will always be a problem to solve My experience has been that this is a very challenging problem. Business leaders consistently apply pressure for faster results (rightly so!) which means that technology leaders will also be under pressure to deliver faster results. Tools at the highest level of abstraction (like the various "declarative programming" app builders) trade away power and flexibility in return for simplicity. The sales teams that sell these tools then inevitably highlight the speed and gloss over the trade off that's being made. The message that buyers (business and tech execs) hear is that a tool can solve problems faster. That is often true when the tool is being applied to a problem for which it's suited and can be disastrously incorrect when it's applied to a problem it's not suited to. My experience is that the promise of "faster" often drowns out the voices warning that a tool is being applied to the wrong kind of problem.
  - ehsankia 8y ago
    Right, that's why the best abstractions are built on solid tools, and if needed, give you access to that lower level foundation. If I can do 95% of my work using the super simple UI, and then for that last 5%, I can go in and hack my way with some code, I'm much happier than having to write 100% of the code with code. Of course, if that last 5% is impossible to achieve at all, then yes, you're definitely not going to be happy and that 95% will have been a total waste.
- taneq 8y ago
neurobashing 8y ago
I had a lot of the same opinions, and then I actually got a job at a low-code platform vendor. The biggest thing I learned, the secret truth, is that "low-code" is intended to be a force multiplier for "real programmers". Low-code dev shops look exactly like every "real" shop I've seen: source control, sprints, Jira, "omg feature creep" meetings, insane stakeholders, the works. "low-code" developers are "real" software developers. They are developing software that is intended to be used at scale by real people to perform a business task that produces value. This stuff is deployed at "real" companies. I'd wager any sum you're using products and services every day that are connected to one of these platforms. (I'm talking, are you an American who goes to the doctor, goes to any national retail chain, buys products and services from large online vendors, etc) It's a complicated and weird industry but it's been incredibly eye-opening.
- slantyyz 8y ago
  You're totally right. Most vertical market solutions were started by advanced end users trying to solve their own day-to-day problems. Chances are they couldn't afford to hire a team of developers to build them a custom solution, so they cobbled one together themselves. Other people in their field see what they're doing, get excited, and a lightbulb goes off - "I can make a business out of this!". Eventually it gets to the point where those solutions need to start following the rigors of a proper dev shop, but in the early days, it's more often than not the "low code" dev that you're talking about.
- tonyedgecombe 8y ago
  Yes, I consulted on such a product for a few years, all the people doing the successful projects with it were programmers. The tool was very productive in it's domain.
- michaelper22 8y ago
  I did QA for a Pega BPM project at a regulated company, working with an off-site (though on-shore) Pega consulting firm. Aside from the usual big-co version of "agile", and that this was a legacy rewrite, the process was more or less the same as regular C#/Java development. Funny thing with Pega is once you break out of the normal BPM-style flow, you'll write almost as much code as an all-code platform, just cookie-cuttered into form fields.
slantyyz 8y ago
>> All of them are trying to abstract away the complex parts of the programming problem. You're right, but you're also looking at it from the lens of a programmer. From a user's perspective, they have a problem to solve, and they just want a tool that will help them. From their perspective, they are not thinking about it like a programming problem. Even if they have to write a little bit of script/code, they don't necessarily perceive what they're doing as programming. That's why Filemaker Pro, Hypercard, Excel, Notes, etc. developed huge popularity among "advanced end users".
- degenerate 8y ago
  But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool. But with programming, it's possible to execute scripts, make system calls, write to files, and initiate network connections to talk to APIs and invoke other 'tools' to continue the task at hand. The tool is now a shape-shifting collection of code that can take on many challenges, limited only by the creativity of the developer. You can't do that with a WYSIWYG, it would be too complex to allow all these functions, so the next best thing is allowing plugins, at which point the tool now requires programming knowledge anyway.
  - slantyyz 8y ago
    >> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. Once again, this depends on the lens you view it with. With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon. I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it. If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options? You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.
earenndil 8y ago
Let me approach this from another angle. Excel, effectively, is 'programming for non-programmers'. And many of the accountants using it don't even realise that what they're doing is programming. So what? It works for them, helps them do their job. Maybe in the future we create neural code interfaces that let us express our code in an abstract symbolic way instead of as a sequence of characters, and we think back on textual code input in a similar way. Obviously the relationship isn't quite the same, but there's definitely a parallel. Some people can write good code and understand it, others can't, same with any platform. So what?

by bigato 8y ago

royjacobs 8y ago

But a lot of apps nowadays are essentially just forms to send data to a backend. If those apps can be 'trivially' made then that's a clear win, I'd say? It will certainly not replace a lot of complex applications, but if you just want a quick "order a mouse at the internal servicedesk" app then what's the harm?

lostcolony 8y ago
If the needs never change and are 100% addressed by the app maker, fine. In my experience that never happens, though, and you either have an incredibly painful process trying to work around the limitations of the app maker, or you end up with a rewrite anyway.
commandlinefan 8y ago
> a lot of apps nowadays are essentially just forms to send data to a backend That was true 30 years ago, when VB was popular, too. Heck, that was true 50 years ago, when CICS was popular. "Forms to send data to a backend" is deceptively complex.

fauigerzigerk 8y ago

True, but there are many people who can handle consistent logic but are not familiar with all the technical detail required for general purpose software development. There is a lot of complexity that is completely unrelated to the core logic of a solution to a particular problem.

oblio 8y ago
Is there any of these higher level languages that doesn't add its own accidental complexity? (essential complexity being the one included in the core logic of the solution to the problem). They usually have their own jargon/terminology and concepts to learn. So they just move the goal posts...
- fauigerzigerk 8y ago
  No, I don't think it's just moving the goal posts if the difference between learning one or the other tool is measured in years. But I think it depends on what sorts of problems and solutions we're talking about. I don't believe for a second that all types of software can be created with this sort of end-user oriented wysiwyg + expressions tool.
prepend 8y ago
I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot. I’ve seen lots of demos (and bought lots) of reporting or automation tools intended for the “CEO” to make their own ad how reports only to have that mean that consultants are hired or someone else do it. At the end of the day, the hard part for many people is the idea of variables and abstraction and interfaces and looping and operators. Making a button vs a keyword to do this is maybe easier, but it doesn’t really Bridge very well to non-programmers. The closest I’ve seen is Excel with people who will not try R or Python but can write lots of stuff in Excel functions and pivots and maybe macros.
- fauigerzigerk 8y ago
  >I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot. There have always been power user types in small and large organisations who are not developers but can create simple solutions, mostly using point and click with some expressions, macros or SQL added in. The ones I have personally met have used dBase, Excel or Access (one of them a non-tech CEO). Of course they had to learn how to do it. But it didn't take them years to learn nor is keeping the skills fresh a full-time commitment. I think this is largely a disagreement over definitions. Can something that doesn't involve writing loops and mutating variables be called "building business apps"? I would say yes, but I understand how reasonable people could disagree on that.

dgudkov 8y ago

It's all relative. One can argue that "true" programmers program in Assembly and languages like Python or Javascript are just high-level abstractions over Assembly. SQL is another type of abstraction which was originally intended to be used by business users (hence the English-like syntax) yet developers are happy with it now. There is a need for wide variety of programming tools, ranging from very low-level to very high-level. Any of them is a trade-off in terms of flexibility / cost of development. Picking the right tool for the right job will always be a problem to solve, but having more tools to choose from would never hurt.

chasingthewind 8y ago
>Picking the right tool for the right job will always be a problem to solve My experience has been that this is a very challenging problem. Business leaders consistently apply pressure for faster results (rightly so!) which means that technology leaders will also be under pressure to deliver faster results. Tools at the highest level of abstraction (like the various "declarative programming" app builders) trade away power and flexibility in return for simplicity. The sales teams that sell these tools then inevitably highlight the speed and gloss over the trade off that's being made. The message that buyers (business and tech execs) hear is that a tool can solve problems faster. That is often true when the tool is being applied to a problem for which it's suited and can be disastrously incorrect when it's applied to a problem it's not suited to. My experience is that the promise of "faster" often drowns out the voices warning that a tool is being applied to the wrong kind of problem.
- ehsankia 8y ago
  Right, that's why the best abstractions are built on solid tools, and if needed, give you access to that lower level foundation. If I can do 95% of my work using the super simple UI, and then for that last 5%, I can go in and hack my way with some code, I'm much happier than having to write 100% of the code with code. Of course, if that last 5% is impossible to achieve at all, then yes, you're definitely not going to be happy and that 95% will have been a total waste.
taneq 8y ago

neurobashing 8y ago

I had a lot of the same opinions, and then I actually got a job at a low-code platform vendor. The biggest thing I learned, the secret truth, is that "low-code" is intended to be a force multiplier for "real programmers". Low-code dev shops look exactly like every "real" shop I've seen: source control, sprints, Jira, "omg feature creep" meetings, insane stakeholders, the works. "low-code" developers are "real" software developers. They are developing software that is intended to be used at scale by real people to perform a business task that produces value. This stuff is deployed at "real" companies. I'd wager any sum you're using products and services every day that are connected to one of these platforms. (I'm talking, are you an American who goes to the doctor, goes to any national retail chain, buys products and services from large online vendors, etc) It's a complicated and weird industry but it's been incredibly eye-opening.

slantyyz 8y ago
You're totally right. Most vertical market solutions were started by advanced end users trying to solve their own day-to-day problems. Chances are they couldn't afford to hire a team of developers to build them a custom solution, so they cobbled one together themselves. Other people in their field see what they're doing, get excited, and a lightbulb goes off - "I can make a business out of this!". Eventually it gets to the point where those solutions need to start following the rigors of a proper dev shop, but in the early days, it's more often than not the "low code" dev that you're talking about.
tonyedgecombe 8y ago
Yes, I consulted on such a product for a few years, all the people doing the successful projects with it were programmers. The tool was very productive in it's domain.
michaelper22 8y ago
I did QA for a Pega BPM project at a regulated company, working with an off-site (though on-shore) Pega consulting firm. Aside from the usual big-co version of "agile", and that this was a legacy rewrite, the process was more or less the same as regular C#/Java development. Funny thing with Pega is once you break out of the normal BPM-style flow, you'll write almost as much code as an all-code platform, just cookie-cuttered into form fields.

slantyyz 8y ago

>> All of them are trying to abstract away the complex parts of the programming problem. You're right, but you're also looking at it from the lens of a programmer. From a user's perspective, they have a problem to solve, and they just want a tool that will help them. From their perspective, they are not thinking about it like a programming problem. Even if they have to write a little bit of script/code, they don't necessarily perceive what they're doing as programming. That's why Filemaker Pro, Hypercard, Excel, Notes, etc. developed huge popularity among "advanced end users".

degenerate 8y ago
But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool. But with programming, it's possible to execute scripts, make system calls, write to files, and initiate network connections to talk to APIs and invoke other 'tools' to continue the task at hand. The tool is now a shape-shifting collection of code that can take on many challenges, limited only by the creativity of the developer. You can't do that with a WYSIWYG, it would be too complex to allow all these functions, so the next best thing is allowing plugins, at which point the tool now requires programming knowledge anyway.
- slantyyz 8y ago
  >> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. Once again, this depends on the lens you view it with. With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon. I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it. If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options? You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.

earenndil 8y ago

Let me approach this from another angle. Excel, effectively, is 'programming for non-programmers'. And many of the accountants using it don't even realise that what they're doing is programming. So what? It works for them, helps them do their job. Maybe in the future we create neural code interfaces that let us express our code in an abstract symbolic way instead of as a sequence of characters, and we think back on textual code input in a similar way. Obviously the relationship isn't quite the same, but there's definitely a parallel. Some people can write good code and understand it, others can't, same with any platform. So what?