|
I very much doubt it.
Learning a computer language has never been the hard part of software engineering. The hard parts have been analysis of the problem, design of the solution, and extreme precision in implementing the solution.
Very few people are capable of taking a client's requirements (usually expressed in vague Marketing term), and turn them into a useful specification for a product. It is immaterial whether the product is software or hardware. A larger set of people is capable of taking a specification and turning it into a design, paying attentions to issues such as complexity, memory and CPU usage, etc. An even larger set of people is capable of taking a design and turning it into code, paying attention to the syntax, code structure, code and data coupling, etc. required for development of a non-trivial program. It is this group of people that "low code" solutions attempt to displace.
The promise of "low code" programming it that the user will specify a set of requirements. and the system will "magically" create an application for them. The problem with "low code" programming is that the "programmers" typically have no idea what to do when their code does not work properly - how to discover what is wrong ("debugging"), and how to correct their specifications so that the "low code" environment will give them the application they need ("programming"). For that matter, very few of them have any idea of the testing required before a non-trivial program is released.
I expect that this will end up like most similar fads in the last decades - a few success stories, and a vast number of failed or flawed applications, hidden from the light of day by their implementers.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I agree. At best you're making a higher level language, but it still requires a programmer's mind to operate it effectively.
Real programmers use butterflies
|
|
|
|
|
Most unlikely. I know at least two business people who created Excel spreadsheets where they manually calculated the total fields and typed them in by hand. So every time some value elsewhere was changed they had to go through the same exercise again. When I pointed out that spreadsheets could do automatic totalling they were amazed.
|
|
|
|
|
Judging by some of the questions on this site, absolutely not.
|
|
|
|
|
Just go to QA, apparently it's not even possible for developers to be a developer 
Seriously though, I've worked with a no-code product and it was very limited in what it could do.
You still had to design a database, which was NOT easy with a drag 'n drop interface that had no scrollbar 
Anyway, when the database (or part thereof) was in place, you could get to "developing".
I worked with someone who'd done WinForms for about twenty years, but he didn't understand web concepts at all, and that was what we were making.
A simple form was easy enough, but then again, so is a form in ASP.NET Core Razor Pages (if you know what you're doing).
Anything slightly less easy was exponentially more difficult as you did not have easy access to the JavaScript of the page.
You could write a separate JavaScript file, but you could also add JavaScript to controls in event handler fields.
The problem was, when you deleted a field, so would the JavaScript be deleted.
We've lost quite some code and even entire forms that way.
Source control was not available.
The back-end was drag 'n drop too, so no code at all.
I had to drag and entire routine twice because of an if-else statement
The fun part, when we asked the company how their other customers did this kind of thing, they told us they didn't
Apparently, we were their first customer to use their drag 'n drop interface.
All other customers hired their consultancy company who did everything by writing JavaScript and HTML because that was easier and faster for them
Meanwhile, my customer paid €16,000 a year for the platform.
Told them I could make it in .NET for less than twice the money, with a hosting cost of about €100 a month in Azure.
It would be cheaper after two to three years.
Their product failed, but they're still paying the platform €16,000 because they took an x year contract 
Just a little anecdote, make what you want from it, but personally I think no-code platforms can't deliver on their promises.
With non-developers creating them and with all the code scattered everywhere on these platforms, they're just the next do-it-all Excel sheets that no one knows how it works anymore and everyone prays will keep working.
|
|
|
|
|
Mandatory: The 'no-code' dream… | CommitStrip[^]
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
It still seems useful for making mocks.
Real programmers use butterflies
|
|
|
|
|
All that'll happen is that the term "developer" will change to mean someone that actually writes real code (granted, "real code" is a poorly chosen phrase, but I'm still waiting for the caffeine to kick in and I can't think of a better phrase, but I think you get the point.)
Basically, "developer" will fragment into "low code developers", for which there probably will be some niche in the marketplace, and "the rest of us", that do real things, including developing "low code" applications.
As to "make it possible for anyone to be a developer?", um, no, because all these low code solutions work within the parameters of what you can do with the platform, and while some may be sophisticated, there will always be limitations. So if that "anyone" wants to do something special that the platform doesn't support, well, that's when they learn:
I AM NOT A DEVELOPER!!!
|
|
|
|
|
A better way to create crap apps.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Mike Hankey wrote: A better way to create crap apps crapps.
|
|
|
|
|
In other words it a crap shoot if the app will be worth a crap?
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
You can have the best kitchen, the best appliances, and great ingredients, and still come out with a crappy meal.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
The situation, as I see it, is this:
|
|*
T | *
a | *
s | *
k | *
s | *
| *
| *
| *
|____________________________________
Time/Difficulty
A developer (or team) has a lot of tasks to complete, but most of them are quite easy.
There are some difficult tasks, but they are few. (Your mileage may vary.)
Tools such as described, and ETL packages and such, address only the easiest tasks.
But developers don't need help with those, we need help with the difficult tasks.
Whenever a vendor announces, "we have a tool which will solve all your problems", you can be assured that it actually addresses only the "low-hanging fruit" -- and no one needs help with "low-hanging fruit", that's the definition of "low-hanging fruit"!
At best, such systems can allow a team to expend less time/energy on easy tasks and concentrate on the difficult ones.
And/or allow an enterprise to hire low-paid contractors to deal with the "low-hanging fruit" in a way that the "real" developers can understand and support once the contractors have left.
However, no tool will "do everything".
|
|
|
|
|
PIEBALDconsult wrote: However, no tool will "do everything".
And if it ever gets to do it... we will probably have other bigger problems to worry about
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
You know what will happen. Some manager will get one of these no-code platforms and try to build his own apps. He'll get stuck part way through and then get a developer to try and finish it.
And that will be where we run into the dilemma of trying to complete it in that no-code platform (if it is even possible) or tell that manager it cannot be done and has to be re-written fro scratch...
|
|
|
|
|
Based on the responses so far, developers clearly underestimate the power of low code. I am not familiar with the Microsoft one but I am familiar with Mendix and it is powerful enough to run businesses. It can do anything .Net can do and much easier to build.
Those that think this is just a passing fad will be passed by this "fad."
|
|
|
|
|
Some trivial apps will be possible, but these solutions always have bottlenecks that make somethings very difficult or impossible.
Outside of a dog, a book is a man's best friend; inside of a dog, it's too dark to read. -- Groucho Marx
|
|
|
|
|
Microsoft was offering "no code database development" in Visual Basic 3, and that was released in 1993.
It's true, using VB3 you could build a database system by doing nothing more than dragging and dropping controls onto a form and clicking the property showing where you'd like to source the data from.
Yet here we are, 27 years later, and I'm continuing to have a good career as a software developer specializing in databases.
No code systems will continue to exist, they will continue be used by "Power users" who all have varying degree of skill, and they will continue to be the bane of the real IT professional who is asked to come up and fix the mistakes of the "Power user", usually after data is lost or a business critical limitation is reached.
|
|
|
|
|
Does it bother anyone else that you declare a pointer like:
char* sz;
But an array is declared like this:
char sz[1024];
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and &
Maybe it's just me?
Real programmers use butterflies
|
|
|
|
|
In both instances the first part declares the type, the second declares the variable. The array modifier is telling you how many of the type.
Think of the first declaration as having a silent '[1]' and it becomes consistent.
And you might be 40 years too late for bringing up this argument! 
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I guess that makes sense.
DRHuff wrote: And you might be 40 years too late for bringing up this argument!
At least!
Real programmers use butterflies
|
|
|
|
|
What has bothered me more is the fact that:
int* pa;
int *pa;
are the same. Had I been Bjorn, I wouldn't have allowed the latter.
|
|
|
|
|
I can see why but on the other hand I don't like the idea of significant whitespace between tokens in language. It's one of the reasons I don't like Python.
Real programmers use butterflies
|
|
|
|
|
But you can also write:
int*pa;
int * pa;
the spaces do not affect the binding. And that was the rule way before the great Stroustrup.
|
|
|
|
|
Agree, the later makes no sense.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
