This really depends on how you define tech... Is a static website made with SquareSpace tech? Is an excel file tech? I'd argue yes, and if so, then I'd bet that number is much higher than 80%.
So many horse and buggy makers in these comments that can’t see what you see. They think that because some SaaS app they build required so much custom login that low code won’t make a big difference in their world view.
What low code really represents is making automation more accessible for more common tasks without knowing how to develop software. Zapier but for more complex tasks.
20 years ago you had apps like Dreamweaver or Frontpage that enabled this for many people to do static sites like a square space now does dynamic ones.
Sadly though, if history is any teacher, at some point these incremental improvements will create larger low code companies and further consolidate more of the web into a few bigger providers.
Lowcode isn’t designed to replace all code, it’s designed to replace boilerplate CRUD apps with only a thin bit of logic. Often these are the internal apps too that aren’t worth the investment of a “fully coded” solution.
So I started my career a little bit later, but one thing I enjoy is reading about old development horror stories, it seems like all of the worst ones start with either/or 'Access Database' and 'Visual Basic'.
I guess my question is it seemed like the last generation of "No more developer tools" failed, because the problem in programming isn't knowing how to code, after all it seems like pretty much anyone can figure out how to write Python in a weekend, but that learning how to work and think like a developer. Thinking of edge cases, determining data flows, what to do in the event of problems, etc.
So from those that have a little bit more experience than me, what was it like in the age of MS Access, Visual Basic, and how do the new low code tools address those?
EDIT:
Also it says that the tech will be built outside of IT, but who is going to end up supporting that?
> what was it like in the age of MS Access, Visual Basic, and how do the new low code tools address those?
What they all have in common, in my experience, is that they make simple things very simple, but difficult things impossible. If you needed to put a form on a user's desktop and capture what they typed into it, VB was the quickest way to do that. If you wanted to make sure they only put valid dates into the date fields and numbers into the numerical fields, you could do that with a click of a button, too. If you had to do any sort of contextual validation or cross-form validation, or long-running workflow or approval or any of the sorts of value that automation actually promises, it took much, much longer to figure out how to force that square peg into that round hole. It could be done, but it was nearly impossible to test, broke for mysterious reasons under real-world conditions, and was noticeably slow (as in, go get a cup of coffee and come back slow) in use.
When I think of "no-code" tools, I think of Salesforce.com, which to me was "Visual Basic for the web". If you wanted to put up a form on a website and capture what the users typed into it, SF made that simple. But anything beyond that, you were going to spend a lot of time fighting with the undocumented parts of the system.
> What they all have in common, in my experience, is that they make simple things very simple, but difficult things impossible.
Exactly that...
I used to work at a company where all kinds of tools where in place, from normally written Code to some web-based Oracle app and even an Access-like solution. The Oracle stuff turned out to hardly work remotely and being extremely inflexible. Eventually the company was split ("un-merged"), so the Oracle app wouldn't need any further customizations. A few months later from the department that used this Access-like solution the lead was fired.
On the other hand much of the properly engineered code survived several mergers and acquisitions.
It's been a long time, but as I recall there were two problems you'd run into with Access:
1. The database you're using was put together as if it were an excel spreadsheet. There was data duplicated between tables but not linked in any meaningful or consistent way, and fields that were supposed to have a fixed set of choices were terribly unnormalized. Think of a column for colors where you have grey, gray, grya, or Gray that are all intended to be the same color, but were entered by differently and wouldn't show up as the same in the reports that were generated.
2. There were real limits of the capabilities of the technology. Performance would drop for a while, but eventually you'd hit hard size limits and have to split your file into multiple "databases".
The first problem is definitely the kind of problem that you you're describing, where you have people working with a technology they aren't trained in.
Workers with these systems had long check lists they would run through to massage the report data into the form they needed, and these check lists would grow as they found more and more edge cases. I used to think it was crazy, but now I realize the alternative when these systems were built was probably post-it notes on a wall. Sure, eventually they had to have someone rebuild their system (move it to a real RDBMS), but meanwhile the business provided it's value.
Visual Basic wasn't a great language as a language, but the VB application was awesome for developing GUIs for code you'd written in a better language (it was dirt-simple to call C or C++ functions from VB components).
The VB UI builder still hasn't been equaled for straightforward ease-of-use, IMO.
“ “The barrier to become a technology producer is falling due to low-code and no-code development tools,” Gartner VP Rajesh Kandaswamy told VentureBeat. When asked what kinds of tech products and services these findings apply to, he said “all of them.””
Reminds me of the exchange between Katie Couric and Sarah Palin along the same lines:
COURIC: And when it comes to establishing your world view, I was curious, what newspapers and magazines did you regularly read before you were tapped for this — to stay informed and to understand the world?
PALIN: I’ve read most of them again with a great appreciation for the press, for the media —
COURIC: But what ones specifically? I’m curious.
PALIN: Um, all of them, any of them that have been in front of me over all these years.
COURIC: Can you name any of them?
PALIN: I have a vast variety of sources where we get our news.
I have managed to earn a great living using primarily basic LAMP skills for decades.. but in the next three years it will all come to an end. oh noooooo
Somebody’s still going to have to maintain no-code apps. If they do as much as current apps, they’ll be just as complicated as current tech. Seems like that maintenance role will be left to people with system design and debugging skills—i.e. software engineers.
Whelp, time to hang up the ol’ compiler again. Jokes on the author, though. 80% of tech is already built outside of IT, then they find out they need us to clean up their mess.
Those are low code as long as you can change your business requirements to match what the tools can do. SalesForce requires expensive consultants and developers to do anything beyond basic contact management.
No-code tooling or not someone still has to design the workflow. Designing a workflow requires asking good questions, which requires putting in the time with domain experts who aren't necessarily an expert in implementing a workflow with software.
You'll just get different flavors of specialists this time with newer no-code tools. IT will still probably be doing this work. Writing custom code / using generators might still be more optimal to avoid vendor lock-in that is often the revenue strategy of low-code SaaS.
There is such a thing as software literacy just as there is a thing called literacy. We spend the first 15-20 years of life teaching literacy so that a young person will be productive in life.
What makes us think it's going to be different with software?
The idea of low-code is like the idea of writing a novel by cut and pasting loads of blank comic book panels carefully crafted by Marvel Studios.
This job used to be called Analyst-Programmer - and nothing in low code will stop the analyst part from being needed. As for the programmer part, it is way way easier to express yourself in code once you can code than any of these blocky tools.
Yes we desperately need new and better tools and languages and processes and so on. But not dumbing down - skilling up
But, you cannot have Wall Street consolidated market winners if you do that! How dare you!
I saw this first hand growing up. The school system had a couple of programming courses a few years before I got into the high school, and then it got all new computers and magically reduced computer education to only a set of Microsoft Office courses offered.
Who needs programming? The school knew we would all only need Word and Excel at any "office job" we could possibly ever get ...
So much this. I was in that beautiful space where schools experimented with CNA and A+ cert programs that set me in the generalized basics of how to escape from proprietary stacks.
A former employer once decided to empower non-technical users to design their own integrations using zapier. It was fine until someone wrote an action that changed a cell on a spreadsheet, which triggered another action that, itself, triggered the original action. A more software literate user would likely have noticed the infinite loop. That was not a fun week.
And anyway, this specific case was all to keep two calendars in sync, for which there are simpler and more reliable solutions. Even this awareness, of knowing when to look for something instead of making it yourself, is part of software literacy.
It also strikes me that the hyperfocus on UX that we've seen in the past, say, 20 years, has systematically removed users' ability to gain software literacy the way it was mostly done in the past: by tinkering. Current young users are mostly clueless about the workings of their apps, since their attention is so well held by apps' prescribed interactions.
Agreed - I mean I grew up on a couple of Sinclair's. You literally started in a command line. You needed to load up the distracting game from tape. Magazines had print outs to type in (that was less cool but at least you had he point)
Damn I need to start those coding clubs with my kids ... it's like growing up in a chefs house who just orders take out cos he is too tired after a days work. poor kids
Even the tired chef can still raise their kids with a healthy respect for food and cooking. By all means, order takeout every night if you can afford it, but take that as an opportunity for thoughtful critique: "maybe this meal was too salty because it was counterbalancing the sweetness of the sauce, or maybe the meat was rank and so it was oversalted".
Don't beat yourself up :)
Just be thoughtful and expressive with your kids, and they'll find their own way around software. Just like you did ;)
First off, disclaimer, co-founder of Lowdefy [0] and shameless plug. But feel ok since it is on topic.
I 100% agree with you on this. We’ve built many back-office tools for customers and the bulk of the engineering time goes into understanding the problem and tranlating that into data. Tools like Lowdefy make it a lot easier to put this translation into action, but the real work is done by a data literate employee.
We believe that role will stay with it the IT / dev department, at least for any project / tool larger than a Airtable. It use to be all tools larger than a spreadsheet or access DB, but now that scale has increased slightly but not much.
For this reason we are designing Lowdefy to be a dev first low-code platform. By writing apps in a DSL you get the following advantages:
- No steep learning curve for new devs :: All devs are familiar with DSLs.
- Apps follow a structured schema :: Easy to pick up where others left off.
- Nothing is hidden in a GUI :: You can copy, paste, find, replace, review changes, duplicate repos, etc.
- Create and manage apps with code :: Develop scripts, like a visual app builder.
- DSL files work with all dev tools :: Devs want to use their favorite tools.
A lot of the developers these days tend to be integrators. The no-code tooling can help actually take that procedure to a higher abstraction where understanding of the system would still be needed but understanding of the low level details of coding can be completely eliminated.
Think languages like JS or PHP. World have been built using these and many of the developers in these languages don’t have understanding on how computers actually work. People can built money making code with these without learning about data types. Both are regarded as low quality languages but both are extremely productive.
Also, many people who don’t know any computer languages are programming in MS Excel all the time.
Sometimes, some tools are simply extremely productive and intuitive when the mental model of the domain you are solving problems matches the way these tools work.
You don’t need to know “how computers actually work” to write code in high-level languages. Those are too abstracted away from the hardware and OS.
PHP and JS are not considered low-quality languages. They are low-hanging fruit for amateurs to write low-quality software. Yes, people who don’t really know what they’re doing can make money with PHP and JS, just like people who don’t know about food, cooking, nutrition can run a restaurant. That’s not really a good argument for low-code, though.
JS and PHP are often a joke due to their inconsistencies.
Anyway, these are also low-code languages. They are not low hanging fruits because of the syntax or the features but because of the API and boilerplate geared towards specific domain. These almost get out of the way of the people who are not fascinated by the technology itself but by the product they are building.
It’s so easy to use JS and PHP to solve a problem.
For PHP, you simply wrote your code and put in a folder in a LAMP machine and it works.
JS is even easier, you open the developer tools in your favorite browser and there you have it. Instantly start working on your idea.
I’m not unfamiliar with PHP and JS. Those account for about 90% of my work, and have for over a decade.
Every language has its inconsistencies. No question PHP and JS have their faults. That’s what happens when a language gets popular (i.e. actually used rather than just argued about in programmer forums) and the deployed code base grows faster than the developers can “fix” the language. Back-compatibility then imposes real constraints. This happened with C, C++, and SQL too, and every language people actually use to write code with any value. The only joke is smug programmers not getting that we can’t go back in time and fix problems obvious in hindsight unless we’re writing class assignments or hobby projects in Haskell.
I make a good living maintaining and rewriting the first drafts of PHP and JS code written by people who let a bit too much get out of their way. Usually they run into problems of scale, security, maintainability.
If you think deploying a real app that has business value amounts to dropping some PHP files in a folder you should keep my email for when that doesn’t work out. I hope the ransomware hackers don’t find your code first.
I don’t see why you are offended. I love JS but here it is 20min of programming jokes in the expense of JS: https://youtu.be/et8xNAc2ic8
As it comes to PHP, I don’t say that you can do everything by a single PHP file in a web server folder(actually, you can but not comfortably). I’m trying to illustrate it’s low-code nature.
There are no other languages that are that easy to start solving your problem with. Okay, maybe Python.
The newer no-code or low-code tools have the same spirit. They are abstraction layers targeting a domain.
These days there’s plenty you can do by programming visually without any knowledge of programming languages. Not everything needs to scale for throughput.
I’m not offended, I have no investment in those languages, or any language. I just don’t agree.
PHP is easy for beginners because of the tooling, or lack of. As you wrote you can just put PHP files in the right folder and there’s your “Hello, world” web page. The language itself is no less capable and sophisticated than any other C-family language, and PHP’s huge (and inconsistent) standard library goes a long way. But getting a demo or tutorial page up is not software development. You have to write actual code to make even a simple CRUD app, plus understand something about databases. It’s not low code.
You can maybe learn JS in the browser console but that’s not developing anything useful. To run JS on the server you need node and npm and the skills to get that all working. Not low code either.
These are low bar to entry languages/ecosystems but they are not low code/no code solutions.
They have been saying this for years. I’ll start believing it once I have been replaced by some no-code hack that graduated a 2 week boot camp in <insert some “low code” company here>.
Anybody remember “dream weaver” for front end development? Thus was supposed to change the game, yet all we got was unmaintainable, and bloated code.
When I aged out of the cool jobs I figured out how to make a good living as a freelancer mopping up these messes, or replacing them. Dreamweaver and WordPress were the best things to ever happen to programmers who have the stomach for it — bottomless pit of maintenance work. Because the customer depends on these half-baked solutions they will pay me double or more what they paid their nephew who “is good with the computer” to write them.
Things change over time, including APIs. Most of these low/no-code tools offers integrations, using APIs. You'll get something setup and working and then one day it breaks, because the API for your integration changed. Now What?
Now you wait, without your no-code tool working, while someone that actually writes software gets around to fixing it for you.
We'll have 80% of solutions failing sometimes and no one can that help in a timely manner. We'll see how long these solutions last.
What if you need something the no-code tool cannot do? I've used one where you could add your own formulas, much like you can make formulas in Excel. I don't want to work in a tiny edit box to create a giant nested call in your proprietary formula language. Ever had a bunch of nested if statements in Excel? Its real joy, not.
Timing is dubious but I can picture a situation in which some version of 80% (by capitalized cost e.g.) of enterprise CRM, ticketing software, ERP, etc. is configured through something you could legitimately call "low code". I think it's already the case in many places.
I also predict that it will become more and more of a bloated mess, because of lower skill people working on it "anyone can set it up easily, no coding required!" and increasing complex reinvention of the wheel that will have to come up in working around whatever limitations make it "low code" in the first place. Again, enterprise software is well down this road.
Eventually, there will be a backlash and disruption of the enterprise market from something we haven't thought of yet that is way better than what we have to put up with today.
Maybe you have used SAP or Salesforce, or any number of customizable enterprise apps like that. If you wonder how companies get hacked and get their databases stolen or ransomed every day, this is how it happens.
When I first started building applications back in the 90’s, I did it using the only thing I could get my hands on at the time, Access 95. Many of these low-code tools just feel like a web version of that. Form builders, drag and drop, define data types, hook up queries to forms and fields to text boxes and grids. I guess I just got old enough to see the approach come full circle.
That was an explicit design goal of one I worked on a number of years ago.
These tools have their place: they allow smart technical people to be highly productive whilst abstracting a lot of the complexity away.
Low-code tools fill a gap, they're the PHP / Rails / Python for Line-Of-Business / data-driven apps. They allow you to achieve in days what would take weeks in those languages and months in C++.
Agree. And we’ve had those tools available for decades. These new low-code/no-code tools have exactly the same potential user base and exactly the same limitations. No new or even interesting problem is getting solved, just a fresh coat of paint. Or reinventing the flat tire, as Alan Kay put it.
How often do you see commercial or enterprise software written in Access or VBA? What happened to all of those? They either couldn’t grow with the business requirements, or they were so specific and idiosyncratic they couldn’t adapt and constrained the business with their limitations for years.
I've seen a fair number of Access applications that were rewritten simply because they need to work in a web browser. They were otherwise fine.
The system I worked on was specialised but highly capable - it could build applications that are very very hard to get right in PHP (but easy to get kind-of-right-if-you-squint).
What I would really love to see is a top class open source Low Code platform; I believe that it could provide a very nice tool of entry to software development, especially for adults.
One thing to keep in mind about this article: Gartner's only MQ that focuses on app development is based around these "low-code" multi-experience development platforms which comprise exclusively commercial vendors rather than any open source technologies.
They simply do not have a perspective on professional engineering trends for app development, so this prediction about low-code is pretty predictable.
Excel Macros, and MS Access, and the various website template builders, are the best we have done so far with 'low code tooling' for the average joe.
Anything more complex, it is going to require a good degree of programing knowledge/experience.
I think the next version for low code tool, will look more like Visual Basic, for web/development, that will allow average programmers to get more things done.
But you will still need people with basic programing knowledge, regardless.
1. A higher level of abstraction will come along that ends up getting used much more than the current most popular level of abstraction.
2. The same people and same type of people that worked in the old lower abstraction layer will work in the new higher one.
This has happened a bunch of times with computers already. I see no reason that this time point 1 will happen but point 2 won't. And, the article really didn't convince me.
Did they make up this claim or is this grounded in anything? If so I would love to see a paper on this because this seems like an outrageous claim to me.
The underlying press release [1] uses - as suspected - Gartner's beloved phrasing like "Citizen Developers" aimed at gullible managers who they sell this nonsense to with the wording's warm, fuzzy, implications of saving cash spent on those pesky overpaid techies.
Note that there are no "Citizen Consultants", "Citizen Managers", or "Citizen Snake-oil Salesmen" (where surely far more money could be saved at far less loss to business functionality) mentioned in their ridiculous marketing blogs.
You could replace every occurrence of 1991 in this article with 2021, and every occurrence of 2024 with 1994, and it would read exactly like a piece from 1991, and have just as much substance, too.
(Spoiler alert: nope, it didn't happen in 1994, either.)
That is weird argument, just because it didn't happen then, it doesn't happen now? Plenty of tech did not happen the first time around. VR, mobile TV, Electric Cars, Machine Learning, comes to mind.
> That is weird argument, just because it didn't happen then, it doesn't happen now?
If you try to do it the exact same way, without even bothering to look at what happened before, let alone learn any lessons from it, then no, it won't happen now, either.
There seems to be a wave of no code hype, much of it coming from the VC community, and I’m baffled as to what has happened to convince people it’s going to work this time. Is there some breakthrough tool I’m not aware of? Or is it just like this article, a bunch of pitch decks saying “if we can take just 80% of the tech market we’ll be zillionaires”?
I believe GPT-3 being able to convert descriptions of functions or designs into semi-functional code is what has some excited. It's certainly the strongest argument and reason to hope it could be different this time that I know of. I'm skeptical but come from a generative AI background so I wouldn't underestimate it will be able to do things previously unaccomplished by making templates in the past.
GPT-3 does only thing, predict the next character based on the previous n characters.
The nuance of the context (previous n characters) and the quality of the prediction(s) (following character, a function of gpt-3 you can repeat by just concatenating its last prediction to the previous n characters) is what has significantly improved.
It has now learned on a significant amount of the writing available on the internet. Which includes guides on writing code, stack overflow, and github repos.
So one is able to write something that looks like a python comment
// This function adds two numbers
And the following n character predictions of gpt-3 will with some unreliability spit out the python code for that function as its predictions
def add(x, y):
return x+y
This has been shown to work with simple descriptions of pages, with it returning html with css embedded that matches that description.
"No code" opens up more purchases direct from the business groups at a company, rather than through a bureaucratic IT department. I am not surprised that it's being pushed hard.
229 comments
[ 2.9 ms ] story [ 249 ms ] threadlow-code tool might maybe get us back to where we were earlier with VB... but there was a cottage industry of OCX controls, again built by IT.
Same thing is/will happen with 'low code' tools: they all have their internal market, where "IT" sells what can not be done with the low-code tool.
And then, it's like Excel or MsAccess... it works until it does not (or the person who wrote it left the company) and then it needs to be rewritten.
What low code really represents is making automation more accessible for more common tasks without knowing how to develop software. Zapier but for more complex tasks.
20 years ago you had apps like Dreamweaver or Frontpage that enabled this for many people to do static sites like a square space now does dynamic ones.
Sadly though, if history is any teacher, at some point these incremental improvements will create larger low code companies and further consolidate more of the web into a few bigger providers.
Lowcode isn’t designed to replace all code, it’s designed to replace boilerplate CRUD apps with only a thin bit of logic. Often these are the internal apps too that aren’t worth the investment of a “fully coded” solution.
I guess my question is it seemed like the last generation of "No more developer tools" failed, because the problem in programming isn't knowing how to code, after all it seems like pretty much anyone can figure out how to write Python in a weekend, but that learning how to work and think like a developer. Thinking of edge cases, determining data flows, what to do in the event of problems, etc.
So from those that have a little bit more experience than me, what was it like in the age of MS Access, Visual Basic, and how do the new low code tools address those?
EDIT:
Also it says that the tech will be built outside of IT, but who is going to end up supporting that?
What they all have in common, in my experience, is that they make simple things very simple, but difficult things impossible. If you needed to put a form on a user's desktop and capture what they typed into it, VB was the quickest way to do that. If you wanted to make sure they only put valid dates into the date fields and numbers into the numerical fields, you could do that with a click of a button, too. If you had to do any sort of contextual validation or cross-form validation, or long-running workflow or approval or any of the sorts of value that automation actually promises, it took much, much longer to figure out how to force that square peg into that round hole. It could be done, but it was nearly impossible to test, broke for mysterious reasons under real-world conditions, and was noticeably slow (as in, go get a cup of coffee and come back slow) in use.
When I think of "no-code" tools, I think of Salesforce.com, which to me was "Visual Basic for the web". If you wanted to put up a form on a website and capture what the users typed into it, SF made that simple. But anything beyond that, you were going to spend a lot of time fighting with the undocumented parts of the system.
Exactly that...
I used to work at a company where all kinds of tools where in place, from normally written Code to some web-based Oracle app and even an Access-like solution. The Oracle stuff turned out to hardly work remotely and being extremely inflexible. Eventually the company was split ("un-merged"), so the Oracle app wouldn't need any further customizations. A few months later from the department that used this Access-like solution the lead was fired.
On the other hand much of the properly engineered code survived several mergers and acquisitions.
1. The database you're using was put together as if it were an excel spreadsheet. There was data duplicated between tables but not linked in any meaningful or consistent way, and fields that were supposed to have a fixed set of choices were terribly unnormalized. Think of a column for colors where you have grey, gray, grya, or Gray that are all intended to be the same color, but were entered by differently and wouldn't show up as the same in the reports that were generated. 2. There were real limits of the capabilities of the technology. Performance would drop for a while, but eventually you'd hit hard size limits and have to split your file into multiple "databases".
The first problem is definitely the kind of problem that you you're describing, where you have people working with a technology they aren't trained in.
Workers with these systems had long check lists they would run through to massage the report data into the form they needed, and these check lists would grow as they found more and more edge cases. I used to think it was crazy, but now I realize the alternative when these systems were built was probably post-it notes on a wall. Sure, eventually they had to have someone rebuild their system (move it to a real RDBMS), but meanwhile the business provided it's value.
The VB UI builder still hasn't been equaled for straightforward ease-of-use, IMO.
COURIC: And when it comes to establishing your world view, I was curious, what newspapers and magazines did you regularly read before you were tapped for this — to stay informed and to understand the world?
PALIN: I’ve read most of them again with a great appreciation for the press, for the media —
COURIC: But what ones specifically? I’m curious.
PALIN: Um, all of them, any of them that have been in front of me over all these years.
COURIC: Can you name any of them?
PALIN: I have a vast variety of sources where we get our news.
Like the coding is the hard part
By 2024, enterprises won’t even have them on their radar.
You'll just get different flavors of specialists this time with newer no-code tools. IT will still probably be doing this work. Writing custom code / using generators might still be more optimal to avoid vendor lock-in that is often the revenue strategy of low-code SaaS.
There is such a thing as software literacy just as there is a thing called literacy. We spend the first 15-20 years of life teaching literacy so that a young person will be productive in life.
What makes us think it's going to be different with software?
The idea of low-code is like the idea of writing a novel by cut and pasting loads of blank comic book panels carefully crafted by Marvel Studios.
This job used to be called Analyst-Programmer - and nothing in low code will stop the analyst part from being needed. As for the programmer part, it is way way easier to express yourself in code once you can code than any of these blocky tools.
Yes we desperately need new and better tools and languages and processes and so on. But not dumbing down - skilling up
But, you cannot have Wall Street consolidated market winners if you do that! How dare you!
I saw this first hand growing up. The school system had a couple of programming courses a few years before I got into the high school, and then it got all new computers and magically reduced computer education to only a set of Microsoft Office courses offered.
Who needs programming? The school knew we would all only need Word and Excel at any "office job" we could possibly ever get ...
A former employer once decided to empower non-technical users to design their own integrations using zapier. It was fine until someone wrote an action that changed a cell on a spreadsheet, which triggered another action that, itself, triggered the original action. A more software literate user would likely have noticed the infinite loop. That was not a fun week.
And anyway, this specific case was all to keep two calendars in sync, for which there are simpler and more reliable solutions. Even this awareness, of knowing when to look for something instead of making it yourself, is part of software literacy.
It also strikes me that the hyperfocus on UX that we've seen in the past, say, 20 years, has systematically removed users' ability to gain software literacy the way it was mostly done in the past: by tinkering. Current young users are mostly clueless about the workings of their apps, since their attention is so well held by apps' prescribed interactions.
Damn I need to start those coding clubs with my kids ... it's like growing up in a chefs house who just orders take out cos he is too tired after a days work. poor kids
Don't beat yourself up :)
Just be thoughtful and expressive with your kids, and they'll find their own way around software. Just like you did ;)
I 100% agree with you on this. We’ve built many back-office tools for customers and the bulk of the engineering time goes into understanding the problem and tranlating that into data. Tools like Lowdefy make it a lot easier to put this translation into action, but the real work is done by a data literate employee.
We believe that role will stay with it the IT / dev department, at least for any project / tool larger than a Airtable. It use to be all tools larger than a spreadsheet or access DB, but now that scale has increased slightly but not much.
For this reason we are designing Lowdefy to be a dev first low-code platform. By writing apps in a DSL you get the following advantages:
- No steep learning curve for new devs :: All devs are familiar with DSLs. - Apps follow a structured schema :: Easy to pick up where others left off. - Nothing is hidden in a GUI :: You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code :: Develop scripts, like a visual app builder. - DSL files work with all dev tools :: Devs want to use their favorite tools.
[0] - https://github.com/lowdefy/lowdefy
----
With all this said, you can optimize with tools as much as you like - most dev productivity is always lost in building the wrong things.
PS
Low-Def-ee or Loader-fi
?
Think languages like JS or PHP. World have been built using these and many of the developers in these languages don’t have understanding on how computers actually work. People can built money making code with these without learning about data types. Both are regarded as low quality languages but both are extremely productive.
Also, many people who don’t know any computer languages are programming in MS Excel all the time.
Sometimes, some tools are simply extremely productive and intuitive when the mental model of the domain you are solving problems matches the way these tools work.
PHP and JS are not considered low-quality languages. They are low-hanging fruit for amateurs to write low-quality software. Yes, people who don’t really know what they’re doing can make money with PHP and JS, just like people who don’t know about food, cooking, nutrition can run a restaurant. That’s not really a good argument for low-code, though.
Anyway, these are also low-code languages. They are not low hanging fruits because of the syntax or the features but because of the API and boilerplate geared towards specific domain. These almost get out of the way of the people who are not fascinated by the technology itself but by the product they are building.
It’s so easy to use JS and PHP to solve a problem.
For PHP, you simply wrote your code and put in a folder in a LAMP machine and it works.
JS is even easier, you open the developer tools in your favorite browser and there you have it. Instantly start working on your idea.
Every language has its inconsistencies. No question PHP and JS have their faults. That’s what happens when a language gets popular (i.e. actually used rather than just argued about in programmer forums) and the deployed code base grows faster than the developers can “fix” the language. Back-compatibility then imposes real constraints. This happened with C, C++, and SQL too, and every language people actually use to write code with any value. The only joke is smug programmers not getting that we can’t go back in time and fix problems obvious in hindsight unless we’re writing class assignments or hobby projects in Haskell.
I make a good living maintaining and rewriting the first drafts of PHP and JS code written by people who let a bit too much get out of their way. Usually they run into problems of scale, security, maintainability.
If you think deploying a real app that has business value amounts to dropping some PHP files in a folder you should keep my email for when that doesn’t work out. I hope the ransomware hackers don’t find your code first.
As it comes to PHP, I don’t say that you can do everything by a single PHP file in a web server folder(actually, you can but not comfortably). I’m trying to illustrate it’s low-code nature.
There are no other languages that are that easy to start solving your problem with. Okay, maybe Python.
The newer no-code or low-code tools have the same spirit. They are abstraction layers targeting a domain.
These days there’s plenty you can do by programming visually without any knowledge of programming languages. Not everything needs to scale for throughput.
PHP is easy for beginners because of the tooling, or lack of. As you wrote you can just put PHP files in the right folder and there’s your “Hello, world” web page. The language itself is no less capable and sophisticated than any other C-family language, and PHP’s huge (and inconsistent) standard library goes a long way. But getting a demo or tutorial page up is not software development. You have to write actual code to make even a simple CRUD app, plus understand something about databases. It’s not low code.
You can maybe learn JS in the browser console but that’s not developing anything useful. To run JS on the server you need node and npm and the skills to get that all working. Not low code either.
These are low bar to entry languages/ecosystems but they are not low code/no code solutions.
of course, like moores law, its likely not going to engulf everywhere a programmer touches, so new use cases will keep busy.
but take wordpress, you can basicslly build a whole ecommerce site knowing a couple of plugins real well.
Anybody remember “dream weaver” for front end development? Thus was supposed to change the game, yet all we got was unmaintainable, and bloated code.
Now you wait, without your no-code tool working, while someone that actually writes software gets around to fixing it for you.
We'll have 80% of solutions failing sometimes and no one can that help in a timely manner. We'll see how long these solutions last.
What if you need something the no-code tool cannot do? I've used one where you could add your own formulas, much like you can make formulas in Excel. I don't want to work in a tiny edit box to create a giant nested call in your proprietary formula language. Ever had a bunch of nested if statements in Excel? Its real joy, not.
I also predict that it will become more and more of a bloated mess, because of lower skill people working on it "anyone can set it up easily, no coding required!" and increasing complex reinvention of the wheel that will have to come up in working around whatever limitations make it "low code" in the first place. Again, enterprise software is well down this road.
Eventually, there will be a backlash and disruption of the enterprise market from something we haven't thought of yet that is way better than what we have to put up with today.
These tools have their place: they allow smart technical people to be highly productive whilst abstracting a lot of the complexity away.
Low-code tools fill a gap, they're the PHP / Rails / Python for Line-Of-Business / data-driven apps. They allow you to achieve in days what would take weeks in those languages and months in C++.
How often do you see commercial or enterprise software written in Access or VBA? What happened to all of those? They either couldn’t grow with the business requirements, or they were so specific and idiosyncratic they couldn’t adapt and constrained the business with their limitations for years.
The system I worked on was specialised but highly capable - it could build applications that are very very hard to get right in PHP (but easy to get kind-of-right-if-you-squint).
What I would really love to see is a top class open source Low Code platform; I believe that it could provide a very nice tool of entry to software development, especially for adults.
They simply do not have a perspective on professional engineering trends for app development, so this prediction about low-code is pretty predictable.
Anything more complex, it is going to require a good degree of programing knowledge/experience.
I think the next version for low code tool, will look more like Visual Basic, for web/development, that will allow average programmers to get more things done.
But you will still need people with basic programing knowledge, regardless.
1. A higher level of abstraction will come along that ends up getting used much more than the current most popular level of abstraction.
2. The same people and same type of people that worked in the old lower abstraction layer will work in the new higher one.
This has happened a bunch of times with computers already. I see no reason that this time point 1 will happen but point 2 won't. And, the article really didn't convince me.
Note that there are no "Citizen Consultants", "Citizen Managers", or "Citizen Snake-oil Salesmen" (where surely far more money could be saved at far less loss to business functionality) mentioned in their ridiculous marketing blogs.
[1] https://www.gartner.com/en/newsroom/press-releases/2021-06-1...
(Spoiler alert: nope, it didn't happen in 1994, either.)
If you try to do it the exact same way, without even bothering to look at what happened before, let alone learn any lessons from it, then no, it won't happen now, either.
For example Outsystems's software was used to build a hospital management system, commercially.
So they've got a a lot of deployed software for a few years, and some of it is really complex.
And it seems to work. No huge negative PR AFAIK.
And there's ton of demand.
I do wonder what's they're breakthrough though.
I’ve tried to find that out but dunno. Do you have an idea?
The nuance of the context (previous n characters) and the quality of the prediction(s) (following character, a function of gpt-3 you can repeat by just concatenating its last prediction to the previous n characters) is what has significantly improved.
It has now learned on a significant amount of the writing available on the internet. Which includes guides on writing code, stack overflow, and github repos.
So one is able to write something that looks like a python comment
// This function adds two numbers
And the following n character predictions of gpt-3 will with some unreliability spit out the python code for that function as its predictions
def add(x, y): return x+y
This has been shown to work with simple descriptions of pages, with it returning html with css embedded that matches that description.