[20200330_130145 UTC: It appears the author's native language is not English; any mistakes seen here were in the original.--martyb]
Will Low-Code and No-Code merge into a single market segment for both enterprise-class and user-friendly developers?
Today's businesses are implementing enriching their operations with capabilities little by little on a variety of different products. But the trend is clear before you know it, the distinction between tools that are powerful enough for professional development teams and to be simple enough for citizen developers.
[...] Before heading, let's identify the distinct functions of low code and no code in app development, by bifurcating them.
[...] Low Code: Low code is a development move that automates time-consuming manual processes, without manual coding, using a visual IDE environment, which is automation that connects to backends, and application management system.
No code: In the same way as low-code platforms, no code platform uses a visual application system that allows users to create applications without coding. Usually this includes drag and drop functions. An example of this is Salesforce CRM, which enables people with coding skills to code, and those who don't have those skills can build simple apps without using the system.
[...] Artificial intelligence (AI) is soon to be the most disruptive. Some providers are already integrating AI into their Low-Code / No-Code platforms for various purposes. For example, AI can help address the most complex challenges of integrating with semi-structured and unstructured data sources.
[...] Not only do several IT people fear their jobs, but the Low-Code / No-Code also threatens their credibility.
Originally spotted on The Eponymous Pickle.
(Score: 4, Insightful) by JoeMerchant on Monday March 30 2020, @01:25AM (1 child)
If all you need to code is that which has been coded before, no code options are possible and very much the way to go.
If you are developing new or original thoughts - no code solutions won't exist, and low code solutions are unlikely (unless your original thoughts are very simple...)
Different tool for different use cases. Generally, when I start coding something it's because nothing available does what I want the way I want it done.
🌻🌻 [google.com]
(Score: 2) by fadrian on Monday March 30 2020, @02:36AM
Clarke's third law: Any sufficiently advanced technology is indistinguishable from magic.
Adrian's corollary: The same is true for what that advanced technology provides: processor cycles per unit of time and/or amounts of memory indirection.
That is all.
(Score: 4, Informative) by Anonymous Coward on Monday March 30 2020, @01:41AM (4 children)
It's just marketing drivel.
Folks have been blathering on about this for decades [wikipedia.org]:
(Score: 1, Funny) by Anonymous Coward on Monday March 30 2020, @02:38AM (1 child)
At my work we call it "pretty picture programming". The idiots-in-charge drank the cool-aid, so where before we had a system that required one-person occasional maintenance we now have two people full time on trying to make this nonsense do what we want.
Pretty Picture Programming - makes simple things possible (TM)
(Score: 3, Interesting) by Bot on Monday March 30 2020, @03:31AM
Yes, RAD is rapid until you want to do what the framework doesn't provide or provides after too many configuration options. BUT there is a definite class of problems that today are tackled with fucking excel sheets which might be solved better with RAD tools.
RAD done right should include programmability though. Some tools built on pharo or web2py might approach RAD.
Programmability would be also great on phones, we had it with the nokia, hell we had better customizability with the newton...
Account abandoned.
(Score: 3, Insightful) by driverless on Monday March 30 2020, @05:44AM
Even longer than that, it's been going on since the dawn of time computing-wise with things like AUTOCODE in the 1950s. This nonsense crops up every 12-18 months, whenever someone pushing some new product gets the attention of an IT journalist.
(Score: 2) by JoeMerchant on Monday March 30 2020, @01:08PM
My 1989 Masters' Thesis was built around a "visual programming system" where processing blocks were attached to each other graphically (using an off-the-shelf CAD system for electrical design.) Half-way through writing it, I stumbled on Hypercard and LabView... thorough research was harder to do back then, I recall driving 100+ miles to "nearby" libraries that had more complete collections of trade journals than my local one.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday March 30 2020, @02:22AM (3 children)
How many times already, have you observed a flood of exactly these promises fountain out of industry rags, only to bubble a bit then ebb without trace? I can remember no less than three, not that I counted.
(Score: 1, Interesting) by Anonymous Coward on Monday March 30 2020, @02:49AM
My first experience started in 1990. Yes 30yrs ago.
First was main frame development system (wish I could remember the name) running on S/38 (then AS/300) and IBM MAIN Frames. The actual tool ran on PS/2 model 70(?). I reverse engineered our system to their model and feed in 1million lines code, OCL, RPG and ASM. That took almost 3 days. Then asked it to display the first call the menu function in tree view. Came back 1.5hr later... it brought up 4 black bars and 3 lines of black dots. There was too much information for it to display. Each bar was was hundreds of functions blocks call hundreds of function block.
The next one ran on a MAC. IT was version of Silverrun a database design tool. We were using that too redefine the hand coded documentions of the file structures. That was func a fun one it ran real time, but again the completeness of system, it took 7 to 10mins to complete each operations. Think re-entrant database server sending message to itself and other servers to keep all in sync.
(Score: 2) by DannyB on Monday March 30 2020, @03:19PM
Remember a program, advertised in BYTE magazine, in oh, about 1983 or 1984 thereabout.
The Last One
Boy did that one get a lot of hype. It was going to be the last shrink wrapped application that a business person ever needed to buy. No more of these pesky programmers that tell you how difficult or outright impossible your idea is.
Later, there was another one . . .
Savvy
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by hendrikboom on Wednesday April 01 2020, @02:02AM
Wasn't getting rid of coding what Fortran and Cobol originally were intended to do?
They did eliminate a lot of coding, but they introduced another lot of coding.
(Score: 2) by MostCynical on Monday March 30 2020, @02:53AM (4 children)
The supposed 'no code' systems are sold as "configuration only", so no developer time, so 'just' Business Analysts doing all the work..
until something (usually integration-related) requires "changes to the middleware" - which only those missing developers can do...
Further, if a form, field, or 'box' doesn't work "out of the box", it often requires "product enhancement", so a customer has to pay for it.. and, again, those developers are needed.'
On top, these systems are usually "SaaS", so integrating them with 'old school' back ends.. just doesn't work well.. the SaaS crew love developing in Prod, copying back to Dev and then Pushing to UAT (all can be done with copies), rather than Dev/UAT/Prod (have to do all the work a second time in Prod, and hope you did it identically to UAT, or... bork!)
A perfectly good LAMP with a flashy no code UI can't handle 100,000 records, even though the underlying "M" is MySQL which should be able to handle 1,000's of times that... but the 'middleware" pseudo-coder can't cope..
/rant
If they didn't bid cheap and lie, it might be okay.. but that is all system/software sales, these days, so.. you get what you pay for (plus Change Requests!)
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 2) by istartedi on Monday March 30 2020, @07:36AM
The supposed 'no code' systems are sold as "configuration only"
I'll just leave this old comment I made on the green site. [slashdot.org]
Appended to the end of comments you post. Max: 120 chars.
(Score: 0) by Anonymous Coward on Monday March 30 2020, @12:53PM (1 child)
If they didn't bid cheap and lie, it might be okay.. but that is all system/software sales, these days, so.. you get what you pay for (plus Change Requests!)
Microsoft should be all of the evidence anyone ever needs that in the tech industry, or capitalism in general, the ability to sell dramatically outweighs the importance of quality or efficiency.
Sprinkled through discussions like this one there are typically software engineers lamenting the use of bad tools and wasted computer resources. They will rail against Electron, and heavyweight Single Page Applications, and programming languages with high memory overhead like Python or Ruby relative to hyper efficient options like C and Assembly. But the problem isn't engineers using those tools, or their managers. The problem is an industry where a bloated pile of trash like a bad Electron application plus a skilled marketing campaign will sell while something a hundred times as efficient and economical with a less skilled marketing campaign won't.
So yeah, the situation sucks. And the core problem is capitalism.
(Score: 2) by hendrikboom on Wednesday April 01 2020, @02:06AM
I rail against insecure options like C and Assembly relative to programming languages like Python and Ruby and Lisp and Algol 68 and Modula 3 and ...
(Score: 2) by JoeMerchant on Monday March 30 2020, @01:11PM
The problem I have with out SaaS vendor is that their pricing contracts only extend for 2-3 year horizons, but the implicit lock-in after we sink all our development costs to use their systems extends for decades. They have already "renegotiated the deal" I'm sure there are some managers who signed off on them who are "praying they do not renegotiate it further."
🌻🌻 [google.com]
(Score: 5, Interesting) by Mojibake Tengu on Monday March 30 2020, @07:29AM (2 children)
I never accepted mental shift of emerged late IT culture from programmers to developers.
It is a cultural diversion.
I repeat that: it is a cultural diversion, by non-programmers, purpose of which is to prevent people en masse from actually learning how to code, how to code perfectly and how to code complex problems perfectly.
It all started with introduction of high languages and with separation of programmers from the machine internals (consider, what a phone is today: a black box).
The result of this policy at historical scale is clearly visible: we have no perfect code now. And effects of imperfect code leak into other sectors of human society badly.
If this keeps proceeding, we will end with no possibility to solve complex problems at all and self-destruction of human civilization by bad software.
A 3 years old guy with box of fancy cubes is not a developer. He just sits in a stage of learning some kind of manipulation.
This is exactly the same stage with No-code paradigm: A manipulation with pre-made structures. A mental freeze in a toy stage is not the progress, it is regress.
In old times, we had four castes of programers, reflected as a work position too:
Programmer, Unassisted Programmer, Programmer-Analyst, System Programmer.
None of us was a developper.
A real programmer must understand the machine completely first, only then she can start programming perfectly in any language.
Do not fall into ideology of funny abstractions, the real world is bloody materialist.
Know your machine.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by deimtee on Monday March 30 2020, @12:43PM
I have known many people who have tried to learn to code, some of whom I would have said were very smart, who just simply couldn't do it. Others who anyone would agree were not as smart, coded all day long. It's like there is an innate talent that people either have or don't have.
Being smart helps you be a better coder, working hard at it helps you be a better coder, but if the talent is not there you simply won't code.
Also, over 18 years old and still relevant. http://ars.userfriendly.org/cartoons/?id=20011121 [userfriendly.org]
If you cough while drinking cheap red wine it really cleans out your sinuses.
(Score: 3, Insightful) by JoeMerchant on Monday March 30 2020, @01:26PM
Perfection requires simplicity - customers rarely request simplicity, not really. What customers request is what they already have, plus... on a short timetable with limited development budget, can you do it?
🌻🌻 [google.com]
(Score: 5, Interesting) by Anonymous Coward on Monday March 30 2020, @09:43AM
People who don't know anything about programming think the hard part about programming is learning the language. "If only we didn't have to learn the language, we wouldn't need programmers!" That is why ancient languages like COBOL and SQL have "English-like" syntax. SQL was intended for non-programmers to write their own database queries and reports in. Is there any universe today where non-programmers write in SQL? But the language is the important part of programming in the same way that Latin is the important part of being a lawyer. Not only is it not the hard part, trying to make it easy typically makes the situation worse.
What does happen is that tools get better so that things that could only be done by programmers before can now be done by anybody. Those same tools don't get rid of programmers, of course. They make it so they can do even more things, because the important part is translating fuzzy half-baked human ideas into real logical program structures that actually work. "AI" can't do that unless it's strong AI that understands human ways of thinking. Programmers - good ones, anyway - hate building more copies of the same things that have been done a hundred times before. They would rather have this automated.
40 years ago you needed programmers with mainframes to do numerical analysis, but then spreadsheets were invented. 20 years ago you needed programmers to put content on the Internet, but then blogs were invented. Right now you need programmers to build mobile apps, but if all they're doing is simple interactions with minimal creativity, there's no reason it can't be automated just like so many things have been before.
(Score: 2) by DannyB on Monday March 30 2020, @03:24PM
I write tons of code. The IDE is like a good power tool. Like a backhoe instead of a hand shovel to dig a ditch. That doesn't mean your problem is "low ditch". Just as much dirt needs to be moved. The IDE just makes it easier.
At the end of the day, the same code needs to be written. To do the same job. It's just a whole lot easier than using, say Notepad, make files and a command line. (eg, the "shovel" vs backhoe)
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 0) by Anonymous Coward on Monday March 30 2020, @03:40PM
Ask again in ten years.
(Score: 1) by crahman on Monday March 30 2020, @04:45PM (1 child)
Pretty soon the IDE's will actually recognize the problem and auto-write code to solve it before people even notice there was a problem. Everything will just happen automatically. Programmers are just like truck drivers - and just like trucks soon won't have steering wheels or even cabs for drivers, soon computers won't have keyboards or displays for programmers.
(Score: 2) by hendrikboom on Wednesday April 01 2020, @02:12AM
Computers without keyboards are already here. Look at the average video game consoles.