Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Cloud Businesses Google Microsoft Programming

Unqork CEO: Anything Java Coders Can Do, No-Code Can Do 200x Faster (cnbc.com) 206

Posted by EditorDavid from the quick-coding dept.
Here's some interesting thoughts from long-time Slashdot reader theodp: CNBC reports that the next frontier in the Microsoft, Google, Amazon cloud battle is over a world without code.

Google recently acquired no-code app development platform AppSheet, Microsoft just launched a new public preview of its low-code Power Apps mobile app for iOS and Android, and there is speculation about an 'Amazon for Everyone' product from AWS. "Anything a Java developer or engineer can build using custom code, we can do it 200 times faster," boasted Unqork CEO Gary Hoberman, whose no-code company raised $131 million in its latest funding round from investors that included Alphabet.

The promise of no-code development platforms has been touted for decades — is it different this time?
This discussion has been archived. No new comments can be posted.

Unqork CEO: Anything Java Coders Can Do, No-Code Can Do 200x Faster More

Unqork CEO: Anything Java Coders Can Do, No-Code Can Do 200x Faster

Comments Filter:

  • no (Score:5, Insightful)

    by Tom ( 822 ) on Sunday April 05, 2020 @05:56PM (#59911390) Homepage Journal

    The promise of no-code development platforms has been touted for decades â" is it different this time?

    No. Of course not.

    RAD-tools have their place, but they don't replace code. Never did, never will. But they can take care of a lot of nonsense that would otherwise take hours to code - hours that a hundred other devs already wasted doing basically the same thing.

    But your logic behind that stuff will always be easier to express in code than in clicking fancy boxes together or whatever the method of the year is.

    • Re: (Score:2)

      by hey! ( 33014 )

      They generate a need for coders as people jump in because of the low barrier to entry and then run into other kinds of barriers.

    • Re:no (Score:5, Insightful)

      by lgw ( 121541 ) on Sunday April 05, 2020 @06:13PM (#59911460) Journal

      Indeed. These tools are nice for organizations that have high barriers around internal users getting small changes from a dev team: reams of paperwork, or whatever. They let non-coders do simple things slowly, which can be a lot faster than "2 weeks of bureaucracy, 2 hours of coding", even if it takes 2 days. Of course, there will be no testing, no code review, just "tinker till it seems to work", but if that for a tool only you wil use, that may be fine.

      • I dealt with these things for 30 years.

        1) They always created a rats nest of special projects that were undocumented, didn't follow corporate requirements or standards, had logic flaws in them which produced bad numbers, and were eventually dumped on IT to support.

        2) Frequently become so complex that they required $50 an hour consultants to work on them after the original gear head executive moved on.

        And executives *always* had the power to force support for these things onto IT.

      • if that for a tool only you wil use, that may be fine.

        But it isn't. And even if it is, it doesn't stay that way.
        As someone else said, when it doesn't work "it's to do with computers, why can't IT fix it?"

    • Re:no (Score:5, Interesting)

      by ath1901 ( 1570281 ) on Monday April 06, 2020 @03:23AM (#59912368)

      Also, it's not just about the time it takes to code. Maintenance and continued development are big issues where "no-code" tools do poorly.

      Spreadsheets are great "no-code" tools for quick prototyping or small programs with small, clean, well defined inputs. But, spreadsheets scale poorly and eventually turn into non-readable, error prone crapfests that are impossible to understand, extend or debug. I've worked at companies that successfully used Excel as an interface but only as a shallow front with all the business logic in a back end written in a real programming language (not VB). As soon as the business logic is in the spreadsheet itself (or VB), it turns ugly real quick if the requirements change or evolve.

      RAD tools are great for small, quick and dirty programs but can't do abstractions and generalisations well or at all. "Real" programming excel at abstractions, generalisations and compartmentalisation because over time, that is what matters.

      • It's like building the Nimitz by extending a barrel raft.
        But it's already there, and it *nearly* does what we want ...

      • Re: (Score:2)

        by Tom ( 822 )

        Spreadsheets are great "no-code" tools

        No, they are not.

        Spreadsheets are spreadsheets. Everyone who built and "Excel Tool" is a moron who deserves to be fired, shot, quartered and hanged. In any order. I fully realize that sort of crap runs half the economy. I also know of the studies that found about a third of complex spreadsheets contain errors that spoil the results.

        spreadsheets scale poorly and eventually turn into non-readable, error prone crapfests that are impossible to understand, extend or debug.

        This.

        That's why Excel is not a dev tool, code or no code. It's a spreadsheet. If you use it for more serious stuff, you're in the same league of people who use Word - a tool to w

    • Re: (Score:2)

      by zmooc ( 33175 )

      But your logic behind that stuff will always be easier to express in code than in clicking fancy boxes together or whatever the method of the year is.

      ... for a programmer. And since programmers are all busy doing such nonsense, they're in short supply. RAD-tools that are focused at programmers are mostly bullshit. RAD-tools that allow non-programmers to do part of the job, even if it takes them 10 times as long, can significantly aid in increasing output _and_ quality.

  • Suspicious when you can't see details (Score:5, Interesting)

    by SuperKendall ( 25149 ) on Sunday April 05, 2020 @05:56PM (#59911394)

    I went to look at what Unqork did, first by clicking on the link which was basically a long Tweet continuing no detail, then searching for the company website which may as well have just been a tweet as it contained no details also.

    The only way you can see anything is a "request a demo". Any time they put technical detail behind a wall like this you cannot look at, is highly suspect to me.

    I'm sure there is some place for the no-code systems, and some things might be able to be built up very fast from it... but all of those systems seem to have limitations that product designers find intolerable about a year after anything is deployed with them (if not before).

    I guess it could be good enough for enterprise work where quality and scalability doesn't really matter for the most part, but for anything targeting general consumer use I'm not so sure...

    • IT looks like drag-and-drop cloud deploys of spreadsheets and data sources for the financial industry. That's my guess.

    • Same experience here. All they show is a bunch of very ordinary web forms and what looks like a flowcharting tool. And claims about a big library of "templates" and stuff.

      • It's probably MIT's Scratch with more corporate (i.e. grey) front-end.
        Not bagging on Scratch here, it's fine for its contractually obligated dolphin.

    • Basically it falls back to "if it's looking like it's too good to be true it probably is"

      When you have automatically generated code, how do you ensure that there are no bugs? And how do you protect yourself against malicious attacks against your systems?

    • When you see "Request a demo" or "Sign up for our mailing list for more info" that means one thing only-- there is no product yet. It's a way for the bean-counters to gauge market demand. If there's X amount of signups, they'll go back and ask for more funding and MAYBE start building something... maybe.

    • Any time they put technical detail behind a wall like this you cannot look at, is highly suspect to me.

      I agree! And the worst thing is that usually they want to many details about you and a salesman will call you before you even can download the demo.

      And in this case they don't even mention on what OS the software is running, I assume: neither linux nor Mac is supported.

  • One phrase from the article is all you need (Score:5, Insightful)

    by phantomfive ( 622387 ) on Sunday April 05, 2020 @06:00PM (#59911408) Journal
    From the article:

    "Unqork, which employs approximately 100 coders itself"

  • No Silver Bullet (Score:3)

    by DRichardHipp ( 995880 ) on Sunday April 05, 2020 @06:10PM (#59911452)
    The inescapable logic of http://faculty.salisbury.edu/~... [salisbury.edu] still applies. Perhaps the Unqork CEO and the editors of CNBC would benefit from reviewing that classic paper.

    • Thanks for the link!

      The only "silver bullet" I can think of that keeps on giving are libraries. I am definitively 100-1000x faster using Pandas to read a csv, calculate some logs or rolling averages and then plotting the result than if I'd do the same thing from scratch in C (or assembler or punch cards). But, the "essential difficulty" can't be reduced much further since only I know what the program should read, compute and present. I don't think a "no-code" tool would be any faster than Pandas for this pa

  • Optimized for sales pitch (Score:4, Insightful)

    by hugetoon ( 766694 ) on Sunday April 05, 2020 @06:12PM (#59911456)

    I am now stuck working on Salesforce based portal (and I hate it with all my guts).

    Salesforce also promises no-code painless app development:
    "What if I told you that no matter what your educational or professional background is, you could build a cloud app today?" www.salesforce.com, 2012

    Well, what I can tell with a great deal of certitude that Salesforce was optimized for one thing and once thing only: sales pitch.
    Sure You can quickly setup with few clicks a prof-of-concept typical application/portal/website (call it however You want).
    But as soon as You need to customize it comes in non-sensical, gotchas-bloated and arbitraty-limits-ridden pile of crap that tries-but-fails to reinvent the wheel (SQL, OOP etc).

    Beware of products to good to be true, most of the time they amount to well-crafted presentations with no solid technology to keep the promises.

    • Sure You can quickly setup with few clicks a prof-of-concept typical application/portal/website (call it however You want). But as soon as You need to customize it comes in non-sensical, gotchas-bloated and arbitraty-limits-ridden pile of crap that tries-but-fails to reinvent the wheel (SQL, OOP etc).

      Heh, that almost sounds like the Confluence CMS by Atlassian.

      Beware of products to good to be true, most of the time they amount to well-crafted presentations with no solid technology to keep the promises.

      Okay now I know it's Confluence. And JIRA for that matter. Utter pieces of shite.

      • Well, Jira is considered to be the best issue tracker in the world.
        So it would be interesting what you find "shit" about it.

    • "What if I told you that no matter what your educational or professional background is, you could build a cloud app today?"

      I would tell you that you have a serious head injury.

  • No-code systems tend to be toy block affairs designed for a very specific niche. Wake me up when a no-code system can implement its own compiler.

    • I'll be honest, that sounds like a really fun challenge, now I want to try to design something like that.

      • Re: (Score:3)

        by HiThere ( 15173 )

        If you're serious, start by studying the Apple ][ implementation of Prograf. (It died trying to convert to the IBM PC.)

        Whether you call it no code or not is a matter of linguistics. There wasn't any typing, but it was definitely a programming language. The major defect was the amount of screen space (or printout) required to represent even a simple program. The MS PC had a database language that adopted a similar idea, though with more actual typing. But it had the same defect in size of presentation o

        • If you're serious

          I don't know, I'm going to think about it anyway. Try to figure out some contours and boundaries of the problem.

          start by studying the Apple ][ implementation of Prograf.

          I just searched for it, hard to find anything good since there is now a drug with the same name :(

          You could also study Scratch from MIT based on Squeak Smalltalk, or even Squeak's eToys

          I love Scratch and recommend anyone look at it and play with it for a while.

      • Flex and Bison, ISBN-13: 978-0596155971.
        These will get you to a prototype compiler, which you can then use you new language to write your own compiler. Once complete, you have bootstrapped a compiler.

  • Rapid CRUD experimenter here (Score:5, Interesting)

    by Tablizer ( 95088 ) on Sunday April 05, 2020 @07:04PM (#59911492) Journal

    The promise of no-code development platforms has been touted for decades -- is it different this time?

    I hate micromanaging mundane shit in code, and so have been very interested in what used to be called Rapid Application Development (RAD), now often rebranded as "no code".

    The usual drawback of RAD is that it makes the first 80% real easy, but the last 20% a bear. It's hard to get that final customization that makes the app's key parts usable in a practical sense.

    Auto-generated code, a competitor to RAD, may make the initial part of coding easier, but the resultant code is often harder to change down the road when requirements change.

    I've always been interested in data-driven design, in that the schema and related to RDBMS tables specify most of the field attributes (AKA "data dictionary"), menus, and navigation of a typical CRUD app. That way analysts and project managers can control much of that without re-programming. Programmers could then focus on the trickier technical aspects instead of changing field titles, order, and menus.

    The "CASE" movement in the 90's was moving this way, but the products were expensive and proprietary. OOP came along and mostly wiped out table-driven design, viewing the class model as the master domain model instead of the RDBMS schema. This was a mistake. OOP is good for making API's, but not at domain modelling. (CASE stands for Computer Assisted/Aided Software Engineering.)

    But the "customization problem" still remains with table-driven design: things must be tweaked outside of what a table can encode. Table's will only get you about 85% there.

    To get around this, I've been experimenting with "staged rendering" (SR). Under SR, the tables generate a draft structure for forms, menus, etc. and one can tweak the values used for the draft. Pass 1 may only generate attributes. An SR event allows one to change these attributes. Pass 2 generates candidate HTML for elements (fields, menu items, etc.). Pass 3 combines the elements into a "panel" or section, then Pass 4 combines all panels into a page. SR events allow one to override each of these stages as needed. It's kind of like how streams flow into minor rivers, which combine into major rivers, then flow into the ocean. SR improves the granularity of tweaking without littering code with IF statements. (SR can also be used for SQL generation: attributes -> columns -> clauses -> final SQL. Also, more stages than 4 may be appropriate in some cases.)

    The SR experiment is still in progress. Our current IDE's are not very conducive to table-managed/indexed code though, though. They're still stuck in file-land. I think we outgrew file hierarchies for code management, time for relational code management. But I'm finding work-arounds regardless. Stay tuned...

    • The usual drawback of RAD is that it makes the first 80% real easy, but the last 20% a bear. It's hard to get that final customization that makes the app's key parts usable in a practical sense. Auto-generated code, a competitor to RAD, may make the initial part of coding easier, but the resultant code is often harder to change down the road when requirements change.

      I would argue that when auto-generated code has been used as a solution, it is a sign that the functionality should have been encapsulated in a function (or set of functions). That has been my observation at least, that almost any boilerplate code can be reduced to almost nothing by using a well-designed set of functions.

      Whenever I find myself typing boilerplate I think, "Something must be wrong....."

    • That sounds vaguely similar to the way gradle build scripts are put together.

      Spreadsheets, as a concept, have been wildly successful. Due to their low barrier to entry, dig into most business and you'll find evidence of some power user who automated their day job. Resulting in a mess of spreadsheets that the business now depends on.

      I have often wondered if a CRUD type framework could approach the flexibility a spreadsheet, while encouraging good practices that keep everything manageable. Revision control,

      • Re:Rapid CRUD experimenter here (Score:4, Interesting)

        by johannesg ( 664142 ) on Monday April 06, 2020 @03:45AM (#59912404)

        I have often wondered if a CRUD type framework could approach the flexibility a spreadsheet

        I think this problem was solved in the nineties by Powerbuilder. You can point it at a database table (or set of tables) and click the "make CRUD" button - and it is ready to go. Of course after that you can spend some time changing labels, colors, and all sorts of functionality.

        Not saying that Powerbuilder is perfect (far from), but it demonstrated that you could build a CRUD application with very little effort, skill, or knowledge.

        Doing something that was not part of its framework was more problematic, but that's the general weakness of these domain-specific tools.

    • OOP is good for making API's, but not at domain modelling.

      In fact thee is no real difference in modeling a domain in an OOP way or start from tables. Table driven development usually leads to a poorer abstraction level. But often that is good enough.

  • The problem will always be power vs. usability. The more people get into this, the more features they want and the more different problems they will want to solve. The UI grows in complexity and people will find new ways to tie themselves in knots, trying to build large and complex systems.

  • Great! (Score:3)

    by fahrbot-bot ( 874524 ) on Sunday April 05, 2020 @07:19PM (#59911504)

    Anything Java Coders Can Do, No-Code Can Do 200x Faster

    Can't wait to send it to scrum meetings in my place.

  • Cradle to Grave, no-code isn't (Score:5, Interesting)

    by holophrastic ( 221104 ) on Sunday April 05, 2020 @07:23PM (#59911510)

    For this conversation, I'm happy to stipulate that no-code is faster at coding than I am.

    I program all day, everyday, for a living, for myself, for two-and-a-half decades now. I've learned this: my job isn't programming.

    Programming is the easiest part of programming. By the time I know what the client wants, what the client needs, what the client has, and how to connect all of the dots, the programming happens as fast as I can type. I type 100-words a minute on a modified-dvorak, modified-key-placement mechanical keyboard. It doesn't take long to type 1'000 lines of code -- call it twenty minutes.

    The thing about code (good code) is that it's easy to write, once you understand what you want it to do. The translation from logic-to-code is a very straight line for experts. Logic-to-visuals is something else entirely. Code doesn't have an spatial-reasoning efforts.

    And then there's my real job. Changes. Client's business grows (often as a result of having solved whatever problems we programmed away). Now change the code, change the system, to work differently, much differently. Adapt. Evolve. Migrate. Maintain. Add.

    Yeah, I've spent enough time with visual flow charts. The upheaval of major changes is worse than starting from scratch.

    No-code's going to be wonderful. It's going to be wonderful for shitty projects that didn't matter in the first place. It's going to be wonderful for tiny projects that never change. It'll be wonderful for rapid prototypes of new ideas mid-meeting.

    And it'll be terrible. It'll be terrible for experts who hit the wall early, and hard. It'll be terrible the moment there's migration of old functionality, or addition of multiple ways of doing the same thing. It'll be absolutely revolting for reading someone else's "code" -- to be clear, it'll be really easy for simple projects, and impossible for anything beyond a mystery threshold.

    But it'll do something that businesses have always loved. It'll create its own documentation for non-technical people. "We hired a programmer, and he gave us this awesome graphic that we can understand."

    The biggest issue will be the same as always -- it'll benefit non-technical people trying to do technical things that they don't want to do. Which means, like always, they won't do it anyway.

    See the current 3d-printer hype.
    See the century-old woodworking hype.
    See the even older textile hype.
    Or the even older pottery hype.
    Or the ancient cooking recipes hype.

    You've always been able to make your own stuff at home with easy-to-use tools. I have friends who can't boil an egg, shape a hunk of clay, fix the hem on their cushion, nor build a fence.

    You think they're going to start programming now?

    They still can't use a simple spreadsheet, and they definitely can't print double-sided. I promise, they won't be able to 3d-print anything but a trinket either.

    They simply don't want to. Kayaking is my recreational hobby, I'm not interested in constructing my own kayak. I don't even care to wash my sports own car -- swirls be damned.

    • Comment removed based on user account deletion

    • But it'll do something that businesses have always loved. It'll create its own documentation for non-technical people. "We hired a programmer, and he gave us this awesome graphic that we can understand."

      This is a great quote. If customers say that, you know you did good work.

    • I type 100-words a minute on a modified-dvorak, modified-key-placement mechanical keyboard.

      Yes, but the time taken to re-calibrate your espresso machine and precision grind your single estate beans reduce your productivity by a factor of 30 or so so it's all a wash.

      OK with that dig aside(sorry!) yes basically I agree with many points.

      Programming is the easiest part of programming. By the time I know what the client wants, what the client needs, what the client has, and how to connect all of the dots, the p

  • Remember the boast of a rich southerner, "You know, you can start driving the car from one end of my ranch, and drive all day and you could still not reach the other by the evening!"

    The New Yorker cut him down with, "yeah, yeah, I know. I used to own a car like that long time ago.".

    Well, this boast shows how bad Java is, not how great Unqork is

  • Comment removed based on user account deletion

    • Well,
      just to nitpick: your example is a factory. So you write that "word" aka type only once. Having the same factory several times is usually a design mistake.

  • ... future "no code" platforms may be possible but most likely it will be because of 100's of years of research into the brain and translating thought into models. There is this naive idea that translating our thoughts into code is magic, the reality is it's hard work. Most coders know that coding doesn't mean a lot if you don't know anything about the subject area or problem area you are trying to solve. A tool is only as good as the knowledge and skill of it's wielder.

    You can do a lot of easy things w

  • I am a veteran professional software engineer. Java is the easiest and fastest part of my day.

    Lately, there are a bunch of fad programming languages...and while something like Scala or Kotlin may be better than Java, writing code is the easiest part of my day. It someone invented a programming language that was 20x better than Java, it would save
    We've seen CASE, wizards, RAILS/GRAILS, I even wrote a few code generation frameworks myself. There's a reason they haven't taken over the world. They autom
  • Comment removed based on user account deletion

  • ... HR managers search for employees with at least five years experience writing no code.

  • Excel, Labview (Score:4, Interesting)

    by joe_frisch ( 1366229 ) on Sunday April 05, 2020 @08:55PM (#59911678)

    Excel is no=code. You can do a lot of great things with a spreadsheet, I use it a lot. But if you step outside of the types of things it does well, much suffering results .

    Labview does that for science and engineering control systems. Great for the set of problems that match its model, horrible for anything else.

    I don't see anything new here. There have been no-code systems for decades. They work well at the things that they were deigned to do.

    • Labview & Excel [also Libre Office sCalc???] (Score:5, Informative)

      by mosel-saar-ruwer ( 732341 ) on Sunday April 05, 2020 @10:53PM (#59911924)
      Labview does that for science and engineering control systems. Great for the set of problems that match its model, horrible for anything else.

      I was wondering whether LabView counted as "No-Code".

      Because it is Turing Complete.

      Similarly with Visual Basic for Applications [VBA] and Excel.

      If you could just manage to stumble upon the magic combinations of absolutely perfect syntax, then VBA and Excel [in conjunction with an ODBC backend] were an awesome combination.

      But it took a week of scrolling through online developers' forums [plus the associated trial & error of the myriad combinations of competing syntaxes] in order to finally stumble upon that one teeny tiny little piece of absolutely perfect syntax which actually enabled the dadgum Rube Goldberg contraption to function correctly.

      PS: Has anyone ever published a readable introduction to scripting sCalc in LibreOffice?

      I'd love to be able to get something like JavaScript running in sCalc.exe, but I've never found a readable tutorial for it.
  • ... great seen that already, next
  • I worked on this stuff back in the late 80s. We basically generated our code for apps. Fairly powerful, but, unless you have a LARGE number of debugged objects and have ppl with SME, AND the ability to know the objects and how to put them to together, it will not work.
    Some things like simple business set up will likely work well on these. However, there will ALWAYS be a need to be coders to develop those objects.

  • Rapid development environments can take care of what will generally seem to be about 90% of an entire application.

    But that remaining 10% is actually about 90% of the real work.

    1. "No-coding" is still coding. Specify requirements and get results. Call it a new buzzword if you like, but it's effectively the same job (only crappier).
    2. 200x faster means the project is slapped together faster, not that the results are produced faster. You get what you pay for.
    3. The answer to every other question is still "no", especially where the cloud is concerned.

  • OK, real-life challenge (as in this was the second assignment I had at a company): create a shower-room door access control system. It has to integrate with the point-of-sale system so that when someone buys a shower their assigned number/code can be printed on their receipt and their number automatically queued for access. Time from sale to their number appearing in the queue (displayed on monitors around the area) must be no less than 10 seconds. Their number should not be assigned to a room and called u

    • Re: (Score:2)

      by jrumney ( 197329 )

      Does Node Red count as "No code", or does it have to be owned by a cloud computing provider and aimed at Business Intelligence apps to count?

      I think for your use case, Node Red would probably be a good fit. The random code generator would probably best be implemented with some custom code to avoid a spaghetti mess of node logic though.

  • Looked at how the AppSheet no code applications are supposed to be generated.

    Starts with a spread sheet. Column headers are the variable names. You use the predefined "connectors" to link data together. Something like functions in cells. Then you can do what appears to be macros. Presto! Appl

    So it seems to be a macro creation wizard rather than app development.

  • Looked at some Power App. Again not impressed. But if the "no code" tag persuades some Americans to learn this seriously we can replace thousands o H1Bs being hired to do trivial coding in SQL or report generation. So, if it replaces one H1B it is worth it.

  • Looks like the claim is 100% true. For cases where your source data is in an Excel spreadsheet in cloud storage, and you want to make some sort of "enterprise dashboard" out of it, at least. Why would anyone want anything different?

  • It was attempted before and we got Visual Basic. 20 years later we still cannot get rid of it.

  • Since the CPU speed began finally catching up with all the cycles wasted on interpreting bytecode, JIT compilation, and high-level languages compiling to other high-level languages, we now get a platform guaranteed to stress-test every CPU at "Hello World!"

  • There was this one program called Optima++ - 1996 (Score:5, Interesting)

    by passionplay ( 607862 ) on Sunday April 05, 2020 @11:52PM (#59912020)

    It let you code with no code for the default behaviors. The hard stuff you could write in C++ with all sorts of extra bells and whistles. Unfortunately, their product was a direct competitor to something called "DataWindow" from PowerBuilder. So despite Optima++ providing a 4GL facade, it wrote in a 3GL (C++) that ran at the speed of native code written without C++ (thank you Watcom C++). And it was a direct competitor to Sybase's PowerBuilder. So what happned? Sybase bought Watcom and Optima++ and OptimaJ, rolled Optima into working the PowerBuider DataWindow, killed Optima++ and the rest is history. As a part of this fiasco, the Watcom compiler was collateral damage and has not seen the light of day since then.

    Optima++ was SO SMART that it could reinterpret your code and figure out your types - in the 1990's. Since then, nothing has come close to the round-trip engineering possible in Optima++ - they had event viewers that showed you small sections of code like in Lotus Notes, but could also let you edit the whole file like in Visual C++ - it provided intelligent navigation between files like the whole program was an indexed library - before Visual C++ provided it. It was truly a joy to program in. It even had closures back then. It could trace events. Provide full access to the windows internal win32 API at runtime. It could roll back execution. I have yet to see ANY no-code environment provide this level of flexibilty. The easy stuff is easy. The hard stuff as no training wheels these days. Your mileage may vary. I'm not holding my breath.

  • "Anything that No-Code can do, can do it 200x faster than if you did it in java."

    That's what they wanted to say, But that, as the crunchy frogs notice, would lower sales.

  • Is this the year? (Score:4, Funny)

    by backslashdot ( 95548 ) on Monday April 06, 2020 @01:32AM (#59912202)

    It'll happen after Linux finally makes it to the desktop.

  • Low/no-code is the future, no doubt. Maybe not the way this particular company did it, but eventually.

    The idea of not being able to touch the real-actual-source-code seems to bother a lot of programmers, but it's probably better in the long run.

    What I've seen lately is online services for creating phone apps. That is a very limited application domain for the concept, and not representative of what it could be IMO.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Not really. Maybe this stuff can replace excel sheets in some scenarios, but in the end, you need to understand the execution model to get performance and robustness. The main problem I see in enterprise environments is slow applications. When 1000 people have to wait 10 seconds 1000 times a day, that is pretty expensive. Low/no-code will make that worse, especially as single-thread speed advances are basically gone and we may not get much more than another factor of 2 or 3 and that is it.

      So maybe they can

  • If you look at the current programming/development landscape, there is already not much code about it.
    I'm talking specifically about mobile app/enterprise environments ofcourse, which these rad/no-code tools focus on.
    Seriously, just take a look at what the modern stack is made of, it's already mostly drag&drop or duct taping things together.
    And in the case you do make mistakes in the very few lines of code you actually write, there is a boatload of linters and checkers running that will correct the mist

Slashdot Top Deals

One way to make your old car run better is to look up the price of a new model.

Close