[HN Gopher] Ask HN: What do you think about the no-code movement?
___________________________________________________________________
Ask HN: What do you think about the no-code movement?
Hi HN, maybe it's just the bubble I'm in but these days I see a lot
of discussion around "no-code" and the "no-code" movement. There's
also a bunch of new no-code apps being launched every day -
https://www.producthunt.com/topics/no-code#order=trending. Some
seem to supplement developers (eg: retool) and some empower non-
engineers to be able to build websites/apps/integrations without
necessarily having a developer in the loop (eg:
shopify/zapier/airtable). What do you think about this movement?
Clearly these apps/platforms enable non-developers to solve a bunch
of problems which would otherwise need a software engineer. Is this
a paradigm shift?
Author : arrayjumper
Score : 186 points
Date : 2021-11-11 14:47 UTC (8 hours ago)
| donatj wrote:
| While I certainly saw them coming a mile away, the rise of sites
| like Squarespace and Wix still unnerves me a little bit.
|
| While I do primarily backend data work these days, I spent a lot
| of the early 2000's working for an agency that built websites for
| people and companies. Many of which would have been simple enough
| to throw together in Squarespace.
|
| I'd always thought I could fall back into building websites if
| this didn't work out, but I feel like that's falling out as my
| backup plan. I still try to keep up on CSS and JS though, just
| incase.
| jamil7 wrote:
| I see it as kind of comforting. These tools take care of the
| cookie-cutter projects so developers can work on more
| interesting things.
| zzznilzzz wrote:
| I feel you.
|
| I freelanced designing and building websites in the '00s before
| gradually migrating into in-house creative direction and
| product design. After getting burned out doing that, I've tried
| to start a little solo web and brand shop again, which sounds
| fun on paper, but I can't find a market for it. People just
| want inexpensive Squarespace editors. They look to Fiverr,
| Upwork, etc.
|
| It reminds me of the Wordpress-only shops that drove me to in-
| house/product design in the first place, but with even less
| custom work being done.
|
| It's a loss for web as a creative platform, and has left me
| unsure of how to proceed professionally.
| tablespoon wrote:
| > Is this a paradigm shift?
|
| No. IIRC, companies have been hyping stuff like this for
| literally 40 years:
| https://en.wikipedia.org/wiki/The_Last_One_(software)
| markus_zhang wrote:
| I don't like the idea, not because it doesn't work. It might, but
| in the mean time I lose ownership to my own code and tools. My
| code and tools might be shit, but at least they are well
| documented and I know how shit works. I prefer to play with my
| own shit than someone else's, if possible.
|
| You may ask why then I don't write my own OS/IDE/Database/etc.,
| well I'd love to but sadly I don't have the skills. I only do
| things within the boundary of my skills.
|
| Sorry, ownership is No.1 issue for me.
| gennarro wrote:
| I've been pretty unimpressed with the results to be honest. There
| has been a lot of hype around businesses that have little value-
| add and lots of great marketing.
|
| I love the concept -- quickly spin up an MVP, etc -- but when so
| much of success lies on execution and so many good ideas need
| time to be perfected before they commercially viable spinning up
| things very quickly isn't always the best.
| d0mine wrote:
| Good examples of no-code (relative to the things they replace
| because a good no-code solution degrades gracefully into
| code/abstraction it replaces for complex cases):
|
| - spreadsheets :: textbook example
|
| - OS/file systems :: it is hard to imagine times without it, when
| these operations had to be programmed manually
|
| - relational DBs/SQL :: compared to myriads of ways data
| manipulation was programmed previously
|
| - shell pipeline :: compared to manipulating processes directly
| in C. People can be tricked into writing useful shell commands
| without thinking about themselves as programmers.
|
| There are many [less general] domain-specific examples such as
| GraphEdit, GUI/web-site builders, yahoo pipes, labview, etc.
|
| Declarative configs for various things (even if they literally
| called "code" can be also considered no-code solutions e.g.,
| IAAC) or various DSLs that discourage the general code with
| loops/ifs (even if it is Turing complete formally).
| a_lost_needle wrote:
| I'm in the process of doing a technical audit of several of these
| for a government. My favourite so far is the ServiceNow platform.
|
| These platforms are great at making use of bottom tier devs quite
| effectively. They're a resource amplifier, when you don't have
| the cash to hire better devs. Hire a few devs to create the
| custom controls, actions, etc.. and have a boat load of juniors
| implement the requirements. Most of these folk haven't picked up
| a new language since college, and don't incorporate coding into
| their lives. These individuals have value, but often create more
| problems due to their lack of skill and/or experience. In a
| low/no code environment, you can better ensure that they're on
| rails.
|
| The issues we're encountering is the pricing model, and it's most
| likely we'll end up going with Microsoft's because of the
| existing contracts. ServiceNow for all it's strengths really
| shoots itself in the foot with pricing. A product like this
| benefits from any "power" user being able to implement their own
| internal workflows, but ServiceNow charges per dev. So they're
| handicapping themselves. But someone will figure out all the
| pieces, it's inevitable.
|
| As a means to solve boring, repetitive, uninspired development,
| it's great, and it'll be the future in the way that SquareSpace
| and Wix ate into front end presence sites...
|
| And honestly, if you aren't a great developer, I suspect the
| rails would make you feel a lot better.
|
| This won't take any jobs from anyone likely reading this. HN
| frequently has a blind spot for that vast majority of enterprise
| development. It's not sexy, but it makes up more developers than
| the Silicon Valley crowd by magnitudes. And most of them would
| fail a Fizz Buzz. With no code, I can make use of those
| resources.
| [deleted]
| codegeek wrote:
| It is mostly just repurposing older stuff in my opinion to make
| it sound cooler and make it the new fad. You know what the
| biggest no code tool is ? WordPress. Tell me why it is different
| than the shiny new no code tools.
| rkagerer wrote:
| Been there, done that, wasn't long before I wanted back more
| powerful syntax tools.
| dagw wrote:
| I have a relative who's been programming since forever (although
| he would never call himself a programmer), and he talks about the
| first time he saw FORTRAN IV. Finally there was a language where
| you didn't have to be a programmer or know about computers to
| use. You just typed in what you wanted the computer to do and it
| did it. You could solve your own problems without having to wait
| for the programmers to do it for you. So clearly the desire to
| get "programming" out of the exclusive domain of programmers is
| hardly a new thing.
| meheleventyone wrote:
| It's weird from the perspective of game development because it's
| so obvious. A lot of time is spent on development tools because
| making a modern game is a very complex undertaking that is highly
| data-driven. A large amount of game tools are #nocode not because
| it's a movement but because it's useful. A classic example is
| level design tools that are much more about spatial design with
| some coupling between entities in a game. Non-programmers can get
| really far and build some surprising diverse things with simple
| primitives.
|
| As an example our Art Director built this without any programmer
| assistance or writing a line of code. Just taking a basic
| multiplayer FPS game then grabbing components we had already made
| and jamming them together to get parts working:
| https://twitter.com/voxeleus/status/1437754413813207047/vide...
|
| You can further see this in many creative games or games with
| modding tools where players put together complex behavior without
| using a line of code. Right up to things like Minecraft Redstone
| which is really an esoteric, spatial programming language. But
| crucially doesn't feel much like programming at all.
|
| I think there's a lot to be taken from the game space for people
| trying to build no-code tools. Particularly in that you're not
| trying to remove a programmer but empower non-programmers in ways
| that suit them.
| redisman wrote:
| I feel like there is a distinction between tools and no code
| and these are just tools. You can maybe prototype a game
| mechanic if it's not very unique with drag and drop but it'll
| never scale to production. By the end the game code will have
| thousands of special cases which would make the nice no code
| experience a complete Frankenstein monster
| jrochkind1 wrote:
| > I feel like there is a distinction between tools and no
| code and these are just tools.
|
| How would you describe the difference?
| meheleventyone wrote:
| > I feel like there is a distinction between tools and no
| code and these are just tools.
|
| Programming is just a tool as well... there's a odd
| distinction here that somehow more specific tools are lesser.
| I also think this is where the whole #nocode thing can go
| wrong. You should empower non-programmers in ways that suit
| them.
|
| > You can maybe prototype a game mechanic if it's not very
| unique with drag and drop but it'll never scale to
| production.
|
| The expressiveness of composition is only limited by the
| number of elements you have to compose. In the specific
| zombie case no it wouldn't scale to production. But then the
| prototype wasn't meant to and also would never have existed
| if it weren't for these tools. We unlocked the ability for
| our Art Director to prototype a new game all by themselves.
| That's massive from a creativity point of view. We'll almost
| certainly turn it into a full game at some point.
|
| From a production standpoint a game is thousands of special
| data cases. Which is why tools are so important and code is
| both data and a tool but if you can simplify things so much
| the better.
| sparsely wrote:
| It's vastly better than previous iterations on the same idea.
| Some (e.g. Airtable) are much better than others, perhaps because
| they have a clearer niche. Others are useful but drive you
| straight into a swamp called Technical Debt (retool). I don't
| think they represent a paradigm shift, more an iterative
| improvement on existing tools.
| z5h wrote:
| Code is simply a way we formalize requirements to the specificity
| required for a computer to fulfill and honor them. So a
| developer's job is to make vague requirements more specific via
| the coding process. Find another way of moving to an equivalent
| representation of every detail captured in code, and call it
| anything you like.
| 015a wrote:
| In my experience, these tools are sometimes a fantastic option
| for developers to alleviate some of the burden of managing
| infrastructure and code. But I've rarely seen a powerful solution
| which can be used by non-developers; either because the tool is
| powerful, but complex, and thus the same skillset it takes to be
| a developer ends up being necessary to interface with the tool,
| or because the tool is integrating with systems/APIs developers
| wrote, and it takes a developer to understand how to handle that
| interface.
|
| But I think they're really cool none-the-less, as a developer. I
| can build a modern react web application with the best of them,
| but I still pay for a squarespace personal site. At work, we use
| a ton of zapier and retool; when the problem space fits, its just
| less dev work. But the devs are the ones who do maintain it, at
| the end of the day.
| prepend wrote:
| I think there's "good" no code and "bad."
|
| Bad is where there's only no code and it's impossible to drill
| down. Or use outside of a walled garden.
|
| Good is when the end product is portable and can be worked on
| outside the tool.
|
| I think the problem comes when noncoders hit a wall and can't go
| any further.
| zemo wrote:
| I think people want "no-code" solutions because they're
| intimidated by code. I think they're intimidated by code because
| they're intimidated by programming culture. If a large number of
| people outside of programming are intimidated by programming
| culture then it is by definition intimidating.
|
| If programming was instead seen to be a welcoming, warm, and
| supportive culture, I don't think no-code would have very much
| persuasive power. The effectiveness of no-code as a brand should
| cause more people in programming to pause and consider the fact
| that the value proposition is _not having to deal with
| programmers_. People _literally_ sell products on the basis of
| not having to interact with our community. That should cause us
| great concern about the health of our community and should
| trigger introspection.
| b20000 wrote:
| every so many years this movement comes back and has a different
| name. I think I've now seen 5 iterations of it over the last 25
| years. back when frontpage was first launched everyone screamed
| it would be the end of web development and everyone and your mom
| would build websites and we wouldn't need those cranky developers
| anymore. and here we are.
| vaughan wrote:
| I think coding and no-coding should eventually converge.
|
| Software development has become far too complex without the right
| sensible abstractions keeping things under control.
|
| Every developer would probably want an Airtable control to drop
| into their app, that they can use to build up their schema and
| then add custom functionality. But there isn't one. I think
| mostly because there were too many technologies coming along at
| such a rapid pace that integrating became difficult because
| everyone is using a different tech stack and changing tech stacks
| all the time. And there are new libraries to do everything. E.g.
| No one uses Redux anymore. Graphql came along. Everyone is back
| on SQL. And what's next?
|
| The pace of tech needs to settle down and then we can build some
| solid reusable libraries that do the same thing as no code tools.
| edsonmedina wrote:
| no-comment
| fitzn wrote:
| I _do_ think it 's a major shift but not in a mutually exclusive
| way, and maybe not a "paradigm" shift. I think initially, no-code
| tools were touted as being for non-developers. But now there is a
| realization that no-code tools are more like "automation" for
| completing a task. In that mindset, anyone (developer or not) can
| benefit from using them since it can be/should be/is more
| efficient. To the extent that no-code tools let a non-developer
| build and test an end-to-end app as their business, I think
| that's rare today but I would say we're on our way towards it.
|
| I liken the no-code movement to the introduction of a higher-
| level programming language. For certain tasks, the higher-level
| language is more than adequate and a developer (or user) who
| knows nothing about OSes, file systems or networking, can build
| an application and probably create value and make money. But the
| higher-level language doesn't replace the lower-level language
| overnight, and for certain tasks it'll never replace it.
|
| To use the example you mentioned, if you just want to display a
| webpage for your co-workers that lets them filter a SQL table, it
| might take you a few minutes to build that in Retool. If there is
| a class of such webpages or webapps that could make you money,
| then it's easy to see Retool as a new higher-level language for
| building those types of apps.
|
| So, my view is that it's not a paradigm shift for building
| software, but rather the next step on an evolution towards a more
| automated process of building software.
|
| Disclosure: I founded a no-code web testing app
| https://reflect.run
| mkl95 wrote:
| It makes sense to employ simple tools for simple problems. The
| world is full of overengineered software.
|
| However, my suspicion is that for sufficiently complicated and
| niche projects, the cost of building a no-code tool that can
| build them far outweighs the cost of writing good old code.
| boringg wrote:
| No code feels to me like an ORM like django. Conceptually easier
| but theres a ton of stuff done in the background that as soon as
| you want anything special you end up in a world of hurt.
| leephillips wrote:
| Except in Django it doesn't hurt, because the ability to send
| straight SQL to the DB is built in.
| Stranger43 wrote:
| The first successful no-code platform(VisiCalc) came out in 1979
| so calling it a new movement or innovation is just people being
| ignorant about the past.
|
| In essence this is an old Idea that have been on the cusp of
| making the professional application developer obsolete since
| COBOL was invented back in 1959.
|
| There is a cyclic nature to this and at i don't see any real
| difference in this generation of tools then something like SAP
| ABAP in that it will not also develop into a new sub-
| specialization that Leeds to an increase in the need for full
| time programmers.
| ineedasername wrote:
| Seems okay to me, it's just one more layer of abstraction higher
| up the chain.
|
| The _organizational problem_ is controlling ad hoc app
| proliferation by non development units and thereby creating
| unsupported shadow systems. So, when used by dev teams I see no
| problem, but usage by operational units should be highly policed.
| kitd wrote:
| _Seems okay to me, it 's just one more layer of abstraction
| higher up the chain._
|
| Exactly.
|
| C++ is no-code if you work in x86 assembler.
| goertzen wrote:
| Not a paradigm shift.
| albeebe1 wrote:
| I think what we're seeing is what we've always seen. That is, we
| start at the lowest levels and continuously work towards a higher
| and higher level. Constantly making the development process more
| efficient. No-code solves a problem, but it's not a panacea.
|
| The movement i'm most interested in as a backend developer is the
| no-software movement.
|
| The idea that the entire process of developing and deploying
| services can take place in the browser. Why install an IDE when i
| can just code in a browser. Why install git when i can press a
| button in the browser and have it handled in the cloud. Why run
| the code locally when i can run it in the cloud and stream the
| output to the browser. Why install a bunch of software and
| configure everything to work on my machine, when it can all be
| handled in the cloud and interfaced via the browser.
| gmonk wrote:
| "No-code" and "Low-code" - it's all still code, just someone
| else's that you don't control.
| mabbo wrote:
| I don't see the 'no-code' movement as something new, just a new
| name on the same idea. Developers are expensive, so let's migrate
| this work to people who cost less, using tools that provide the
| same or similar value.
|
| Do you know how many people's jobs today are "this person is
| really good with excel, so we can hold on hiring a dev team and
| data scientist"? Probably millions. They're everywhere. I met
| dozens of them hidden away in Amazon warehouses during my career
| there. And Excel is the ultimate 'no-code' tool, pinnacle of the
| industry.
|
| And yet the developers, we're all still here. Frankly, there's
| more of us. Because what really happens when you don't need
| developers to do the simple stuff is that developers can instead
| focus on the hard, higher-value problems, that a no-code solution
| can't do for you. More gets done, more value gets created.
|
| There's always talk that eventually, we'll reach the end of the
| runway and the no-code will replace are large portion of us. I
| don't think we're anywhere near that. So bring on your no-code
| products, I say.
| bitwize wrote:
| Standard rants:
|
| 1) Every symbolic or visual representation of a command or
| control flow structure in a no-code tool is isomorphic to some
| construct in a programming language, just more cumbersome to
| author and manage, especially at scale. Therefore, users of no-
| code tools are programmers; they engage in programming when using
| the tool to define some process.
|
| 2) Programming with text can be done with a variety of tools,
| from full-fledged IDEs to Notepad. Programming with a graphical
| representation can be done only with tools that render that
| representation (usually, proprietary tools from the no-code tool
| vendor).
|
| 3) Text is more amenable to being diffed, transformed, and
| version-controlled than are visual representations.
|
| 4) Visual representations have a low complexity threshold beyond
| which they simply become unmanageable. It doesn't take long to
| clutter the screen and make it difficult to find what you are
| looking for and manipulate it. Some sort of normalizing or
| beautifying feature for the program control graph, as well as a
| search feature, may be added, but these are necessarily more
| complicated than their text-based equivalents.
|
| 5) It's much easier to simply type in what you want the computer
| to do than to engage in prolonged rat wrestling to construct a
| representation of the procedure to be followed.
|
| 6) No-code is circumscribed: If you are writing something the no-
| code tool author anticipated, you will be fine, If you are
| writing something the no-code tool author didn't anticipate, good
| frigging luck.
|
| 7) We've been sold this snake oil time and time again. It was
| CASE tools in the 90s. In the 2000s, we were literally told that
| programmers would be made obsolete by the emergence of UML to
| program conversion tools. (I had a professor who said as much,
| almost in so many words.) It never takes because with the
| complexity of real-world software, it becomes an ergonomic
| nightmare.
|
| 8) No-code is intended for two main audiences: as didactic tools
| for children or the barest of beginners, and as production tools
| for dilettantes who want to program without putting in the effort
| or assuming the stigma that professional programmers do. In a
| production environment, the output of these dilettantes will be
| abandoned by the dilettantes themselves, who aspire to grander
| things like marketing, management, or finance; and will instead
| have to be maintained by... professional software developers, who
| will curse the original authors' names forever -- thus nullifying
| one of the touted advantages of no-code to organizations: that
| you get the benefits of custom programming without having to hire
| programmers.
|
| In short, in order to think of things more snake-oil than no-
| code, I have to go to the old standbys of medical pseudoscience
| and multi-level marketing products. I can see no-code used as a
| crutch by those who are new to programming and afraid to approach
| it, but they would perhaps be better served by using something
| that involves code, but tricks them into believing that what
| they're doing is not programming, thus alleviating their
| "programming anxiety". Secretaries were successfully trained to
| write rather elaborate Emacs Lisp on Multics Emacs back in the
| 1970s -- simply because they were told that in so doing they were
| simply _customizing_ their editor, not _programming_ it!
| jerf wrote:
| It's interesting, but always calibrate their claims against the
| fact this is about the tenth time this movement has come around.
| This movement literally goes back to COBOL. That is not a typo.
| It's not only likely older than you are, but probably _much_
| older than you are.
|
| I recognize COBOL may not seem like "no-code", but that's just
| because "no-code" is a stupid label. "No-code" doesn't mean "no
| code" just like "serverless" still runs on a server.
|
| I would say the main problem with the no-code hype is the idea
| that it is a leader. It is not. It is a follower. "Normal" code
| goes out, hammers things out over the course of literally
| decades, and then, when it has finally settled what the best
| couple of ways to do something is, it's finally time for the "no
| code" solutions to come in and systematize that for a larger
| audience. Nothing wrong with that. Power to the people and all
| that.
|
| It just goes wrong when no-code advocates put the cart in front
| of the horse and make grandiose claims about replacing all
| developers or something. That's not the direction the stream
| flows in. No-code can't operate without the "normal" developers
| doing immense amounts of work charting the territory and building
| the infrastructure to get there. There is no chance of them
| displacing "normal" software developers; they are structurally
| incapable of it. Woe unto the no-code startup that doesn't
| understanding this dynamic, and foolishly tries.
| henrikschroder wrote:
| The first time I encountered something that called itself "no-
| code" was when the internet portal I worked for (Remember
| those?) decided to offer a "webpage builder" for its users. I
| didn't work on it, but just looking at the limited webpages you
| could build with it, how all of those were basically just our
| best practices, and how the amount of code needed to support
| the builder was just _massive_ compared to the code it
| generated, it was pretty clear to me that my job security wasn
| 't threatened.
|
| Every single solution like this has an edge, a limitation, and
| when you reach that edge, the answer is always "well, you can
| edit the code directly if you know what you're doing..."
|
| It's exactly as you say, every solution like this can do the
| already mapped parts of programming, but they are fundamentally
| incapable of being used for the unmapped parts, the woods, the
| edges, the limits.
| marmaduke wrote:
| This seems true until one can generate code based on
| descriptions like GH Copilot can do. That's a step towards
| structurally capable.
| cabalamat wrote:
| > It just goes wrong when no-code advocates put the cart in
| front of the horse and make grandiose claims about replacing
| all developers or something
|
| "no code" like most IT industry buzzwords over the last 70
| years, is mostly bullshit but with a kernel of useful truth.
| mountain_peak wrote:
| My first job out of university was working with a very large
| firm that bought into Computer Associates' product suite -
| including 4GL code generators such as Telon ("green-screen"
| generators) and Easytrieve (4GL report generators). From what I
| recall, we spent 90% of our time trying to work around the code
| generators to accomplish tasks, as opposed to simply using
| native CICS, which was difficult to master (hence the 4GL).
| I've since used a number of 4GL-type tools, and they've all had
| the same limitation in that the tail wags the dog, to use an
| old idiom. Quite fast and seemingly magical if you stay within
| the guardrails, but as soon as you veer off course (and unless
| you don't want any differentiators, you will) they quickly
| become far more onerous than hand-coding, plus lock you into
| their 'forced march': cost, upgrades, incompatibilities, and so
| on.
|
| As an aside, it was a very interesting time to be a developer
| as we had a mix of youngsters (me), who were raised on personal
| computers, many people seasoned on mainframes/mid-range
| computers, plus a few "old-timers" who started coding in the
| 1950s without any formal training. Everyone had great stories,
| and I feel lucky to have been exposed to people firsthand who
| were some of the first programmers (and they universally
| thought everything above assembly language was 'cheating').
| Their stories and perspectives have stayed with me throughout
| my career.
| coldcode wrote:
| I knew a team that did 4GL on AS/400s (generating RP4 I
| think) and they were all about how superior their tool was
| and how terrible the Java team was in comparison and how they
| would never be out of a job. Within a couple years none were
| programmers any more as their tool was abandoned and they had
| no other programming skill.
| ndm000 wrote:
| Completely agree, and it makes me wonder if we are at the edge
| of standardization for many types of applications. The desktop,
| tablet, and mobile form factors and use cases are well
| understood. Best practices amongst these major platforms are in
| place. The cloud is maturing (litmus test for this is the
| reinvent seems to be less exciting each year). New form
| factors, like AR/VR, don't have the market share for broad
| changes to development practices yet.
| AnimalMuppet wrote:
| COBOL. SQL. HyperCard. Visual Basic. Spreadsheets. Yeah, same
| song, next verse.
|
| In some ways it's like AI, though. Once it succeeds (at what it
| can do), then it no longer is "no code", it's just it's own
| niche. (We don't think of SQL or spreadsheets as "no code" any
| more; we think of them as their own categories.)
|
| I mean, spreadsheets are not nothing. They're useful for a
| segment of things. They didn't replace web programming or
| embedded real-time or machine learning, though.
| ethbr0 wrote:
| Things we agree on: ignore everything no-code proponents say
| about their tools or capabilities
|
| Things we disagree on: code before no code
|
| My experience has been that actual code is always superior* to
| no-code, because no-code is always more complex. E.g. the no-
| code developer environment + code (in whatever designer form) +
| interpreter / runtime / libraries + any integrations + actual
| generated code.
|
| Consequently, business critical functions should be in actual
| code, if it's an option.
|
| So where and why to use no-code?
|
| As a prototyping tool, no-code before code, because it inverts
| the pyramid (few developers, many users) by making users into
| prototyping developers, and it makes the best use of scarce
| resources (code developer time).
|
| No-code written by users allows you to waste user time figuring
| out all the things that are typically missing in a business
| spec, without wasting developer time. Then, when they've
| figured out _exactly_ what they want (because it works!),
| developers can come back and do exactly that.
|
| This usually involves throwing away the no-code model when
| coding, because it's probably not going to be architected well,
| but does provide a concrete, tested, proven spec.
|
| So essentially, the company gets version 2 of the code, at the
| cost of 1x user time + 1x developer time. Instead of version 2
| of the code, in 2x developer time, which is too expensive and
| never happens.
|
| * From a TCO, maintenance and reliability standpoint
| rizz0 wrote:
| >So essentially, the company gets version 2 of the code, at
| the cost of 1x user time + 1x developer time. Instead of
| version 2 of the code, in 2x developer time, which is too
| expensive and never happens.
|
| Not sure why, but in my experience the difference has been
| closer to 1x user time + 1x developer time <> 4x developer
| time.
|
| I believe empowering a customer to think along -- be pushed
| to their limits, even -- within the boundaries of a system's
| technical/business domain _from the very start_ is likely to
| dramatically improve a system's design.
|
| From a technical perspective it may not be architected well,
| but in terms of user <> business fit it probably will be.
| sam0x17 wrote:
| > My experience has been that actual code is always superior*
| to no-code, because no-code is always more complex
|
| Yes, usually an order of magnitude more complex, even.
| mdpye wrote:
| I suspect you are talking at cross purposes. You are
| suggesting no-code first on a micro timescale. For
| prototyping. That seems like a solid suggestion and use of
| resources.
|
| But from the GP, I read a statement on the macro scale. No-
| code can't codify turn-key pluggable building blocks until
| the problem spaces of those blocks have been thoroughly
| explored by code solutions, and a small number of "winning"
| configurations identified.
|
| Sure, those blocks can be plugged together to prototype
| "novel" line of business "problems", but I think there's a
| disconnect in the kind of problem spaces you are talking
| about.
|
| The "solved" problems that the no-code widgets represent
| still need to be solved by code first. And expectations
| continue to move.
| ethbr0 wrote:
| We have a different definition of no-code, I think. I
| wasn't including any tools that don't offer generic enough
| primitives to build an arbitrary business process.
|
| If we're reducing no-code to "things that have been written
| in code first, that can then be plugged together by the no-
| code user", then we're talking about libraries with a
| visual designer on top.
| wonderwonder wrote:
| I used to think this as well, that No Code was not a real
| development to production level option. I have very much been
| proven wrong. I transition recently from 15+ years as a
| developer to contracting for a no code platform. Virtually
| everything a regular web dev can do in code can be done in no
| code. Sometimes its easier to do in code and sometimes it is
| much easier to do in no code so mileage may vary but no code
| is very much a mature technology now that can produce
| applications to the same scale as regular web 2.0 coded
| software.
| AnimalMuppet wrote:
| OK, but web development is an area that jerf would probably
| classify as "solved".
| jrochkind1 wrote:
| > no code is very much a mature technology now
|
| How is "no code" a technology? Aren't there a variety of
| "no code" technologies?
|
| I'd be interested to hear which ones you are seeing that
| can produce applications similar to ordinary software
| development! Like... it's probably not WordPress or
| SharePoint.
| ethbr0 wrote:
| I've been consulting in no-code platforms, in addition to
| writing actual code, for about 8 years. Producing something
| that works isn't the problem.
|
| Maintaining it is.
|
| The legacy codebases from this stuff are dumpster fires,
| because most of the tools are closed enough ecosystems that
| the companies supporting them have to reinvent every
| programming best practice from the last 30 years.
|
| 'Version control? Sure, that's a feature on our roadmap
| that we'll get to at some point...'
|
| In addition to going back to the bad old days of limited-
| use, proprietary compiler problems. 'Oh, that bug? Yeah,
| just don't do that.'
|
| Furthermore, unless you choose very carefully, you're
| playing right into vendor lock-in, and a lot of the people
| buying this stuff aren't technically proficient enough to
| realize that.
|
| Once these companies hit the end of the easy growth ramp,
| and the industry turns into monetizing & squeezing existing
| customers, there's going to be migration pain on an Oracle
| scale.
| andrewstuart wrote:
| COBOL is code - it's not nocode.
| pjc50 wrote:
| By the standards of the time when even macro assemblers
| weren't always available and programmers often had to do the
| translation to machine _code_ manually, it was unlike code.
| It was even portable!
| tejtm wrote:
| Have you met assembly?
| brazzy wrote:
| It was sold as "basically English, so programmers are
| obsolete since everyone can write their own software". Which
| is pretty much the same pipe dream as "no code".
| monocasa wrote:
| Yeah, if you look at it, it's designed after recipes, even
| more so than typical programming. It starts with a title of
| the module, then a data definition section (ingredients),
| and the the program section which is a numbered list of
| english phrases to be performed more or less in order.
|
| The idea was to convert women who had been working _as_
| computers, into programmers.
| LisaDziuba wrote:
| I can say from our experience: we made more that 2000+ no code
| projects so far and it really required some customization, some
| coding and technical understanding from "no code developers".
|
| No code operates together WITH normal developers. At
| WeLoveNoCode (https://welovenocode.com/) we have mix of no
| coders who knows design, no code tools but also can dive into
| code. So it's not like isolated function, no code is an
| instrument to build something faster with visual editors.
| Agree?
|
| Also, why see no code as a "competitor" or something completely
| different? Wix or WordPress was around for a while and only
| until recently "every" tools decided to call themselves as "no
| code" :) I mean, it was there for a long time already...
| kodjima33 wrote:
| Did you have any cases when devs collaborate with no-code
| devs?
| Mountain_Skies wrote:
| I remember articles early on during the release of SQL that
| promoted it as a way to reduce the need for programmers because
| it would allow managers to access all the data they wanted
| through natural language. Things didn't really turn out that
| way.
| hluska wrote:
| I took a course in COBOL when I was in Unversity. The
| professor was in industry but taught one night class a
| semester.
|
| He started the class by talking about how when he learned
| COBOL, they told him this would make developers obsolete
| because it would let managers build their own solution. In
| his experience, it made developers even more valuable because
| "give a manager five minutes with a codebase, give a
| developer a job for five years cleaning the mess up."
| fitzn wrote:
| I totally agree, and this jives with my feeling that no-code is
| an evolution or a codification of the best practices and
| principles "hammered out" as you say over the years by regular
| software development.
| annoyingnoob wrote:
| I've used Microsoft's tools, like the Power platform and Logic
| Apps. For anything interesting you want to do it boils down to
| Excel-like functions. Have you ever worked with a series of
| nested If statements in Excel? Its kind of a nightmare to think
| about and there is definitely code there.
|
| If you want to do something really really basic its fine. If you
| want to do something complicated then its a hinderance.
| dirtybirdnj wrote:
| I'm a backend focused engineer that's worked on PHP and
| Javascript API / apps. In the past I had to write a lot of
| boilerplate code, now things like Strapi make it super easy to
| prototype data models and give you authenticated APIs for very
| little effort.
|
| I'm a huge fan of Plasmic so far, I've tried to make frontend
| react sites and they don't look as nice as what I'm able to
| achieve with what I can only call a "website builder" tool.
|
| My goal is to customize the CMS and use it as an API for a
| separate frontend site. JAMStack is the future... I don't think
| there is anything specifically 'no-code' about it but I'm
| suggesting two tools here that let you do no-code and also have
| nice doorhandles to let you get under the hood. I think that last
| part is key.
| a4isms wrote:
| The "no code" and "low code" movements come up over and over
| again because programming is now like writing: Yes, it is its own
| profession, but also yes, it permeates all other professions as
| software eats the world.
|
| Languages and tools are user interfaces, and any time you have
| many different jobs to be done by many different people with many
| different contexts, it is natural to develop several different
| interfaces for what may appear to be the same work.
|
| Thus, low-code and no-code. But!
|
| Programming is more than just coding. It's also all the
| activities AROUND the coding, including things like reviewing
| code before it is deployed, version control, reverting code,
| testing code, automated tests that also serve as DSLs for
| describing the behaviour of code, &c.
|
| Robust no-code or low-code systems also need to address the needs
| that the systems and tooling that live around high-code serve.
|
| They don't need to do these things the exact same way, but it's a
| Chesterton's Fence situation: We shouldn't just ignore those
| other systems, we should figure out why they exist and make sure
| that either we know those needs no longer exist, or address them
| another way.
|
| https://raganwald.com/2012/01/08/duck-programming.html
|
| Discussion around the original post:
|
| https://news.ycombinator.com/item?id=3442419
| ghiculescu wrote:
| The best no code tools empower non-developers (and are thus
| poorly understood by HN). You've named some good examples.
|
| In my B2B saas company we massively increased customer
| satisfaction by making it easy to integrate with retool and
| metabase and then letting anyone internal or external extend the
| product with new views and functionality.
| ChrisArchitect wrote:
| Maybe ask some of these people:
|
| _1 hour before you_ Ask HN: Do you like the term 'nocode'?
| https://news.ycombinator.com/item?id=29187754
|
| _2 days ago_ Ask HN: No Code GUI Tools?
| https://news.ycombinator.com/item?id=29160858
|
| _3 months ago_ Ask HN: Is there any future for low-code /no-code
| development? https://news.ycombinator.com/item?id=28150056
|
| _4 months ago_ Ask HN: Anyone built a business with no-code
| tools? https://news.ycombinator.com/item?id=27593073
|
| _3 months ago_ Ask HN: What do you think of Producthunt 's
| obsession with no-code solutions?
| https://news.ycombinator.com/item?id=28194430
| arrayjumper wrote:
| Thanks for posting these. I did see these threads before
| posting this Ask HN. However in most of those threads there
| wasn't much discussion at all.
|
| I'm finding the comments in the current thread quite enriching
| to be honest.
| scrubs wrote:
| Ouch! Ok, somebody came ready to rock-n-roll on questions.
| Originally I read, for example, "4 months ago" instead as "4
| months before asking HN [see link here]" as in don't ask
| answered questions!
| santiagobasulto wrote:
| We have to start doing like those Soccer Mom Facebook groups
| and put something like: "please use the magnifier glass[0] to
| search if your question hasn't been asked before"
|
| [0] https://hn.algolia.com/
|
| Edit: I'm getting heavily downvoted. Sorry guys, it was just a
| joke.
| k__ wrote:
| Isn't this what software development is all about?
|
| We make tech more accessible for people who can't code and then
| we move to the next thing.
|
| I saw a bunch of freelancers fail, because they had the
| impression they could sell people basic homepages as a job for
| their whole life...
| jlarocco wrote:
| I think it's great to see the commoditization of solved problems.
|
| On the other hand, I'm not surprised to see developers hating on
| the idea because our industry has spent decades telling everybody
| these are difficult problems and they need to hire experts to
| help solve them.
| nicebill8 wrote:
| As a programmer, I've got a love for code but I have to accept
| that this is going to be the future for 90% of consumer-facing
| apps. The most common abstractions for the most common use-cases
| are already built and they're going to stay that way in my
| opinion. Once the "hard thinking" work is done building these
| abstractions, it's just a matter of connecting the dots to bring
| a product to market in <insert industry of choice>. While there's
| been no-code tools for a long time (Yahoo pipes being my earliest
| memory) there's no doubt they're improving every day.
|
| I think in a few years (decades?), "developer" and "programmer"
| will mean something very different that they do today.
| dagw wrote:
| I'm a programmer who does a lot of "no code" development and
| find those tools very productive for many of the problems I
| deal with. And I observe every day the people who know
| "programming" can use those tools far more effectively and come
| up with far better solutions and solve far harder problems than
| the people who cannot program, but just learned the tool.
|
| The hard part of programming is computational thinking, and
| coming up with novel ways to string the right algorithms
| together to get the result the client needs, not typing vs
| dragging and dropping.
| Alex_Bell wrote:
| """ I think in a few years (decades?), "developer" and
| "programmer" will mean something very different that they do
| today.""" Hello. Your opinion is very interesting. And can you
| tell your version of this in more detail.
| ThalesX wrote:
| God I'd love it so much if 'idea people' could use some sort of
| no-code tool to get their idea 80% of the way there, so I can
| start cracking on the remaining 20%, or even not at all.
|
| This would really clear me up for valuable work instead of having
| to rehash the same quick fixes for broken data modeling paterns.
| thrower123 wrote:
| It's always been a pipe dream. I wish that people would invest
| more into making decent real SDKs for full developers to use
| instead of chasing this fantasy that you're going to be able to
| solve all your problems by gluing pre-made lego blocks together.
|
| What invariably happens is that somebody gets a bee in their ear
| about some silver-bullet low-code tool, and tries to use it. They
| maybe get a few simple work-flows to work. Then they try to start
| doing more complex things, and it falls apart rapidly. Then more
| requirements are foisted onto the low-code platform, and
| developers get dragged in to try to build integrations into it
| and new custom components for it. Usually this is unbelievably
| awful to do.
|
| Eventually you have developers having to maintain this awful Rube
| Goldberg machine of crap that they didn't want to be involved in,
| tmilard wrote:
| Software == a NO-CODE tool
| vikR0001 wrote:
| No-code is definitely useful today for certain specific use
| cases, especially to create apps that collect data, store it in a
| database, and report to the client the results of some analysis
| of that data.
| pedalpete wrote:
| As an SE, I think that no-code is great. It lets us focus on the
| more interesting and challenging problems. Here's how we
| approached that in my current start-up.
|
| We built the website on Squarespace ( a tiny bit of custom JS
| because I wanted a specific UX, but minor). When we are fully
| launched and selling product, we'll probably continue to use
| squarespace, but we'll see. It suits us for marketing purposes
| and capturing interest now.
|
| At the same time, we're working in the hardware space (healthtech
| building an EEG), so we write all of our firmware, and we've got
| AI running on google cloud, so all the data pipelines that go
| along with that.
|
| We're building the front-end for our mobile app, but using Google
| Firebase for the user account, and other simple user-data stuff
| that we need. I consider Firebase to be mostly no-code, I code up
| the front-end, but don't need to do anything on the backend.
|
| The more interesting thing I've heard of recently is Fl{0}
| (https://fl0.com). They're a Sydney based start-up that is
| building a low-code style backend system. I'm not completely sure
| I get it, maybe it's just another version of nodeRed, and other
| similar tools.
| wglb wrote:
| Very old idea. First one I remember was COBOL--enables
| accountants to learn to use computers "without having to
| program", meaning without having to learn 1401 code.
|
| Later, there was the 5th generation movement with Prolog or
| Prolog-type langauges.
|
| Before that there was Fourth Generation Programming.
|
| Building systems is hard and requires programming. So people look
| for a way around it, leading to the next generation of "no-code".
| Then, the systems reach some sort of inflection point where
| programming is again required to add functionality.
|
| [Edit] See also "No Silver Bullet" for a thoughtful discussion
| about complexity of problems. This cycle will continue to repeat.
| oneplane wrote:
| It's just buzzword bingo. Complexity doesn't go away, it just
| moves around. Thinking about user interaction, product lifecycle,
| collaboration, knowledge pools etc. doesn't tie in to 'code' as a
| one-to-one, and if you swap out code for something else those
| still exist.
|
| The problem isn't code, the problem is the ability to analyse the
| problem, formulate requirements and design a solution. How you
| express that is an implementation detail at best. This is also
| where the problem with the marketing of those tools lies: it
| pretends that when you don't write code, you also don't have to
| do those other things.
|
| Ultimately this is just the same balance you get everywhere else.
| You have operating systems, tools, interfaces, frameworks,
| languages etc. that all do various things. Depending on what
| things you need to do and how novel they are you might be able to
| use and re-use existing systems, and you'll be adding to the same
| generic pool of applications that already exist. This is where
| automation-of-automation shines, depending on the level of
| genericness.
|
| Regarding problem solving, again, not code-related, you can solve
| problems in a conversation, on paper, using calculations etc. Yet
| any anti-code product is marketed as being able to avoid those,
| but that is not how problem solving works.
|
| Now, if we bring this all together a bit I find a question
| popping up: is this whole thing actually solving problems that
| exist? It's very easy to see a 'problem' if you're working in a
| bad workflow. But the 'problem' that is seen then often isn't the
| actual problem, but just a symptom. So now we are not solving a
| problem but 'solving' a symptom. This happens whenever someone is
| set to 'fix' something but doesn't actually know how to find the
| problem and then find the solution.
|
| Long-winded Example:
|
| Joe and Bob work at different companies. They need to exchange a
| bunch of rows of information and they do this by exporting a
| database table from some web app to a CSV file and emailing that.
|
| Joe (Source) uses some Database GUI with an 'export' button,
| grabs the file, puts it in an email as an attachment and sends it
| to Bob.
|
| Bob (Destination) receives the email, downloads the attachment,
| goes to his Database GUI, uses an 'import' button, points it to
| the file he just downloaded and now his task is complete.
|
| Joe and Bob won't want to constantly drag and drop CSV files, so
| they come up with a plan to use LowCodeNoCode Creator Studio XP
| Edition to automatically export the CSV, email it to a predefined
| email address, process the email, download the CSV, and import
| the CSV. From their perspective, they solved the problem! Without
| writing code!
|
| From a problem's perspective: the symptom is now hidden and the
| problem is made worse because nobody knows how this process
| works, why it exists, who did what, and how to manually
| intervene. On top of that, the real problem still isn't solved.
| Even the argument that "there is no code so anyone can find out
| how it works" doesn't hold up because while you don't need to
| learn some syntax you swap that problem out with learning some
| tool.
|
| The real problem is Master-Slave table replication, and if we
| analyse it one level deeper: messing about with a database table
| that is owned by an application. If you want to interact with
| data that is owned by an application you don't go messing about
| with the underlying persistence store, you use the application
| and if needed write an API extension that does the job. Heck,
| that API probably already exists in any modern application! But
| then you'd actually have to know how systems work, how to resolve
| requirements and how to come up with documentation and scoping
| and the foresight of future endeavours.
| ldiracdelta wrote:
| Exactly. The code isn't the hard part. The hard part is
| abstract thinking and logic.
|
| I created an email escalation notification system that was
| manipulated with graphics in a flow diagram. My users couldn't
| handle the precise logic for doing the escalation chain and
| always asked for help. Turns out, _that's_ what I'm good at.
| Logic and abstract reasoning.
| oneplane wrote:
| I see the same thing in most ticketing and planning systems,
| they all have some logic to decide what next steps are
| allowed and to edit those steps you modify a graphical
| representation of a state machine.
|
| You don't need to write code to modify it, but if you have no
| knowledge of flows or state machines or logical succession of
| events you simply can't solve the problem. It's not hard, but
| no-code isn't going to make it less hard either.
| tdrdt wrote:
| I think the most famous no-code app is WordPress.
|
| Some estimate that 70% of all websites run WordPress. But I can
| tell you my salary was paid by customers who wanted this 'one
| custom application' that was not available as WordPress plugin.
| avereveard wrote:
| They're not wrong, but they don't solve anything hard either, so
| they'll find that there's little value to extract from no code
| tooling.
|
| They live in a difficult bracket to find offering customers in:
| medium+ projects have most of their complexity in making the
| business domain model and understanding it's intricacies, well
| before you attempt to make a computer understand them; no code
| tooling only cover the latter. Small- projects live comfortably
| in Excel sheets, as scary as that sound for the reading cohort,
| it appears evident that a lot of the no code market is already
| captured by that, and they're not offering anything to challenge
| the dominant player in the space.
| shireboy wrote:
| > Clearly these apps/platforms enable non-developers to solve a
| bunch of problems which would otherwise need a software engineer.
|
| I'm not sure that's as clear as it seems at first. Everywhere
| I've been involved with them, the flow is like this:
|
| 1) Org sold on idea of no/low code tool, "business analyst can
| build things!" 2) Business analyst tries, fails to build things,
| calls dev 3) Dev figures it out, could have done similar in a few
| lines of code. Either a) becomes "expert" in tool or b) goes back
| to code
|
| I'm not ready to rule them all out, and maybe I just worked with
| some inept business analysts. These tools are by their nature
| usually closed source/proprietary, but maybe there's some great
| ones. But I also wonder if it's not partially fundamental: maybe
| text is just more concise and expressive than visual paradigms
| for some problems - there's a reason we still have textbooks for
| some things.
| jimnotgym wrote:
| I find that it is great until you want to do something it doesn't
| really support... and then it is hell. The inflexibility is a
| killer. I am only interested in a system that lets you code if
| you want.
| neilwilson wrote:
| When these things pop up again for the umpteenth time I just
| refer people to the classic text on the subject.
|
| Fred Brooks essay "No Silver Bullet"
|
| http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
| mmphosis wrote:
| What do I think about no-code?
|
| "Data" Driven Development (DDD), if you need a buzzword/acronym,
| is where I think about code and data in the same bucket (ie.
| Lisp). I can check a box to enabled something, type some text in
| a field to provide the i8n label and database field. Easy.
| Underneath somewhere, there's obviously still code, more complex
| code, to make all of this work.
|
| Or, what do I think of the so-called "movement?"
|
| As a single independent developer, I am in a bubble. I can't
| predict the future. I'd like to see powerful rapid development
| tools out there, but more and more I see a lot of locked up
| proprietary walled fortresses disguised as movements.
| mercurialsolo wrote:
| I think there's a reason this is such a recurrent theme that
| keeps coming up in different forms across the decades. Often
| people who are not developers have sensible ideas for
| apps/websites but do not have access to engineers who can
| implement them. This is especially true in enterprises.
|
| For example the content team in a company like Doordash won't
| have access to engineers to help automate content creation.
|
| But people in that team WILL have ideas around how they can
| automate their processes using a low-code/no-code tool.
|
| Shameless plug - I am myself making one of these tools to help
| more folks DIY tools, flows & apps without making it themselves.
| We're here at https://getmason.io
| tmaly wrote:
| If there is a truly great product that can make this work well
| for simple reports and simple CRUD apps, I would love it.
|
| I personally would like to be working on more interesting
| projects.
| mb22 wrote:
| I am an engineer with 20+ years of hands on keyboard, I've got
| projects that are now part of Apache, 1000's of stars on github.
| I've been CTO at a number of startups that have got significant
| funding. My point is to establish some credibility. I probably
| still suck.
|
| Having said that, I have been working with Microsoft
| PowerAutomate for the past 1.5 years and while it has saved a lot
| of time and been overall a good experience, there are times when
| the no code/low code gets in the way and I wish I could just
| "drop into code" to get something done. Examples are things like
| data validation. This technology is not going to replace coding,
| the paradigm shift is really happening for people in the
| marketing and sales operations parts of the business. For these
| folks, this tech is life changing. In a lot of ways, this tech
| felt like when you try a new framework in your language of
| choice; at first it's super easy and you get hyped, and then you
| hit a requirement where the nocode/lowcode environment really
| gets in the way.
| nodejs_rulez_1 wrote:
| > I am an engineer with 20+ years of hands on keyboard, I've
| got projects that are now part of Apache, 1000's of stars on
| github. I've been CTO at a number of startups that have got
| significant funding. My point is to establish some credibility.
| I probably still suck.
|
| More about being in a right place at a right time, but granted.
|
| > Having said that, I have been working with Microsoft
| PowerAutomate for the past 1.5 years and while it has saved a
| lot of time and been overall a good experience, there are times
| when the no code/low code gets in the way and I wish I could
| just "drop into code" to get something done. Examples are
| things like data validation. This technology is not going to
| replace coding, the paradigm shift is really happening for
| people in the marketing and sales operations parts of the
| business. For these folks, this tech is life changing. In a lot
| of ways, this tech felt like when you try a new framework in
| your language of choice; at first it's super easy and you get
| hyped, and then you hit a requirement where the nocode/lowcode
| environment really gets in the way.
|
| I think higher-level languages with a dual code-graphic
| representation and a possibility to drop into lower level are
| an interesting option, but even that is not new -
| Unreal/Unity3D etc.
| bluedevil2k wrote:
| Why are you trying to diminish his accomplishments? Does that
| make you feel better, to try to bring someone down? You come
| off as bitter and unaccomplished and this site could use less
| of people like you.
| dudeman13 wrote:
| Humble-bragging either works real well or backfires real
| hard.
| prepend wrote:
| I've had a different experience with PowerAutomate.
|
| Both as a no-coder and a user.
|
| As a user the UX is horrible and I'm now swamped with terrible
| "apps" or "workflows" that people try to get me to use and fail
| for arcane reasons. Or are just ugly or brittle.
|
| As a no-coder the tools are hit or miss, the docs are bad, and
| widgets frequently don't work due to my licensing and there's
| no way to know other than to try and see.
|
| It has such promise as the shell scripting equivalent for the
| cloud what shell was to PCs. But instead it is a costly and
| difficult thing to use.
| nitrogen wrote:
| _It has such promise as the shell scripting equivalent for
| the cloud what shell was to PCs._
|
| What ever happened to Yahoo Pipes?
| ROARosen wrote:
| > I wish I could just "drop into code" to get something done.
|
| Since you're using PowerPlatform you can prob easily do that
| with Microsoft's Power FX, built - I believe - especially for
| this.
|
| https://docs.microsoft.com/en-us/power-platform/power-fx/ove...
| Hjfrf wrote:
| I'm confused about the intended audience.
|
| Power FX has a level of abstraction squeezed between MS's
| other options (excel formulae,power query M/DAX, Powershell,
| C#).
|
| It gives the impression of a pet project rather than
| something users actually asked for.
| drunkpotato wrote:
| I think this is spot-on. No-code solutions allow non-technical
| folks in marketing and sales to build some amazing things that
| would have required teams of software engineers: marketing,
| shopping cart, and email integrations; email onboarding
| workflows; complex ad campaigns; better inventory and wholesale
| sales management; and a lot of other things I'm not creative
| enough to think of. I've seen an entire application prototype
| built by a product manager by duct taping Google Sheets,
| Mailchimp, and a database together with Zapier.
|
| However, their wants always grow just beyond the no-code
| capabilities, and there's still a need for software engineers
| for things that haven't been fully solved yet.
| ethbr0 wrote:
| IMHO, the best fusion of the two is offering a no-code tool
| to non-technical folks... while ensuring you have a tiger
| team of random and varied developers to produce one-off duct
| tape bits to cover gaps for them.
|
| It seems far more efficient to have a non-technical person
| fiddle with a GUI, get most of the way on data integration,
| etc., and then come to the team with only the parts they
| couldn't figure out.
|
| "I have this list of strings and I need to X" or "I need to
| push data to this API"
|
| We did something similar at a previous job, and it generally
| worked out well. The code assistance kept people from
| constructing Rube Goldberg machines in the designer tool, to
| solve simple coding problems that the tool couldn't cover.
| nodejs_rulez_1 wrote:
| > What do you think about this movement?
|
| It's not a movement, more like a mini-trend based on rediscovery
| of an old idea. At least not a pure investor duping like
| "metaverse".
|
| > Clearly these apps/platforms enable non-developers to solve a
| bunch of problems which would otherwise need a software engineer.
| Is this a paradigm shift?
|
| If it is, it happened in the last century and many times since
| then already. You could still hype it up for a new domain to grab
| some investor money, I guess.
| jdavis703 wrote:
| To give an analogy to natural language, a lot of no-code users
| want to skip past learning the rules of Latin and jump straight
| in to writing a 1000 page treatise in Latin.
|
| The problem with no-code is it generally appeals to a class of
| non-programmers who think programming is hard because of syntax.
| They don't understand that coding is hard because it's about
| understanding and solving hard problems that touch human computer
| interaction, legal/compliance and computer science domains (among
| others).
| junon wrote:
| This is such an old concept that it's been beaten into the ground
| at this point. These "movements" aren't really movements, they're
| product bandwagons. Notice how most of these "no-code" solutions
| are proprietary, for-profit, non-standard and unwilling to be
| anything but.
| hunterb123 wrote:
| Like most things in SV, people get hung up on the term.
|
| I like the tools coming out. UX designers, Airtable, etc. I don't
| view it as nocode, simply as developer and business tools.
| game_the0ry wrote:
| I think the actual question people are wondering is - will no-
| code take my job.
|
| TLDR -- No-code / low-code are basically just SaSS - you still
| need hire and pay software engineers to build it and use it. I do
| not predict that it will become a threat to employment or
| compensation, ever. Longer answer below:
|
| Some of you who remember a time when developing software was
| really, really hard. The tooling and docs have only gotten
| better, and the barrier to entry is lower than it ever has been
| before - it is now easier to become or switch careers (me) into
| development. Has the compensation for developers fallen? No, we
| have just gotten more productive, but the demand for software has
| gone up a lot.
|
| No-code / low-code are tools, and tools do not tend to replace
| people, but people still need to build and use the tools. Did
| AWS, kubernetes / docker, and Jenkins make IT and sys-admin folks
| less valuable? No, they just learned the tools and leveled up -
| now we call that "devops" and they get paid well.
| austincheney wrote:
| No code is fine. It's not much different from front end
| development where developers cannot figure out how to dynamically
| put text on a page without 300mb of framework and dependencies.
| AnIdiotOnTheNet wrote:
| The most popular programming environment on the planet is
| Microsoft Excel, a no-code product.
|
| I think a lot of developers are very anti-no-code because they
| know, as any rational person does, that any no-code solution
| flexible enough to do everything will look pretty much just like
| programming. But no-code shouldn't be a 'do everything' solution,
| it should be a 'do a lot of things more easily' solution. No-
| code, to me, means tools designed to bridge the gap between non-
| programmers and programmers and allow individuals to access
| computing at levels that are comfortable for them while on-
| ramping them towards more and more programming as their needs
| increase. This is what personal computing is all about.
| goohle wrote:
| Formulas are the code, otherwise FORTRAN is another popular no-
| code product.
| [deleted]
| AnIdiotOnTheNet wrote:
| By that logic, typing a URL into a browser or an email
| address into the "To:" field is code.
| vavooom wrote:
| Platforms like Alteryx (https://www.alteryx.com/) used for large
| data cleaning strike me as a strange stop gap between a clunky
| system like Excel (which has its natural 1 million row limit) and
| Python/R/SQL that are full OOP and are likely considered too hard
| to learn for many business professionals. And yet watching people
| using the platform looks tortuous! Why not invest in an often
| free application that you can fully control instead of buying an
| expensive, no-code based application? Likely has to do with what
| allows you to maintain talent / not pay for 'programmer' up front
| in salary costs.
| dagw wrote:
| I'm a decent programmer and I use an expensive, no-code
| application called FME for data
| cleaning/analysis/exploration/transformation etc. almost all
| the time. While I'm certainly capable doing basically
| everything I do in FME using Python, I am far more productive
| using FME. With FME I can knock together something in 10-15
| minutes that would take me hours to do in Python.
|
| That being said, one feature of FME that I do use a lot is that
| at any point you can drop in a PythonCaller which lets you
| execute arbitrary python code on your data. Invaluable for the
| last 5-10% which cannot easily be done using the "no code"
| approach
| hermitcrab wrote:
| The combination of visual programming with the ability to add
| code when required can be very fast and powerful (it is the
| approach we are using with our data cleaning tool, Easy Data
| Transform).
| LisaDziuba wrote:
| I've been working in the development space since 2015 and
| recently joined fast-growth no-code startup
| (https://welovenocode.com). We just raised $1M and achived $150K
| MRR. Happy to share my opinion based on my experience of leading
| "code" and "no code" startup.
|
| No-code is basically the art of creating solutions (native apps,
| websites, web apps), which could have been written with code but
| instead using visual methods (without coding). Most no-code tools
| use a visual drag-and-drop interface. A lot of them have pre-
| built templates that you can customize. There is also a slight
| difference between "low-code" and "no code".
|
| With "low code" a lot of things can be done with a drag-and-drop
| interface, however, some coding is required to for a finished
| product. So you ANYWAY need some background in coding. This is
| typically great for people with intermediate technical skill.
|
| What can be built with no-code?
|
| Mobile apps, web apps, websites, workflow and automations,
| marketing tools, payment systems, and the list goes on.
| Basically, "typical" products & MVPs benefit the most from no
| code. So founder can built something in weeks, really fast. For
| example, WeLoveNoCode (https://welovenocode.com) connects
| founders with the best no-code developers to build their software
| and apps without a single line of code in like 10 days. All that
| is based on a monthly subscription.
|
| Why all the hype?
|
| Well, ho code has A LOT of the advantages:
|
| - will save you money
|
| - You can build and test your ideas quickly
|
| - Anyone can use it > Designers, product managers, marketing
| managers now have the ability to make their ideas tangible
| products.
|
| What are the challenges you may face?
|
| Just like new thing, tools have to be learnt and they all have
| their learning curves. However, it will take you much less time
| and resources learning how to use no-code tools. Unlike low-code
| tools, no-code tools have a limit to how much they can be
| customised. If you want to change every aspect of your product or
| want to build very complex products, no-code tools may bring some
| limitation. However, there's so much innovation and growth with
| these tools so I expect these barriers to reduces in a few
| months.
|
| I should add that there's no limitation with scalability. No-code
| tools have the capacity for serve increase to allow as many users
| as possible without breaking. These tools are also very secured.
| TruthWillHurt wrote:
| Doesn't work. And I've had practical experience using low-code
| platforms, "selling" them and even built a couple myself.
|
| First - there's no complete solution. notice how they all have a
| "custom code" feature for you to fill in what's missing using JS,
| DRM or proprietery language. And you need a developer for that.
| These platform only work so long as you stick exactly to the use-
| case they had in mind.
|
| Second - Business/non-dev users don't have the skills nor _the
| inclination_ to use these platforms. It may look simple, just
| drag 'n'drop, connect the dots, But what if it fails? why did it
| fail? when will it fail? they don't have the experience and
| mindset to debug and account for edge cases, and they don't even
| want to learn how to do it! no matter how easy the no-code
| platform is.
|
| These conclusions I payed for in blood, sweat and money.
| mikewarot wrote:
| The ultimate "low code" experience I had was back in the 1990s
| with Delphi. You drag and drop your form elements, get everything
| just right. Next you hook up your event handlers and type in a
| few lines of code to do the actual work.
|
| It was the best I've ever seen balance of managing complexity,
| yet letting you write code when you needed to.
|
| The C++ version was nowhere near as god, it generated a ton of
| templates and things that just weren't necessary in Pascal.
|
| Since then everything is expected to work across the internet,
| through a web browser, web server, etc. It'll never be as simple
| and effective as it was.
| wonderwonder wrote:
| I remember Borland C++ builder being similar. Was actually
| pretty good to use.
| vadfa wrote:
| >The ultimate "low code" experience I had was back in the 1990s
| with Delphi. You drag and drop your form elements, get
| everything just right. Next you hook up your event handlers and
| type in a few lines of code to do the actual work.
|
| Today I was thinking about Visual Basic 6, which worked more or
| less the same way.
|
| I wonder what similar alternatives we have today? Gambas?
| https://en.wikipedia.org/wiki/Gambas
| redisman wrote:
| The problem is that you can't usually afford to target just a
| Windows 95 PC or equivalent today so such a tool cannot
| exist. The UI must morph and adapt and feel native across
| phones, tablets, retina displays, etc.
|
| Even video games these days need to adapt to a different UX
| on each platform even thou they are the closest to having one
| unified UI across the gamut
| lowbloodsugar wrote:
| Delphi is alive!
| https://www.embarcadero.com/products/delphi
| mikewarot wrote:
| It's unrealistic to expect a full, productive, desktop
| experience on any smaller devices.
|
| Giving up on the desktop is a huge step backwards.
| oneplane wrote:
| On the other hand, the market has expanded beyond
| economies where users have the space, power and physical
| safety to actually own a desktop. For some people their
| first, last and only "PC" is their smartphone. Your
| choice then becomes embracing those users or not having
| those users at all.
| nitrogen wrote:
| "One size fits all" fits no one.
| bitwize wrote:
| I like typing stuff in and instantly seeing the results,
| rather than rat wrestling widgets onto a form. Rat
| wrestling also makes adaptive UIs difficult; again, the
| solution is being able to declare your UI with layout
| managers that apply constraints.
|
| The most rapid UI tool I've ever encountered is Tcl/Tk.
| Everything else involves incurring more tedium and misery
| -- even Visual Basic or Delphi.
| airstrike wrote:
| > The UI must morph and adapt and feel native across
| phones, tablets, retina displays, etc.
|
| Isn't that a solved problem by the likes of React Native?
| jonjon10002 wrote:
| The first one I encountered from that same era was Interface
| Builder, on the NeXT. And it turns out it's still around, as
| part of XCode on the Mac.
| vb6sp6 wrote:
| Vb6 still works. I just put out a new version of my project
| today :)
| pjc50 wrote:
| You can do "drag and drop form elements and type up the event
| handlers" with Visual Studio and C#. The problem is that
| Microsoft have rather lost their way on GUI frameworks - too
| many of them and the latest ones are either "to be obsolete"
| or "not finished yet" (winui3), and winui3 has broken the
| interactive designer.
|
| Theoretically it can be multi-platform https://platform.uno/
| GordonS wrote:
| I used Delphi a lot in the 90's and early 00's, but I never
| really considered it "low code", with the exception of the drag
| and drop forms designer of course.
| PeterisP wrote:
| It depends very much on what functionality you needed.
|
| If you needed a GUI for database CRUD operations (which is a
| _lot_ of business processes and a lot of webapps now), then
| you could do that with nearly zero code, as the built-in
| behavior was all that you needed, but if you needed some
| interesting custom script and just a button "run it" and a
| textbox for results, then of course that would be nearly all
| your own code.
| DantesKite wrote:
| No-code is just a synonym for "software".
| can16358p wrote:
| It will probably solve simple problems as it will enable "no-
| coders" to actually do things really without any code with AI-
| assisted-visual-drag-and-drop "coding". But that doesn't seem
| like to take off for any serious work soon. It might be a gateway
| for beginners to perform some simple tasks and to start actual
| programming by diving in though.
| jl6 wrote:
| This is an imperfect analogy, but consider for a moment the role
| Microsoft Excel plays.
|
| Excel allows non-coders to do many useful things, and provides a
| relatively gentle on-ramp to actual code via formulas. If you
| take that on-ramp and keep going, towards VBA and add-ins and
| other pieces of Microsoft technology, you might wind up becoming
| a full-time software developer, leaving Excel behind and using
| "real" tools.
|
| Now, there's a happy path and an unhappy path here.
|
| The happy path is that you use Excel for what it's good at, but
| recognize when you are operating at its limits, and at that point
| pivot into "real" software engineering tools.
|
| The unhappy path is that you stick with Excel too long and become
| mired in the world of VBA and advanced formulas and attempts at
| shared workbooks, and build pseudo-database application-
| contraptions.
|
| No-code can be like that early Excel usage: it can grant some
| limited but useful powers to non-developers. But no-code can also
| evolve to become like those contorted, unmaintainable spreadsheet
| monstrosities that stretch the technology far beyond the point
| where some "real" software engineering would have been the right
| answer.
|
| Short version: use the right tool for the job.
| divbzero wrote:
| Excel is a great example of how "low code" or "no code" are
| recent buzzwords for a long continuing evolution. There have
| long been attempts to make software development more
| accessible. Some attempts stuck (Crystal Reports 1984, Excel
| 1987, WordPress 2003, IFTTT 2010) while others did not
| (HyperCard 1987, FrontPage 1995). The same will be true for the
| current crop of platforms.
| jbjbjbjb wrote:
| Seems like you either die a hero or you live long enough to
| see yourself become a villain.
| darkwater wrote:
| I don't agree: Frontpage was definitely a villain.
| can16358p wrote:
| Not as villain as Dreamweaver. Not directly but
| considering how MS saw that has no future and abandoned
| it, while Dreamweaver became the "web dev tool" for many,
| many out there for long years until Adobe understood
| those tools had no future at all.
| StevePerkins wrote:
| Pfft. Dreamweaver (and even FrontPage) were perfectly
| fine back in the pre-IE6 days when they dominated.
|
| People today crap on using <TABLE>'s for grid formatting,
| just as we crap on 1990's Java code for its
| `AbstractStrategyFactoryFactory` excesses. Because it's
| "what people did back in the bad old days", and is a
| glaring red flag that one's skills are out of date.
|
| But whereas OO design patterns are a matter of subjective
| debate, early HTML4 and prior just flat out didn't have
| modern mechanism for separating presentation and content.
| CSS 1.x was very limited, and no major web browser even
| seriously supported that until the year 2000. CSS 2.x
| didn't get real until the 2010's.
|
| Would any professional use Dreamweaver today? Of course
| not. But it was an appropriate tool for its time.
| actually_a_dog wrote:
| There's a second version of the unhappy path, as well: you're
| trying to use the tool for what it's good for, but there's a
| bug that makes your particular use case unnecessarily
| difficult. At worst, what happens is you silently either get
| bad results or lose data. At best, you either don't use the
| tool for that purpose until the bug is fixed, or, you implement
| some silly workaround. All in all, this can be a rather
| disempowering situation for a non-technical user, which is the
| exact opposite of what "no code" promises.
|
| TL;DR: "no code" is just somebody else's code. You're
| introducing a massive external dependency you have little
| control over by using a "no code" solution.
| mountainofdeath wrote:
| Case-in-point, there are more than a few non-software
| engineering firms where the entire business is a series of
| mind-boggling amalgamations of Excel and VBA with a healthy
| dose of Matlab on the side. I'm talking full applications
| written in VBA with Excel as the interface. I wouldn't be
| surprised to see the same in non-quant finance.
| jimbokun wrote:
| I would go further and say Excel is the ultimate no-code
| solution. It has been used by more people to solve coding like
| problems by non-coders than any other no-coding tool.
| jrm4 wrote:
| It's a _perfect_ analogy. Don 't sell yourself short. Look, the
| following things are true.
|
| 1) This industry absolutely has the capability create more
| tools like Excel that are both extremely empowering and orders
| of magnitude easier than what we think of as coding.
|
| 2) Unfortunately, there's a strong, likely frequently
| subconscious, incentive to definitely not do this, since it
| carries a strong danger of IT making itself "obsolete."
|
| (Not judging here, just observing)
| Aperocky wrote:
| > 2) Unfortunately, there's a strong, likely frequently
| subconscious, incentive to definitely not do this, since it
| carries a strong danger of IT making itself "obsolete."
|
| I can't think of a single case that this has ever been the
| decision making process when creating a product.
|
| If you look at the myriad of available tools that trends in
| this direction, in all fields, you'll realize that the
| industry is littered with both successful and failed
| examples, ERP systems alone are a huge market.
|
| It's just that people wanted to replace _actual_ convoluted
| general purpose logic known as coding, that they ran into
| problem that could not be addressed by some GUI. And that no-
| code solutions that exist today propagandize about.
| jrm4 wrote:
| What? I can think of a ton _egregious_ examples of
| deliberate "disempowering" right off the top, to say
| nothing of the likely TONS more subtle ones.
|
| Shutting down Hypercard.
|
| Google Reader.
|
| Bill Gates emphasizing to NOT make MS docs compatible with
| others. The list goes on and on.
| Aperocky wrote:
| How are any of these related to making IT obsolete?
| jrochkind1 wrote:
| I would think the incentive to make a bazillion dollars if
| you did this sucessfully would outweigh your purported
| frequently subconscious disincentive.
|
| Plus there are other people in this comments thread saying
| they are working for companies that _are_ (they claim) doing
| so. Not to mention all the past attempts to do so over the
| past 40 years. Is the idea that those companies are
| intentionally not doing it as well as they could, because of
| their allegience to not making the field of IT obsolete?
|
| The idea that we collectively could easily be making software
| construction toolkits for non-programmers that would make "IT
| obsolete", it's an easy problem, but we just _choose_ not
| to... is a conspiracy theory.
| arrayjumper wrote:
| I suppose the difficult part is figuring when you've crossed
| the fine line from "good enough for now" to "this is becoming a
| monstrosity, we need to hire developers and create our own
| software now"
| Ensorceled wrote:
| The second difficult part is when the team that built the
| "good enough for now" realizes that the line was crossed,
| that they do not have the skills to be part of the "hire
| developers and create our own software now" solution and then
| start subtly, or even openly, sabotaging every effort to move
| away from the Excel/VBA solution.
| Waterluvian wrote:
| I mostly agree. But I think there's an important semantic
| distinction: people who use excel are coders. They are
| programming the moment they write an expression into a cell.
|
| I think this is important because we fool ourselves by calling
| these people non-coders.
|
| Excel is really just a coding environment that has a
| ridiculously smooth learning curve.
| lambdasquirrel wrote:
| The problem is as it's always been. Solving problems in the
| general sense is hard. It is true in design, it is true in AI,
| it is true in the automotive world, and on the battlefield.
| Specialized for one task is easier to learn, and easier to
| design for. General is harder to learn, and harder to design
| for.
|
| With that in mind, it's interesting that we still even have
| "general-purpose programming languages." There is some
| specialization for sure, but that's partly because of things
| like e.g. the browser only supports Javascript. And then you
| see things going back the other way, e.g. with NodeJS.
|
| So I'd wait till we see some actual, real specialization in the
| languages / tools that engineers use, beyond "ecosystem"
| reasons. In the meantime, we've seen tools that help non-
| programmers "automate" things. Everything from CAD to Wix,
| Salesforce, Figma, etc. would fall under that umbrella. But
| then you still have code. If what you want is automation /
| labor-force-multipliers, the common denominator will still be
| highly generalized, and therefore, hard.
| ethbr0 wrote:
| > _Excel allows non-coders to do many useful things_
|
| I heard a great quip at some point: "Why is Excel the most
| useful IDE?" Answer: "Because it's the one IDE every business
| allows every user to access."
|
| Most of us here have forgotten that many businesses flat out
| ban access to programming tools for the majority of users.
|
| And what is an enterprising user to do, when they realize
| they're performing the same process 100 times a day?
|
| Reach for the only wrench they've been given access to.
|
| PS: I guess an analogy would be people griping about shell
| scripting, without considering that someone might not have the
| ability to install their framework of choice when connecting
| into a client server. It gets the job done, with the tools
| available.
| _trampeltier wrote:
| 100 x this. Most companys ban all kind of software. So Excel
| is the only solution for really all kind of problems.
| xondono wrote:
| Some years ago someone posted here on HN an excel extension
| that turned excel into an actual IDE.
|
| While it's true for a lot of people is the only choice,
| there's also an amazing amount of enterprising users that
| sadly don't know any better!
| ethbr0 wrote:
| That's the Venn diagram problem: how many people are there
| who (a) understand the needs of line of business non-
| developers, (b) understand their corporate IT policies that
| non-developers suffer under, (c) know the better way that
| other developers do it, & (d) are willing to wade through
| the political and policy @&$& to actually get something
| done about it?
|
| In my experience, not too many. Non-developers don't know
| what they don't know, and developers don't know what non-
| developers need.
| 908B64B197 wrote:
| > Most of us here have forgotten that many businesses flat
| out ban access to programming tools for the majority of
| users.
|
| That sounds... counter productive to say the least.
| ethbr0 wrote:
| You get no argument from me, but I've seen it too
| frequently to believe it's not by design.
|
| Typically the rationale given is "Non-developers can't be
| trusted to write code and follow development policies,"
| while leaving the unspoken that they're limiting
| development to people who by their organizational seat
| definition aren't experts in the problem they're being
| asked to code.
| GordonS wrote:
| I definitely think that's a large part of it, but I saw
| impressive uses of Excel and Access by non-coders long before
| it was typical to lock-down workstations the way corporations
| do nowadays (like, 20 years ago).
| analog31 wrote:
| >>>> The unhappy path is that you stick with Excel too long and
| become mired in the world of VBA and advanced formulas and
| attempts at shared workbooks, and build pseudo-database
| application-contraptions.
|
| How happy was the "let's just spin up a software project" path?
| je_bailey wrote:
| I don't think it's a paradigm shift. There's always been a desire
| to have some sort of magical tool or platform that would
| eliminate the high cost of a developer. The problem that these
| companies encounter is that these tools are quick to improve the
| baseline but they come at a cost of making their baseline the
| same as other peoples baseline. If they want something unique, or
| compelling, that's above and beyond then they would need custom
| work and that means some form of development
| goinfar wrote:
| 1) Don't write code 2) Automate transit 3) ??? 4) Idiocracy.
| ecshafer wrote:
| What is old is new again. This has happened before. Graphical
| programming, low-code, no-code. They all inevitably hit a wall
| where it does not cut it. Either the performance is not good
| enough, they need to dip into real code to add features, etc.
| Then there are the issues like CICD and version control that they
| don't do well that hold them back, and then integrating with the
| rest of the company. Its just not worth it, its a dream sold to
| VPs and will die off in a few years and come back a decade after
| that.
|
| I previously was supporting a company integration with Appian
| (building the AWS/Webservices integrating the two halves), which
| bills itself as a Low Code platform for Business Process
| Management. And their hello world example kind of worked fine for
| getting "a business person" to "write code". So the idea was they
| get these business people to write code instead of developers.
| But the problem with this platform was that we had to eventually
| get full time software developers (so no cost savings there, but
| also had the issue of these devs were now niche developers and
| not learning broader skill sets). Because their graphical
| development didn't cut it, so they had to drop down into their
| code proprietary DSL. Then the actual platform was a mess of no
| cicd, bad disaster recovery, bad monitoring, bad everything. It
| would have been cheaper and easier to literally just write a
| business process management from scratch in whatever language we
| wanted.
|
| tl;dr No code, low code, graphical programming is a fad.
| derac wrote:
| I agree completely. IPaaS tools are bad programming languages
| with awful tooling. The logic you need to transform some data,
| say, can become very complex quickly and you're stuck
| manipulating it with terrible graphical tools. When you
| inevitably find a bug, it's a huge pain to deal with.
|
| For making a website with a store though, it can be great.
| [deleted]
| ignoramous wrote:
| I wrote this on another thread a few months ago:
|
| I think the basic reason why low-code / no-code works is down to
| software bugs and long-tail maintenance.
|
| Bugs are a function of number of engineers, features, moving
| parts, and significant lines of code.
|
| No-code takes out engineers, moving parts, and SLoC from the
| equation (as far as the enterprises buying these solutions are
| concerned), but leaves a lot to be desired in terms of feature
| set; low-code brings down number of engineers, and SLoC, whilst
| providing flexibility in terms of bespoke feature sets.
|
| Also, in essence, No-code and Low-code are a natural extension of
| the cloud computing model in which capex is traded away for opex.
| And economies of scale, over time ensures Low-code / No-code will
| be cheaper yet more reliable than anything one (tech-enabled)
| enterprise can roll on their own. While at some level it is also
| an indication of 'software is eating the world' phenomena (both
| in terms of available capital given software economics, and rise
| in popularity of CS, in general).
|
| https://news.ycombinator.com/item?id=27074657
| tehjoker wrote:
| No-code is always doomed to fail because the forefront of
| development always requires complex reasoning and understanding
| of leaky abstractions. I worked at one point with a business
| rules engine, and non-programmers are fine with a decision tree,
| but start introducing loops, queues, function calls with multiple
| parameters, database queries, or even complex logic in if
| statements and it gets hairy. It takes training to reason like
| that.
|
| It doesn't matter how nice the UI is, there's a fundamental level
| of complexity there that requires study and training that also
| induces anxiety in an untrained person.
|
| No-code can handle a significant percentage of work. In the
| system I experienced ten years ago I would guess 20-30%? In that
| case, we had close collaboration between developers and business
| people within the same building, and some of the business people
| were even willing to be trained in SQL (!). It's certainly useful
| in that regard, but it doesn't eliminate the custom stuff. The
| eventual interactions between the custom and no-code logics are
| something that requires balancing too.
| ucosty wrote:
| I'm still not sure what difference is between 'no-code' and just
| using software. If I create a workflow in Jira I wouldn't say I'm
| creating no-code software, I'd describe that as just 'using' or
| 'managing' Jira.
| callesgg wrote:
| No code just means non text based code with limitations, perfect
| for people that are scared of text.
| undoware wrote:
| The problem with no-code is it is also usually _no-ontology_. It
| 's always fun to mock 'ideology', but without a strong
| philosophical principle, every project will eventually morph into
| a hairball.
|
| The underlying ontology behind code is, "reduce problems to a
| normalized form that can be stored in text, which we have gotten
| good at managing with snapshots and branches in DVCS".
|
| With no-code, you _don 't have a normalized form to reduce to_.
| Maybe your project is PowerBI modules or Excel-like
| superspreadsheets or whatever, but the 'stuff' that your project
| is made out of is not subjectable to the same kind of rigorous
| management that contemporary codebases tend to adopt.
|
| The two analogies that come to mind are nosql, a movement which
| rather quickly discovered that RDBMS -- a normalized form for
| storing and addressing data -- was a pretty good idea, actually,
| for many use cases.
|
| While NoSQL found important roles to fill, it is by no means as
| Big a Deal as the breathless tech media made it out to be, back
| in the aughts when mongodb first dropped.
|
| The other analogy is double-entry bookkeeping. It's been around
| forever, and while it's not appropriate for every use case, its
| resilience and _ability to represent complex changes in a complex
| system over time_ in a _normalized way_ is similar to how a well-
| maintained codebase is represented by git (and competitors).
|
| Code is a form for representing thoughts about changing systems
| which change the world in turn. It implies an ontology -- an
| "ideology", in the popular sense of the term -- and without that
| scaffolding, projects get floppy.
|
| I'm much more excited about things like Git Copilot. Did you see
| the demo at Ignite, where that guy was literally just describing
| in English how he wanted the minecraft bot to behave, and the
| model wrote the (perfect) Minecraft scripting to make the bot
| obey?
|
| That, IMO, is the future. Tools that create code that may or may
| not require tweaking, but can be still be committed to a repo,
| and is still something whose provenance and behaviour you can
| reason about, and diff-view when it changes.
|
| Now, making the resulting code _provably correct_ in a quick,
| automated way is probably the next thing I 'd work on if I was in
| charge of Copilot development. But this will probably require
| changes to the languages that people use.
|
| "Here is the code that does the thing you verbalized in English,
| here it is deployed, and also, here are several proofs, including
| a formal proof, the code does what is intended."
|
| (Another advance I'd like to see are AST-based DVCS, rather than
| text diffs, but that is a story for another monologue)
|
| [EDIT: I should mention that I happen to work at the specific Big
| Tech Company that makes Copilot; however, I work nowhere near the
| team that made it, and my opinions are emphatically my own.]
| tcldr wrote:
| Code is the OG 'No Code'. Or to give the movement its full title
| 'No Machine Code'.
|
| I wonder if programmers of the day thought that compilers would
| put them out of a job?
| kemiller wrote:
| My observation from running a consulting business is that there's
| a gap in the market that I have not seen meaningfully solved. On
| the one hand are these no-code tools where you can do something
| reasonable in a very limited domain. Wix, Squarespace, etc. Every
| decade the limited domain expands a bit, and you can get
| something serviceable for your hobby or small business fairly
| cheaply, in the order of $10s or $100s, maybe a couple thousand.
|
| On the other hand, is full scale development, either in-house or
| outsourced. This is only doable for projects that are ~$50k and
| up, even if you go with cheap offshore developers.
|
| So there's this gap from ~$5000 to $50,000 where if that's all
| you can afford, you just can't justify the project. In theory
| that's where the "low code" tools should fit, but so far, I have
| never seen it work out like that.
| bjt wrote:
| What's fascinating to me as that it's happening at the same time
| as the "X as code" movement.
|
| Devops: Infrastructure as code. or dbt's viewpoint on analytics
| as code (see https://blog.getdbt.com/building-a-mature-analytics-
| workflow...)
|
| So I'm seeing it as an exercise in finding sweet spots. There are
| things that have been mostly manual or point-and-click and people
| are seeing wins from defining and managing them as code. Usually
| in terms of reproducibility and testability. Then there are
| things that people have traditionally done in code (e.g. admin
| UIs) where maybe most of it can be abstracted away into a point
| and click tool.
|
| No-code works great until it breaks, and then your ability to
| debug is going to be very constrained. We're fighting that
| problem with some no-code ETLs using Stitch at work today, for
| example.
| wai1234 wrote:
| As has been pointed out already, this is yet another round of an
| old paradigm. Just like every other shortcut (looking at you,
| frameworks) it comes down to LEGOs (or Minecraft). As long as you
| are satisfied with blocks world, they are great. As soon as you
| need a curved surface or a different color, you are out of luck.
| There's also that detail that someone has to write all that code
| so you don't have to.
| EricRiese wrote:
| There is still code in no code in the same way that there is
| still procedural code running when I execute an SQL query. I
| don't care how much code is being executed. I care about
| maintenance burden. Postgres is better maintained than anything I
| can make. So I'd rather just maintain the SQL query than the
| entire procedural mass that's actually executed.
| Jugurtha wrote:
| I don't.
| thehappypm wrote:
| Some areas of software are well-suited to solutions which require
| no coding. Photoshop is a great example. PowerPoint and Word are
| another. WordPress is another. Some of these are enhanced with
| code (WordPress, Excel).
|
| Over time all software areas will have no-code options.
| aarondia wrote:
| A lot of comments here point to users eventually running up
| against the boundaries of no/low-code environments and having to
| make the decision to graduate from them or push their limits to a
| place where they were really not intended to be used.
|
| I've spent the past 1.5 years or so building a no-code data
| analytics tool called Mito [1] -- a spreadsheet extension to
| JupyterLab that lets previously Excel-based workers make the
| switch to a Python based environment. Unlike other no/low-code
| data analytics tools we spend a large amount of engineering time
| making sure that users are never locked into Mito. We do this in
| 2 ways: Firstly, every time you make an edit to your data in the
| Mito spreadsheet, we automatically generate the equivalent Python
| code for you. And secondly, to make it easy to work with that
| code, Mito is an extension to your JupyterLab environment. By
| existing in the IDE that you would otherwise be using if you
| didn't have the low-code environment, its really easy for users
| to switch back and forth between working in the Mito no-code
| environment and writing code themselves.
|
| Practically, what we've seen over the past year is that giving
| users ownership of the code that they create using Mito and
| existing in JupyterLab has been incredibly important. The most
| active Mito users are those that use Mito in conjunction with
| custom Python code that they or their company has written. They
| do things like incorporate API calls to access their data, use
| advanced pandas/Python functionality that we don't support, etc.
|
| TLDR: We believe that no/low-code are most powerful when they are
| augments to the "real deal" code-first workflow instead of a
| substitution.
|
| [1] https://trymito.io/hn
| haolez wrote:
| I've tried this with my current company, where the majority is
| not tech savy. The business analysts had immense difficulty in
| creating and maintaining automations on their own. And it gets
| worse: the few devs that we have at the company had to "rescue"
| the no-code automations on a daily basis and ended up rewriting
| most of them. It takes longer for a dev to create an automation
| in a no-code platform than by simply writing code for this
| solution.
|
| Your mileage may vary, but my feeling is that no-code will keep
| growing in relevance, but it's not there yet on what it claims to
| do.
| davnicwil wrote:
| I work at Stacker (YC S20) [0] -- we're actively building a part
| of this future and so I've done a lot of thinking about it.
|
| My view is that, indeed, the general no-code category represents
| a paradigm shift in the truest sense. That is, it is not going to
| replace anything we currently use software engineering for,
| except at the very edges. This is pretty obvious to anyone who
| understands software and the complexity inherent in building
| custom things. Rather, it will enable a massive _new_ category of
| software to be built, where presently it is uneconomical to do
| so.
|
| Think simple tools, sometimes throwaway tools only needed for a
| few weeks, tools specific to each new project - things currently
| implemented with whiteboards and sticky notes that would clearly
| be better as digital tools in all sorts of ways - and indeed
| increasingly essential as the assumption that everyone is in the
| same office gets less true.
|
| This stuff is typically quite straightforward but requires deep
| domain context that'd be really difficult to translate into a
| spec, and way too expensive anyway to justify hiring engineers to
| build, but it can now just be done directly by the domain experts
| themselves who need not necessarily be technical.
|
| This category is simply massive - think of the number of such
| tools that could be useful in even a single given business if
| they were simple and cheap to create. Now multiply that by every
| business.
|
| If you're convinced / intrigued by any of what I've said, by the
| way, we are hiring. So let's chat about it more! Email is in my
| profile :-)
|
| [0] https://stackerhq.com
| andrewstuart wrote:
| Lotus Notes was the earliest true nocode tool.
|
| I was using it in 1990 to build nocode distributed replicated GUI
| form and view driven applications.
| TheRealNGenius wrote:
| Much ado about nothing
| a-dub wrote:
| computers have become way more pervasive and basic coding
| actually isn't that hard. i think that maybe for all the hassles
| it creates when things get complicated, it may be secondary to
| next generation ides that make coding easier along with a general
| population that grows evermore tech savvy and ready to learn with
| each passing year.
|
| tldr; i think it solves yesterday's problem. people today are
| both more willing and more able to learn basic coding skills. the
| hard part for both visual environments and high level languages
| is getting the abstractions right for the building blocks and i
| think it's an easier problem with the expressiveness of text.
| mywittyname wrote:
| No Code can solve problems that have been solved so many times
| before that a bunch of developers decided there was money in
| solving the entire class of problems once and for all.
|
| So I think they are great, because who wants to reinvent the
| wheel? It's so much nicer to pay someone else to deal with the
| problem while I focus on building solutions to novel problems.
|
| Is it a paradigm shift? Yes, in the same way that Excel was a
| paradigm shift. When you make it easier to solve a class of
| problems, then people solve more problems in that domain.
|
| Excel radically transformed so many industries because it
| suddenly became dirt cheap to do complex costs analysis, so
| instead of paying an accounting firm to run two or three various
| costs analysis for a product, they could instead be paid to find
| the optimal solution for a product to hit a specific price point.
| Suddenly, we have candy bars with 54.51g of chocolate in them.
|
| Something to keep in mind, is when the cost to compete in a
| segment goes down, competition increases to the point where the
| cost to compete is driven back up. If anyone can build a
| competing product in a weekend with 0 background, then competing
| products are going to pop up where ever money is being made. And
| one of those competitors is going to innovate their way to the
| top, through technology, marketing, corruption, or some other
| means.
| ARandumGuy wrote:
| The fundamental problem with any no-code type solution is
| balancing how complicated the system is. If a no-code system is
| too simple, then you'll need a programmer whenever you need to do
| something not offered by the no-code system. If it's too
| complicated, then you might as well just use an actual
| programming language.
|
| Obviously, there are use cases for these type of systems. Many
| businesses only need a simple website, and there are a lot of
| problems out there where an off the shelf solution will suffice.
| However, I doubt no-code is going to make any meaningful impact
| on software development. The world is full of problems too
| complicated to solve with off the shelf solutions, and those
| problems will need a programmer to write some code.
| kodjima333 wrote:
| At welovenocode.com (the biggest no-code marketplace) we
| discovered that during shortage of software developers, big
| companies (S&P 500) started to hire no-code devs instead. The
| ratio of code to no-code people hired was 1000:1 and now it has
| increased to 100:1 (by 10 times)
|
| I think that within a couple of years, no-code will take over
| >30% of the software development market
| dlsa wrote:
| Its a shift in some ways. Lowers a lot of friction for
| prototyping and production purposes for plenty of adhoc tools.
| People think this will help. It does and it will. I've used quite
| a bit of it and had generally good results. We're only in the
| early stages even though plenty of tools are a decade old.
|
| But it has limits like everything else. Vendor lock-in is
| returning similar to the old days of mainframes. But at least
| this time around the tools are more varied and from different
| vendors as well as the ability to use one of many languages in
| most cases.
|
| You can run a bunch of businesses with writing very little code.
| What they don't seem to include in that no-code advertising blurb
| is the amount of configuration required for some no-code
| solutions. Especially integrating each *aaS to the next. That
| seems trivial but can become quite a project.
|
| The bigger cloud offerings such as AWS create dependencies that
| might be an issue for a lot of businesses if they try to switch.
| This includes wanting on-premises solutions for whatever reason
| instead of the cloud. AWS is more than "hey you can run redis,
| mysql etc in the cloud". Its constellation of convenience is
| quite a thing to behold. Gets hard to leave. That's the new
| variant of the old vendor lock-in strategy: You don't want to
| leave and it can hurt a lot to do so.
|
| There is also an issue with non-cloud alternatives as inherent to
| most of the no-code solutions in practical use. Unless of course
| you have a disaster recovery plan for when your favorite sites go
| down. We still need to have DR plans even for no-code.
|
| You are ready for the no-code platforms you use to go offline,
| right?
|
| Haven't mentioned security. Better not forget that either.
|
| No-code means more contract management.
| Aperocky wrote:
| It's in the same class of ideas as perpetual motion machines.
|
| In that case, it violates laws of thermodynamics, in the "no
| code" case, it violates Information Theory.
|
| The entire process of coding is about translating requirements
| into machine executable programs. The requirements cannot be
| condensed below a certain threshold and that's where the 'no
| code' promise fails. You can move around blocks of shapes but in
| the end they must represent the same amount of information and it
| just resembles code.
| kwhitefoot wrote:
| There is no such thing. There are simply different
| representations of 'code'.
|
| Those who promote 'no code' solutions always seem to think that
| just because one does not edit with a text editor that there is
| no need to _design_ the solution or to _debug_ it.
|
| One is still developing, just using different tools.
|
| For some subset of problems it might indeed enable someone who is
| not a programmer to create a solution just as Excel enabled
| millions of people to do just that. Unfortunately one usually
| finds a little later that the solution has the shape of the tools
| used to create it, that because the tool could do something in a
| certain way that is the way that is chosen rather than choosing
| the tool to fit the intended solution.
|
| You end up with people creating databases in Excel because Excel
| is what they had.
| sirwhinesalot wrote:
| They need to stop locking people into their ecosystem and
| generate code you can get out and hand out to a developer if
| necessary.
|
| No-Code / Low-Code / Full-Code is a false trichotomy anyway.
| There's no reason why visual coding needs to be any more
| restricted than the real deal.
|
| It's all just one big usability problem. We'll continue to
| develop software pretending we're running 80 character wide
| terminals for awhile, but I believe this will change someday.
|
| Tools like Enso, or the Elm debugger already show how much better
| things are with instant, actionable feedback, even on "real"
| languages. Then you remember Smalltalk and HyperCard existed in
| the 80s and you wonder how it all went so wrong.
| hermitcrab wrote:
| Visual no-code/low-code tools have been around for decades. They
| can work really well when they are aimed at a manageable sized
| domain (e.g. data wrangling). They tend to fail badly when the
| try to be a replacement for a general purpose programming
| language.
|
| I think a lot of the problem is the endless hype and over-
| promising by marketing and sales people.
| short12 wrote:
| It's stupid and doesn't really represent anything of substance
| Animats wrote:
| Web development was much closer to no-code at Macromedia
| Dreamweaver 8. Then came Adobe.
|
| The machinery behind web sites outside of the top 100 ought to be
| standardized by now.
| jasode wrote:
| _> What do you think about this movement?_
|
| The "no-code" desire has been around for _decades_ -- just using
| different terms. E.g. in 1980s and 1990s, a common phrase for new
| tools that didn 't require programmers was "self-service" ...
| like Crystal Reports software for _" self-service reports without
| programming"_.
|
| To put it in perspective, consider that Microsoft Excel is a "no-
| code" tool. In the old days before desktop computers, if a
| business person wanted to look at a report of sales amounts
| grouped a different way, he would ask the COBOL programmers in
| the IT department for a "change request" and they'd do the
| following:
|
| - "code" new punch cards for the mainframe:
| https://www.google.com/search?q=mainframe+punch+cards&source...
|
| - load of magnetic tapes (each held about 40 megabytes) of the
| sales data:
| https://www.google.com/search?q=mainframe+9-track+tape&sourc...
|
| - get a new report on greenbar paper:
| https://www.google.com/search?q=greenbar+paper&source=lnms&t...
|
| Now, any office worker can do the above with a "no-code" tool
| like MS Excel with pivot tables, filters, etc. Even though Excel
| eliminates a lot of coding work, the demand for _programmers
| keeps going up_. No matter what "no-code" tool is invented, the
| world keeps _inventing new tasks for human programmers to do_
| that today 's no-code tool can't do. There's always a delta in
| capabilities.
| Sn0wCoder wrote:
| Background I have worked at a low code/ no code shop. We could
| deliver prototypes fast. But that's just it they were prototypes
| that went into production but at that point clients were hooked
| just where you want them. At that point feature requests require
| one of two things. A coder to build a new no code widget or more
| likely just code the feature. So to summarize they make the easy
| things easy but the hard things impossible. As time goes on maybe
| you have enough widgets to be successful but most problems are
| one offs where the widget is only needed once so why build the
| widget when coding is faster and cheaper?
| dangus wrote:
| Business value and technical implementation details method are
| not necessarily connected in any way...something that in my
| opinion many engineers should think about more often.
|
| You can make a lot of money on sophisticated custom technology,
| or you can make a lot of money with very little technology or
| even white-labeling someone else's technology.
|
| Every business should focus on the basic value proposition on for
| their business and product and make decisions that support it.
|
| How do we make money, and where is the best place for our time to
| be invested to make more money? That's it, that's the only
| question there is.
| reureu wrote:
| I've been pitched on no-code data solutions in healthcare for
| over a decade, and it never seems to work out. At least in that
| space, people confuse who their main audience is: I don't want to
| use a no-code solution because I can code, and most of my
| stakeholders won't use a no-code solution because it wasn't code
| that was their barrier (it was time, specialization, analytic
| skills-- that's why they hire me). So I just watch vendors pitch
| me on how much easier my life would be if I could drag and drop
| analytic pipelines (lol, no.), or I watch them pitch doctors on
| how they can train their own machine learning models.
| cm2012 wrote:
| Zapier is a god-tier tool for all kinds of corporate work, and
| companies that ban it for "security" reasons are shooting
| themselves in the foot.
| twiddling wrote:
| Has been the challenge of Shadow IT since the glass house days.
| jrvarela56 wrote:
| Assembly -> ... -> Ruby -> Rails -> -> UIs to deal with framework
| abstractions
|
| I think the 'no code' is just a marketing term to explain
| something that everyone here is familiar with: the tradeoffs of
| building with abstractions.
|
| On the one hand, powerful abstractions to build-a-blog-
| in-15-mins. On the other, the decrease in flex/extensibility and
| the maintenance pains that come with using tools in unintended
| ways.
|
| We'll get to a stage where we can build with VR-think-about-a-
| component-and-see-it-appear or w/e but we all know there's always
| inherent complexity that eventually requires going under the hood
| or just straight up reimplementing.
| nnoitra wrote:
| I'm fundamentally opposed to outsourcing myself or other
| engineers either now or in the future either to AI or to no-code
| tools. I don't like the way this industry treats their employees
| in general nor am I very fond of the idea of using engineers to
| create a tool to make them obsolate. No thanks.
| readme wrote:
| the shift already happened -- the shift is that software ate all
| the CRUD business processes that could possibly exist
|
| if you want to build something cool now it had better do more
| than update a database
| omarhaneef wrote:
| I mostly agree, but I suspect not all CRUD businesses have been
| eaten. The ones that have been eaten have the following
| property:
|
| -- You have to enter the information in yourself, or your
| equipment currently captures it for you
|
| There are still CRUD opportunities where you find, capture and
| enter the information on behalf of the user. The phone captures
| a lot of data, so all that is already CRUDed up, but if you had
| novel data -- say from a wearable device -- you could still
| produce a new CRUD for that.
|
| I think this is why hardware is hot again. It allows us to
| automatically capture new data that isn't already captured by
| the phone.
| nisegami wrote:
| I propose the following statements:
|
| 1. Reducing complexity by reducing capability/power is easy. 2.
| Moving complexity from one form to another is easy.
|
| The biggest issue is that these limitations are not well
| understood by the end users of these products. Inevitably, they
| want something that the product didn't account for and have to
| grapple either with the complexity inherent in doing it or come
| to terms with not being able to do it.
| hospadar wrote:
| I was wondering if there was any similar conversation going on
| way way back when compilers were a new thing - found this gem by
| Grace Hopper (1958) (yeah THAT Grace Hopper).
|
| https://pubs.acs.org/doi/pdf/10.1021/ie50587a038
|
| She's talking about the difference between "programmer" (one who
| designs logic and processes) from "coder" (one who converts those
| processes to "codes" - i.e. assembly) and how compilers have the
| potential to eliminate the need for "coders"
|
| I'm tickled by the (IMO) obvious parallels that have just moved
| up a few levels in complexity us who use text editors to write
| programs are often supporting configurable logic for someone
| downstream who can get work done with less complexity using
| simpler, more accessible tools.
| donquichotte wrote:
| > Is this a paradigm shift?
|
| Graphical "low-code" programming has been around for a long time
| in e.g. the control systems community, where people typically
| have strong math am physics backgrounds (e.g., knowledge of
| vehicle dynamics), but little experience with programming or
| software engineering.
|
| Matlab Simulink and LabVIEW are well-known products that offer a
| low code approach to these fields. Large and complex projects are
| done with these tools.
|
| IMO the complexity is shifted from interacting with the hardware
| to wrestling with the tools, e.g. version control, knowing what
| happens exactly and cooperation is really hard.
| seltzered_ wrote:
| I would like to hear more from people wrestling with labVIEW
| projects of sufficient complexity. My (albeit decade-ago)
| experience is they lack the communities and subtoolings and
| things break at a point of complexity, thus the "wrestling with
| the tools" that could help clean things up gets harder when
| using a no-code flow-based environment.
| blablabla123 wrote:
| Actually part of the LHC collider is programmed in LabView.
|
| https://www.apexwaves.com/blog/using-nis-pxi-hardware-to-
| con...
| kristiandupont wrote:
| I tweeted this (https://twitter.com/kristiandupont/status/1362698
| 30566755123...):
|
| The thing with no-code is that there is still code. Only now it
| doesn't live in git but in a magic ether between sites and
| services, and in the head of that ex-employee who set it up two
| years ago.
| indymike wrote:
| I just added a no-code to our product instead of a scripting
| language. So far, users really like it.
| mlboss wrote:
| Ideal no-code solution would be that can talk to users, convert
| user stories to code, debug/fix code that broke production server
| and can make sense of new/existing technologies. Anything other
| than that is just abstraction over already existing code.
| hackerbrother wrote:
| I think if someone made a decent auto-fullstack-web-CRUD app they
| would be very rich and would have solved a lot of no-code
| problems and saved us an amazing number of man-hours on internal
| tools.
|
| Just: SQL tables, prettified CRUD on those SQL tables on the
| frontend (with R/W permissions per user on tables), and reports
| (either on-the-fly or SQL queries run on a cron schedule).
| throwaway1777 wrote:
| Lots of startups attempting this, two big ones being Retool and
| Airtable doing almost exactly what you describe.
| codegeek wrote:
| Ms-Access says Hello :)
| WJW wrote:
| Isn't that just basically Rails? It has a (pretty good) built-
| in ORM, prettified CRUD on any of the tables managed through
| that ORM and making SQL queries on a cron schedule is possible
| through Rake tasks, which come preinstalled with the framework.
| dragonwriter wrote:
| > Just: SQL tables, prettified CRUD on those SQL tables on the
| frontend (with R/W permissions per user on tables), and reports
| (either on-the-fly or SQL queries run on a cron schedule).
|
| Supabase is pretty much the backend piece of this (built around
| PostgREST), all it needs is a frontend generator that fits with
| its DB conventions.
| waxdotrun wrote:
| We're (https://www.wax.run/) doing this. We expose a CRUD app
| for your existing database in Google Sheets. You can also call
| custom Python for anything not covered by SQL.
| worik wrote:
| I hate it.
|
| Some time (not long) ago I was working remotely on some software
| that was driven by an API on a remote server maintained by some
| folks in a different country. A long way from me.
|
| Cutting a long story short I realised that the lack of control
| over the server was because they really did not know how it
| worked, or how to fix it or diagnose issues their server was
| having.
|
| It was a laraval/MS-SQL system built from building blocks
| supplied by Microsoft. They wired all the blocks together in a
| GUI and look! It works!
|
| * Putting images into a UU-encoded text field worked for images
| <7MB... The actual images the customers want are >10MB
|
| * Low levels of activity it was reliable. Under load it randomly
| dropped sessions.
|
| * They did not seem to know what logging was, or how to use it. I
| was supplying them with problem reports, carefully noting the
| time - and getting ghosted. I realised they had no way of knowing
| what their software was doing, or did. They could only set it up
| to do what they hoped.
|
| * The stored times as wall clock time strings
| "2019-02-12T03:02:12.123" No time zone included. Time series data
| worth a lot of money. "What happens when daylight savings repeats
| an hour or skips one?" I asked. No answer. This infected the
| whole system. I spent a lot of time fighting dates, and was that
| in the past? Future? Is that supposed to be now?
|
| Back in 1997 we had more reliable, and higher quality software,
| on a telehoused 486 Apache/Perl/Postgres system. But we compiled
| it from source and edited the configuration files by hand.
|
| "No code" might be OK for Aunties cookie recipes, but for
| building infrastructure it is rot
| zwieback wrote:
| I've been writing code for 40 years and doubt that no-code will
| generally take over any time soon. In my field I've seen
| environments like LabView take over certain niches but also
| painfully aware of their shortcomings.
|
| On the flip side, my wife and I ran a home bakery for a while and
| I LOVED the website builder we used. Click, click, click - full
| integration with credit card processing, email handling, etc. No
| way I'd sit there at night hand building a website.
| lewisjoe wrote:
| https://writer.zohopublic.com/writer/published/kiaow0e244617...
|
| Just wrote this piece putting down my thoughts on what I call
| domain driven no-code platforms.
| tqwhite wrote:
| I have been a professional programmer for forty years. In the
| eighties, there was a no-code desktop relational database
| application called Helix. I continue to think that it belongs on
| the same shelf as Excel in the UI hall of fame.
|
| Like Excel, people made applications with it. Unlike Excel, it
| created a server product in the mid-eighties that allowed it to
| become an IT platform. Small business owners who had hacked up a
| Helix database to help with invoicing were able to extend the
| function to the entire organization without ever using a keyboard
| for anything except typing label names on reports. All drag-and-
| drop icon stuff.
|
| Fast forward twenty-five years. Today the applications have grown
| and grown and grown. The owners who created them are old,
| prosperous and tired of screwing around with it. Also, Helix is
| no longer well supported. These people are screwed.
|
| I consult for a few companies that use it. These apps are exact
| replicas of the brain process of the owner that made them without
| a single structured thought in sight. Even if Helix were a
| healthy platform, the apps are largely unmaintainable.
|
| They are also so complicated and so deeply integrated into the
| companies that they represent a horrible threat. They can't
| easily adapt to the modern world and will cost millions to
| replace.
|
| Which is to say, these no-code systems encourage amateurs to
| reach too far. I advise people against them.
| jrochkind1 wrote:
| I wonder if you could find any 'enterprise' system at a
| business of any size that's lasted 25 years, if it would have
| much the same problems. And if you can't find many enterprise
| systems that lasted 25 years, that says something to, in
| Helix's favor. (some of the ones you can are... COBOL I guess?)
| karmakaze wrote:
| It relates to a lot of things. One thing like telephone adoption
| "at this rate, everyone will need to be an operator" and then we
| had self-dial phones instead of switchboard operators. So for
| simple often done things people can do it themselves. For other
| rare/special things we can still call for an operator (we still
| have those right?)
|
| Another way to look at it is like computer architecture. We have
| technologies for holding data and impedance mismatches between
| them, so we make intermediary caches, integrated/hybrid devices
| and devices start blending to look like each other 3D
| XPoint/NVMe. On another scale a Facebook datacentre can look like
| a macroscale computer architecture. My point is that
| 'programming' and programmers started out being one thing, but
| there will be many different forms of this at many levels, in
| various vertical areas. We already have specialized platform
| (Shopify) programmers, and self-serve (Zapier/Airtable) and even
| among those there could be third-party helpers as has happened
| around Google sheets data collectors/analyzers. Lo-code/no-code
| is so many things. It comes back to 'any sufficiently capable
| configuration schema becomes a lisp'. People want to tweak, so
| they learn to program.
| leephillips wrote:
| > (we still have those right?)
|
| I think there might still be operators to help setting up a
| call with a deaf person. Other than that, I had kind of assumed
| that the concept was obsolete. What would you need an operator
| for?
| baby wrote:
| Frontpage, dreamweaver, joomla, wordpress, etc.
| paxys wrote:
| While no-code tools have existed forever, the difference is now
| they have finally found their niche - workflow automation for mid
| to large sized companies.
|
| I have personally seen entire departments move from pen and paper
| to off-the-shelf boxed software to SaaS and now to no-code apps.
| You can finally customize your software exactly how you like
| without hiring a team of developers, and that's a great thing.
| cynusx wrote:
| Which no-code apps have this ability? the ones I know are
| rather basic
| cirgue wrote:
| My hot take: No Code, from a non dev perspective, is just a
| really user hostile config interface.
| zulban wrote:
| People who cannot code get excited about technology trends and
| then have a fantasy that they can participate without working
| hard. It's called "no-code".
|
| There's tons of advanced software tools on computers that do
| amazing things without code. We don't call it "no-code", we just
| call it using a computer.
| xaduha wrote:
| Laugh all you want, but I genuinely believed that XML standards,
| yes those 'design by committee' standards like XForms, XProc,
| XPath/XQuery 3.0+ and just general web standards like XHTML 2.0
| could've been the future and a backbone of something that a lot
| of people could use and not just as customers.
|
| Not by writing XML by hand without proper tools, but using
| something built upon this, on an extensible, inter-operated web.
| Think using modern XMPP for messaging, instead of a zoo of
| messaging apps that can't talk to each other or Yahoo Pipes on
| steroids. But that's not the universe we live in and that's not
| the no-code we're talking about.
| colechristensen wrote:
| It's not new but an old idea which is a bit of a fad. People will
| try to take it too far and then realize it's not good for
| everything but the idea rightfully should get some increased
| mindshare.
|
| Code, especially these days, can get quite insanely complicated
| and pretty far from being a concise description of appearance and
| behavior. Fiddling with frameworks and libraries and language
| features instead of doing the thing you're actually trying to do
| has gotten to be too much and no-code fad is the response.
|
| It should also be an implicit call for "hey lets try to reduce
| complexity" but that is rarely listened for.
| niark wrote:
| In my experience, these tools have another - counter intuitive
| and often overlooked - strength. Their limitations.
|
| You want to handle this very specific edge case? With code, there
| is certainly a way to do this. It may take days, it may add
| unreasonable complexity. Nevertheless, someone (yourself?) will
| ask that this kinda insignificant edge case is properly handled.
| And won't take no for an answer.
|
| With a (too) limited << no code >> tool, maybe there really is no
| way to handle the edge case (or it would require code in a
| context that forbids it). Management (or yourself!) has no way to
| make someone fix this, and can just give up. Soon enough, there
| is no problem. Finally, you can live with the unhandled edge
| case! Ok, you'll just brief users. Ok they'll learn by themselves
| that they shouldn't do this.
|
| So sometimes, << no code >> tools can't solve a problem. Then the
| problem simply disappear. It helps with finding a 80-20,
| something good enough. Everyone can be focused on more important
| stuff.
| WA wrote:
| I mean, what is programming? It's describing the rules of a
| system and all edge cases. For some stuff it makes sense to
| combine rule descriptions into Lego blocks. At some point, the
| Lego blocks become too big to be useful and you need fine-grained
| control over the rules you want to implement.
|
| If you can combine big Lego blocks into something useful, that
| sounds great.
|
| If you need more fine-grained control, you need smaller blocks.
|
| And that is the spectrum from assembly to higher level languages
| to platforms to libraries to frameworks to low-code tools to no-
| code tools. Pick what works for your use-case.
| booleandilemma wrote:
| I think this particular paradigm shift happens every 15 to 20
| years :)
|
| Even in the event of a perfect "no code" era, i.e. a future where
| we speak to the computer and tell it what we want it to do, we'd
| still have programmers. They just would be doing the job very
| differently. Maybe we wouldn't even call them programmers at that
| point. But the job would be there.
|
| Complexity will never go away and you'll always need someone to
| manage it. That's life, that's reality.
| osrec wrote:
| It's okay, but by its very nature, it's not as flexible as code.
| Often I see an argument describing low-code tools as "Pareto
| efficient", but even that turns out to be a false economy once
| your use case becomes a little more complex.
|
| Generally speaking, if you're doing something beyond building a
| simple form or table, and have some serious business logic to
| implement, in my experience, code is the only way to go. Anything
| else feels somewhat sub-optimal.
| cynusx wrote:
| I think most no-code solutions fail to think about what happens
| when a software engineer turns out to be needed after all.
|
| It makes it easy for really simple websites/apps to be built, but
| the reality is that business people have no idea of how complex
| something can be and after they started using no-code tools they
| hit a hard wall of having to rebuild everything with a real
| software developer.
|
| In reality though it would be nice if there's a solid hand-off
| between no-code and the "properly build and tested" world.
|
| That said, they can be good for prototyping or brochure
| apps/websites that just serve information and have some forms.
| coding123 wrote:
| I've been waiting for a (popular) low-code movement to hit the
| backend. Right now we still seem to start every project with -
| auth,connections,server, etc..
|
| Something like https://github.com/oshalygin/gqlgen-pg-todo-
| example but easier and more tied into everything already.
|
| Effectively instead of hand coding up the stack, there would be
| this server that you install and you get auth (implying a user
| model), GQL, and all you have to do is make the database and
| define a special file that tells the DB what is viewable or
| restricted and how that connects to the user.
|
| The package would be 100% open source but would have like modules
| you could enable to connect it to auth0 (or others) or use a pre-
| created schema.
|
| That's the stuff that should have been turned to low code by now
| and I still don't see much progress.
| dna_polymerase wrote:
| Everything about no-code screams vendor lockin. It's stupid and
| I'd never use or recommend these things.
| petems wrote:
| There are many open-source no-code tools so you can gain full
| control over your data/application with them as well as
| contribute into the source code.
|
| For instance, you can deploy an admin panel with
| https://www.getmotoradmin.com/ (plug) and save a lot of time on
| building custom internal tools.
| recursivedoubts wrote:
| Nocode has its place, and the problem area it can reasonably
| address will grow over time, but at the end of the day good
| automation requires the same thing any other software system
| requires: complex logic and, therefore, tests.
|
| Code is going to be the most efficient way to express and verify
| that logic.
| bdavisx wrote:
| Someday it might happen, but the problem is being specific
| enough:
|
| https://i.redd.it/s140v80nmc561.png
| heywherelogingo wrote:
| Fusion. Artificial general intelligence.
| sysadm1n wrote:
| I asked this a few hours ago here:
| https://news.ycombinator.com/item?id=29187754
|
| Here's my take, quoted from my thread:
|
| I've slowly started appreciating the nocode / low-code movement.
| At first: I thought it was a lazy person's dream, but more and
| more I realize a lot of the low hanging fruit that you can do
| with code has been done and there's little left to make. I mean,
| why bother re-invent the wheel right? So now I just leverage
| software made by other people typically GUIs / point-and-click
| tools and a bunch of online services to automate burdensome
| tasks.
|
| I still write simple one-liner helper scripts in my free time
| though, typically userscripts that I place into
| Tampermonkey/Violentmonkey to automate a bunch of stuff and make
| the web more accessible. I call this 'low code' so I'm not
| entirely reliant on GUIs.
|
| What's your thought on the movement? Do you like the term
| 'nocode'?
| wonderwonder wrote:
| I have been a software engineer for a long time, C++ for the
| first half, and web development for the second. Recently I took a
| job as a contract developer for a large no code company. I had no
| idea what to expect and thought I was going to be limited to
| creating toy UI apps. I have been blown away at what I can
| accomplish in this platform. Virtually anything that can be done
| by a software engineer via languages like PHP (with some very
| definite exceptions / limits of course), Javascript, etc. can be
| done via the no code platform. Integrating with virtually any API
| takes seconds and they dont have to be pre built, I can
| essentially take any open api endpoint and get and send data to
| in in a minute (after I understand the API parameters, etc.) SSO
| integration, Parsing JSONS, complex data filtering, database
| queries, creating forms, saving data, creating work flow
| processes, relatively complex server side calculations, you name
| it, it can be done. It allows for the use of excel and lodash
| functions as well against data although that is pushing the "No
| Code" concept, Essentially anything I have done in my prior web
| development work, I can do on this platform. Some things take a
| little figuring out and there are some lengthy chaining of
| components but it works. No code is not a toy anymore, it is a
| legit technology and while it definitely takes some engineer
| level thinking sometimes, it very much works.
| nebula8804 wrote:
| Can you suggest some tools that you really like in this space?
| You got me intrigued about automatically integrating an API. I
| want to do this + small amounts of scraping for side projects
| but even as a 'developer' I cannot drag myself to start the IDE
| after hours so many project ideas just languish in the back of
| my head.
|
| EDIT: oh sorry you posted the response just as soon as I posed
| this question. What a coincidence!
| tcrow wrote:
| Sounds a lot like the platform i've been working in for the
| last year or so (coming from a pretty hard code software
| engineering background for the last 15 years) and continually
| finding it surprisingly capable. Do you mind to share the name
| of the platform?
| wonderwonder wrote:
| ---Redacted---
| nebula8804 wrote:
| Darn, it seems like they are not something a regular
| consumer can just buy and use. Guessing something that good
| wouldn't be appropriate for consumer environments. :/
| tcrow wrote:
| dang, I missed it, would you mind to PM me?
| tegiddrone wrote:
| Yeah, I tried to get on this wave of (no|low)-code to enable non-
| devs to prototype their ideas. Turns out they run into "counter-
| intuitive" things when modeling your data and ones mental models
| have to be redeveloped.. and the query languages (like bubble)
| get pretty abstract fast. Future AI driven prototyping may be
| interesting. For now lets get back to "medium-code": rails,
| django, airtable/baserow, canonic, firebase, etc.
| rozenmd wrote:
| From what I've seen close-up in the indiehacker community, it's
| shifted the goal-posts of what an MVP is.
|
| You used to be able to get away with a landing page with just a
| form to collect email addresses - now you need a hell of a lot
| more polish to get started.
___________________________________________________________________
(page generated 2021-11-11 23:01 UTC)