You can, but I have not seen tools that actually do. My issue is that I develop a graphical node-based programming language and I'd like to be able to see diffs. I thought that I could convert our format into some other form and use a diff tool for that format.
Right, the problem with developing a completely new programming language is that you need to also create new support tooling for all the ways in which it is different. That's one of the reasons most programming languages are so similar: it's just less work that way.
If you use text as a storage medium, you can reuse diff, grep, sed and other text-based tools. They won't be perfectly adapted to the language semantics, but good enough. Debugging with gdb is a similar situation: if you include DWARF in compiled binaries it works, otherwise your language needs its own debugger.
I think the best thing you could do is to convert your graph into some common format like dot and create a generic diff tool for that format to make it easier for the next person with similar needs.
We are using xml underneath, the problem is that since the graph can be cyclical the nodes and links are in separate lists, which makes a standard diff quite a poor tool. As you say, converting to dot and making a tool for that is probably the way to go. I was just hoping that I could do just the first step. I was thinking about SVG as well, but in that case the diff would have to be very specifically tailored and not much of a reusable brick.
There is this product called Labview that does visual programing. I am not a huge fan because its just easier personally to write c code. Does everyone just want picture books. Plenty of people like normal books. I think Code is just more concise to understand. There are probably plenty of people who feel the same way.
Oh man do I hate Labview. I used everything else when possible including C, python with C bindings, and even MatLab compiling into C to give direct equipment directions. But that being said it is just my (and it seems like your) preference. I had several peers who were significantly better at getting the whole lab collection, processing, and output process up and running quickly and efficiently and they did not know how to code. I think there is a space for "no code" tools. Of course there will be someone on the back working with code but visual tools help lower that barrier for individuals with other skills than coding.
I don't think that either LabVIEW or C are particularly well-designed programming languages but the problems with LabVIEW aren't because it's visual. Visual programming does not make the problem of writing complex algorithms go away, but it does have other advantages.
No it's not. For some reason, people with no SW background tend to under-estimate the complexity of seemingly simple business rules and their interactions.
Exactly. And that's my primary argument when I tell people they should learn some basic programming - because it can quickly make you realize just how imprecise the day-to-day human thinking and communication is.
The Future of Selling Stuff to Enterprisey Places is Showing Them Slick No Code Interfaces and Persuading Them It Will Allow Ordinary Users To Get Things Done
(but there will be severe limitations and in practice the users will end up logging calls to IT support)
This is either just very misinformed or selling things to misinformed people. The fundamental problem is the inherent complexity in all but the simplest information systems.
The skill set required for managing that complexity is basically the same as for a software developer - and software developers have developed their preferred tools for manage it, and the relevant reason that the tools are not better than they are is that it's hard to build good tools, not that software developers are inept for the task.
I'm not saying that the tools can not be improved, but I'm saying that the tools won't be graphical.
More intuitive prototyping tools are another thing though - I'm all for it.
I think the same can be applied to Cucumber testing: having to write “natural language” tests in one area and then a bunch more code to interpret that dialect.
Why not express tests directly in code like everyone else instead of pretending business people will ever write them, understand them or know their limitations? Cuke seems like extra busywork job security rather than GTD.
Despite plenty of experience to the contrary, I'm still a believer that there's some way to disentangle what needs to be done from how it needs to be done. I do think the business people have to understand what they're asking for, and how to tell whether they've got it. I don't think many of them are going to learn code to do it. Maybe there are documents out there, somewhere, that unambiguously describe what business people want and whether they've gotten it, but until I see those mythical creatures, I'm willing to cut Cuke some slack.
Cucumber did get one idea right though - enforcing a separation of concerns between a high level non-turing complete specification and turing complete code that executes it.
Gherkin just isn't a great language to demonstrate the benefits of that.
Oh man, that hurts to read. That's some wishful thinking there. I'm currently helping a division of the Air Force replace a legacy flash application that they've spent years trying to keep going.
“Rather than having to pay upfront, even the smallest startup could access technology that rivalled what a large enterprise had available to them.“
This assumption seems wrong to me and I’ll even suggest the exact opposite. Cloud software has traditionally been cumbersome since its the one size fits all approach. With the advent of the cloud, people were willing to sacrifice functionality for convenience. Now that everything is in the cloud this is not true anymore and we’re starting to see pushback at all levels. Almost every company has a different workflow that only custom software can serve best. This is why companies with more resources will win at the software game; assuming they know how to play. Molding software to your workflow is always better than changing your workflow to accommodate software.
They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche. And they still need real programming languages and software engineers to help them overcome their problems when they try to scale, extend, or encounter a problem that's too complicated.
There are two things here. The first is sometimes programming languages are harder than they have to be and the other is that sometimes problems are hard.
1) Yeah, C++ is really complicated and you could probably replace it with language that was less complicated, but if you're trying to do something in the C++ problem space then you're still going to require a lot of difficult thought with respect to your problem, your solution, and the machine it's implemented on. You're not going to get away from writing driver code with a no code solution.
2) If you want to do arbitrary things, then eventually you'll need something that's turing complete (or really close to it if you're going to talk about things like Idris or Agda). A no code solution might be able to handle things as long as you follow a very carefully constructed path, but eventually your users are going to have reasonable requests that no code solutions won't be able to solve because if they could they would just be programming languages unto themselves.
If you're telling me that eventually CRUD apps will be mostly automated away, then I believe you. If you're telling me that eventually software engineers won't be needed then I'll see you in line at the unemployment office because the last two jobs to be made obsolete are software engineers and youtube personalities (and last I checked they're working on automating youtube personalities).
If you're telling me that eventually software engineers won't be needed then I'll see you in line at the unemployment office because the last two jobs to be made obsolete are software engineers and youtube personalities
lol, love that! I'm not afraid, if it is to be, so be it, I'll just work on how to grow my own twinkies from a personal garden.
I agree with you but what I would add is that what programmers miss is that there is a continuum between how much the underlying rules of the system can be changed and knowing when to expose these is actually your job as a programmer.
For example, users can always change a URL. This has allowed companies like Twitter to give a little URL-UI (UUI) to help power users while still letting normal people type in the search field. Way on the other end of the spectrum is a tool like Microsoft Excel where there is practically no limit to what a pro can do. Somewhere in the middle would be a sort of table-based design where admins could add simple rules (like layered tax rates, minimum requirements, or when a price change goes live) without needing to do a code deploy.
> If you're telling me that eventually CRUD apps will be mostly automated away, then I believe you.
Don't. Read "worse is better" again. In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.
People who wouldn't know code from Welsh English made databases for libraries, of their CD/DVD collections/... just for fun even.
Today, that doesn't happen anymore. And the web frameworks we currently use for that by and large don't work on mobile and even those are losing in the marketplace for reasons I can't understand, but there is a new javascript framework we just GOT to use. CRUD apps these days ... need a web interface, an android one, an ios one, and more. Minimum number of programming languages required: Javascript, Java/Kotlin, ObjC/Swift, and a backend language (can't use Java for that ... that would make ... euhm ... that would make sense ? And yes, you could use even Javascript, but ... so let's use Python ... or Go).
And let's just not mention that such absolutely basic things as a data table that were lowest-common-denominator are now exceptional. Sorting by every column ? Rarely happens. Having all data in a single listbox with search, filter, and rapid scrolling ? Unheard of (because very impractical on the web).
So no worries about programmer jobs. Ever simpler things will require ever more programmers. Worry about enjoying programming.
> In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.
Because CRUD apps were for one platform, running purely locally, not dealing with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, resolutions and orientations, or in arbitrary human languages. I think you underestimate the scope of modern CRUD applications.
A lot of that is self-inflicted complexity and following latest business trends (read: mostly hype). Things like opting for distributed cluster and map-reduce where a couple of unix commands piped together, running on a mid-tier laptop would do. Things like going with the latest and greatest web framework, that incidentally pulls in 5-layers deep stack and thousands of dependencies into your workflow.
Also related is typical business optimization - which usually means externalizing costs to users. Like, "CRUD apps were for one platform" - the cost of doing them for multiple platforms is at worst linear with the number of platforms, and most of that cost can be moved to a constant factor if you design your architecture correctly. It's a big deal, but it's not always that big of a deal. And contemporary alternatives result in applications sorta-working on multiple platforms at the price of one, but having half (or less) functionality.
The framework is intended as complexity management. Instead of picking each of 20 components each of which has 7 choices with different tradeoffs and figuring out which subset of choices delivers an acceptable complete picture just read how to use the components we have picked for you in a suggested fashion.
The result may be complicated under the hood but may be easier to operate as well.
Problem is, this often backfires - you end up using 5% of the power of the framework, but spending 95% of the dev time fighting it to achieve what you really want.
In my experience, a wildly suitable framework for one person will almost certainly be wildly unsuitable for someone else, especially if that framework is especially opinionated. Appealing to every use case would mean a proliferation of frameworks with very subtle differences, leaving a prospective user entirely confused about which one to use.
That's not to say that there's no place for frameworks, but it is to say that there's value to being able to piece together the equivalent functionality (or at least the critical subset thereof) from unopinionated "do one thing and do it well" components with relative ease and minimal pain.
Unfortunately, "picking a framework" for which "working with it as it's intended to be used" actually matches with the user's intentions tends to be the excruciatingly difficult part. Best-case: the user happens to find the perfect framework for one's use-case. Common-case: the user gets by on hacking the framework to do one's bidding, regardless of how it's intended to be used, because the user can't find one that actually satisfies the user's requirements.
See also: the proliferation of Excel spreadsheets driving business logic pretty much everywhere outside of Silicon Valley (and in some cases even within).
I don't see the relationship there... end users choose Excel because it's the only thing that's available to them. For a professional programmer you should not only have better judgment but also have some familiarity with the frameworks available for what you want to do.
In the late 1990s IBM Lotus Notes / Domino ran on multiple platforms and worked fine for CRUD applications with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, and multiple human languages. The underlying architecture was a bit ugly but it worked.
As an industry we have absolutely regressed in many ways. Web application make distribution easy but almost everything else is worse.
I just love the dichotomy on HN where you get one article: “The Future of Software Is No Code” and another “Why it took a long time to build the tiny link preview on Wikipedia,” these two are seemingly orthogonal in my mind.
I believe even in the context of mathematics orthogonal means independence. I.e., one can move along x and y axis without having y or x value being changed. However if you move along any line that's not parallel to x or y axis then both x and y value change simultaneously. That's how I interpret orthogonality in the context of math anyway.
As long as you don't rely on concepts that don't generalize to higher dimensions. To the extent that you use concepts that don't generalize in your example, you are using a poor example.
The real reason it took so long was buried in the comments: the community was unwilling to accept a sub-par solution at all.
And if your requirements are very steep, you're probably not going to get away from code, but if your goal is to build something quickly and make a few compromises, then maybe No-Code approaches are for you.
I have been hopeful for this for a long time - it's not so much that I expect it to stop the need for a developer, but rather that it will allow a developer and domain expert to work together more efficiently.
The ideal case, in my mind, is a case where apps can scale. A user needs a simple tool, so they build it in a UX-friendly way, which has limitations but can reach some basic data sources and can do some basic CRUD.
Then, the user starts reaching a point where they need to scale. Then, something like VBA can be written by the user or by some developer, and tied into the UX. Indices can be added to the database, and to a DBA it looks like any other CRUD app. Views and materialized views can be used to add information from other parts of the database.
If there's one difficult part, the system can call a service that has access to the database and can do computing more directly, communicating through a standardized JSON system. (Perhaps something like JSON API.)
Then, the tool starts getting popular, and is straining at the seams. Instead of having to create an entirely new project, the project can be exported using a translation layer to a pure programming language, with tests built automatically. Developers can then take it in any direction necessary.
The biggest problem is that it's hard to progressively scale small apps - every time a small tool created outside IT gets created, it expands until it starts being dangerous - excel anyone? - and then IT is brought in to build a full scale system that solves all the problems. IT then gets angry at the users for creating a useful tool instead of getting dragged out into the funding-design-create-test-bugfix process.
And that's why the No Code sounds so appealing. It's a structural PITA to scratch your own itch.
We have had this in the DSP field since the 1990s with pure data, and before that the closed source Max, now a part of Ableton Live 10. Faust is another example of a graphical coding tool for DSP, in the case of Faust you can export C++ that you then include in a larger C++ based application.
These kinds of tools are only viable for their narrow problem domains. Code will always rule for general purpose development. At least until AIs are good enough to produce usable results from a problem description.
Electrical Engineering has already trod this path. Before HDLs became good enough for logic synthesis, FPGAs and ASICs were developed with schematics or manually mapping circuits into the target architecture. That process doesn't scale well as you end up wrangling with 2D spatial representations and constantly fiddling with low level details. Now, HDLs are the primary means of developing such hardware and the vertical tools are limited to specific data processing niches where there is some productivity advantage in reusing established design methodologies.
Hmm, yeah I'm similarly skeptical as someone who did his fair share of LabVIEW for a research lab back in the day.
I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code. More than a few programs basically became wrappers around C libraries.
That's to say nothing about the unwieldy LabVIEW monstrosities that I'd regularly get asked to take a look at because they were complicated as hell. Massive programs, mostly because of copying and pasting. While you can wrap things up in functions and subroutines and etc., you have to know that you should do that. And I certainly can't blame a research scientist for not knowing that - it's not really their job to.
Fundamental software concepts like DRY don't disappear just because you're using a visual language.
> I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code.
Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms?
(a) doesn't bother me as using a low-level language for low level tasks is a perfectly reasonable thing to do.
> While you can wrap things up in functions and subroutines and etc., you have to know that you should do that.
If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.
> Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms?
It's high-level in the sense that you program by choosing a set of components. A very apt analogy might be Excel and VBA: It would be extremely difficult (if not impossible) to accomplish some tasks using Excel, and if you're using Excel as a "programming language" you will find yourself reaching for VBA to do certain arbitrary tasks.
> If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.
Sure, but saying people should do x is basically absolving yourself of the problem and throwing your hands up in the air. They don't do x, so it's sometimes our job to figure out why they don't x and how we can encourage people to do x over time.
LabVIEW is very much presented informally as "program without learning how to program" (very similar to the article), so people using it don't feel as though they should have to learn basic programming fundamentals.
Thanks for your reply. So, in practice (b). I had been led to believe the underlying language G was at least in theory general purpose though its libraries are specific to instrument control and similar applications.
I used LabVIEW for a few years. In my view, LabVIEW is as low level as you want it to be. It has some very low level operators. And it can handle algorithms as complex as you want them to be.
One of the first hurdles faced by all beginning programmers is "what to do when a program gets too big to fit on one screen," or to understand in one sitting, etc. We all know at least some basic solutions to this problem: Variable naming, subroutines, etc. When LabVIEW programs grow beyond a single screen, which happens quickly, it becomes very cumbersome to navigate through multiple windows and their different viewing modes. Since a program can have multiple entry points, it's hard to figure out what a program "does" in a top down fashion.
Second, there's the reason why so many of us went back to CLI and text editors after experiencing the wonders of the GUI. I think that doing complex work with GUI based tools becomes physically laborious to the point of being debilitating. I came away from my LabVIEW sessions with splitting eyestrain headaches and wrist fatigue.
The physical work involved in laying out code also discourages refactoring.
Maybe, oh maybe, there's something right about text based programming languages.
Or maybe LabVIEW needs a better editor/IDE. I very quickly gave up with Franz Lisp on a VAX running Berkeley Unix not because of any deficiency in the language but because I had to use vi to edit it.
There have been only two languages (Prograph and Max) with any similarity to LabVIEW which have gained significant numbers of users, so the space of visual dataflow languages hasn't been explored enough to write them all off.
LabVIEW was designed in the 1980s when nothing similar to base it on existed, and various design choices were committed to which didn't work out well. In the following decades, many advances in language design took place or were widely adopted and would be difficult to retrofit to an language of that era.
I've only read about LabVIEW, but I have a fair amount of experience designing another visual dataflow language, Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html).
In Full Metal Jacket's IDE, opening a function definition is done by right-clicking on its vertex (rectangle); connecting an output of one vertex to an input of a second vertex by dragging the mouse cursor in its general direction and releasing or, if the the second vertex is absent, right clicking on the output and dragging the vertex from another window. Hovering over a vertex displays its documentation string, hovering over inputs or outputs displays their types.
I adopted some ideas from functional programming languages - simple syntax from Lisp along with Gabriel's MIT approach, strong static typing with type inference from Haskell and ML, tagged data and a few other ideas from experimental dataflow hardware (I knew the people involved in this both at Cumbernauld and Manchester); and some vocabulary from graph theory. It was obvious to me very early on that there was no way anyone could honestly market dataflow languages at people who don't consider themselves programmers. Not only do you still need to design algorithms, you have to think in a completely new way.
Syntax is often too complicated, I agree. But to me, software development is not about learning syntax but about handling and understanding complexity. Good languages support handling complexity and I really don't see a future where complex software can be built without something supporting you in handling complex interactions between things.
But domain experts can handle complexity just fine, especially given right tools to help with domain driven design/DSL , abstracting, versioning, parameterizing, information hiding, reuse, modularity, and getting help from software engineers when needed).
And since there are easy to use examples of each of those in various categories, it's not impossible to imagine some tool will tie all of them together.
I think there's a third issue you didn't mention: Ecosystem/framework complexity.
Writing a device driver in C is complex, sure, but pretty much all that complexity comes from the problem domain. C++ adds a little more incidental complexity, but if you use it to write a device driver, you're still mostly fighting "how my computer talks to hardware" - and at least that's the correct fight to be having.
But if you're writing a CRUD app for the web, the incidental complexity is off the charts. Five different languages (HTML/JS/CSS/{Ruby|Python|Whatever}/SQL), three or more frameworks (Bootstrap/React/Redux/Django/SQLAlchemy)...and you haven't even deployed yet.
There should be a middle position between "impoverished pseudo programming language" and "here's your five-layer web stack, have fun". If your app is basically three "if" statements and a "for" loop with some UI on top, I agree that you should write those statements in a real programming language. But you shouldn't need three layers of framework on top, just to put them in front of a user!
I think this is what everyone is talking about when they bring up VB and Delphi in this thread. I don't think that "Delphi for the web" is an impossible goal - and I've put my money where my mouth is, by building a sane development platform for the web - https://anvil.works. You do everything in one language (Python), with proper tooling support (hello, autocomplete!), and skip the BS.
(On the other hand, perhaps this is what you meant by "CRUD apps will mostly be automated away". If so, it's only in the sense that my time is being "automated away" when I use a GCed language rather than malloc.)
Heh, SQL (formerly SEQUEL) is the 'structured English query language', designed to be simple enough for anyone who knows a bit of English - not unlike Cobol.
Yes sure, but when you start one language having to learn another just to store and retrieve data is a lot to ask.
And of course once you progress with your data needs you get into more complex aspects of the language where the simplicity of the language isn't as important as the concepts and ideas it does express.
AFAIK the idea was that SQL is so close to plain English that any accountant could simply use it to generate reports or enter data. It's really an old fallacy that using plain language would make complexity go away.
I disagree. I'd say that attempts to let end users do their work without 'programming' have succeeded marvelously. We've handled the 50% case, and then the remaining 50%, and repeated this process several times.
When I was a kid, I had to type a valid line of source code to load and launch an application (often two separate lines). Today I can literally touch a picture of it with my finger to do the same thing.
There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.
> There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.
And the end result of this is what? More or less code gets written? Is there a need for more or less programmers over time? What's the trend, do you think?
Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.
That's a great question, and I'm going to sidestep it a bit by saying I think the limiting factor isn't technology.
95% of the projects I've worked on have been some fairly simple permutation of ETLs, CMSs, and ops -- all of which are sufficiently constrained problem spaces that we've got good systems for them which work well without the need for Turing-complete programming languages.
But as long as we're constrained by legacy codebases, overly complex third-party APIs, and the need to maintain business models, we're not going to be able to make things as simple as we know they should be. It's not just services: I've got 100 legacy file formats on my disk, and they mostly are completely different and require different tools for no good reason.
I've wasted many months (years?) of my life figuring out how to plug the API from service X into the API for service Y and put the results on a simple webpage, with some CSS that a designer gave me. That's not the sort of thing that ought to require a Turing-complete programming language. It's almost all accidental complexity.
Someday we'll sort this all out, and then maybe we'll go on to discover some other unexplored area where we need lots of (Turing) programmers, or maybe we won't, but that's beyond the inflection point. Our next 50% barrier isn't technical, and as long as we've got artificial socioeconomic barriers in the way, I can't guess what's after that.
> Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.
Most "software" needs these days are business related. Legions of engineers are just adding minute variations to the same CRUD frameworks to make slightly different products. I think the kind of programming that goes into making a CRUD startup and the kind of programming that went into making a device driver in the '80s is very, very different.
I can imagine this being the future, but it's quite a long way off. I was thinking about this as I was doing some work in Python earlier today - back when I was working in C, variable-length lists and hash maps were so inconvenient that I often just convinced myself that fixed-length lists and sequential searches were "good enough" for the case at hand (and, often, I was right). With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack. That said - there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose. Even in that future world, there will be a need for "low-level" folks who can at least think in assembler when necessary - but I imagine that role will be more like that of a surgeon in meatspace.
> With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack
But these existed in programming languages before Python's inception, at least back to Lisp in the 60s. And newer languages like Go eschew some of the higher level flexibility of a Python on purpose.
Also, despite the widespread use of languages like Python, JS and Ruby, C/C++ and Java remain just as widely used as ever.
> there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose
I can think of lots of useful web applications today built by people with no knowledge of linked lists (or at least, they didn't need any such knowledge for those applications). The entire CMS market seems to exist to enable this.
> They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche.
I bet spreadsheets are the most common form of programming on the planet. So at best it takes over a very large niche, becomes entirely mainstream and we forget it's programming at all.
(Of course spreadsheets can use 'real' PLs, but most people only use the basic formulas and ranges.)
> They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche.
Exactly. Creating a "simpler programming" for business users, in the end, only creates a 2nd language the IT staff has to support. Even getting business users updating something as simple as a quality CMS is an uphill slog.
Another often unacknowledged reality about that - I suffered for three years in the "Salesforce" environment which bills itself as the be-all end-all "no more programmers" solution. In reality, it's clunky and limited, and even when non-programmers are able to get something that approximates what they want, it ends up being slower than molasses. That's when they call in a programmer to figure out what went wrong and it's usually something like re-running a complex DB query a thousand times to satisfy a simple request. And you can hardly blame the business users - they have no visibility into what they're doing, so it's completely understandable that they come up with an inefficient mess. If user-created software is ever going to be feasible, the back-end is not only going to have to translate their drag-and-drops into usable code, but it's also going to have to intelligently optimize: that is, infer what their goal is and find the most efficient way to achieve that goal. That alone should tell you how far we are away from a programmer-less future.
I feel like CRUD web apps are pretty much automated already. You load in React or Vue or whatever, then you just write CSS and HTML in a copy paste style where you're copying from your brain. In fact! The automation has gone so far that people even specialize in using these new automation tools.
Typically they're referred to as designers and web engineers.
This is not ‘no code’, anymore than someone programming in Python is doing ‘no code’ just because they aren’t programming in assembly.
A visual coding language is just providing a different abstraction, but it is still in the same space as other abstractions like a high level language such as Python.
Now, it might be hiding more behind the abstraction than a traditional high-level language, but that is a difference in degree and not kind. It does, however, mean that there are going to be more things that can’t be expressed in the visual language because the abstraction is too broad to be broken down enough. This means that a lot of the tasks that need to be done can’t use the abstraction and need a different programming language.
The way we make progress is by hiding more and more things under better and better abstractions. So this is the way forward - if the abstractions are better.
But there are two problems here. The first is that you can make better abstractions in text-based languages, too. In fact, it's easier to do there. So the visual coding language is always easily caught by text-based languages. They may be easier to use for the layman, but they don't offer anything extra to the professional.
The second problem is that abstractions always have limits. Good (useful) languages give you a way to escape from the abstractions when you need to. Evil languages sucker you in and then trap you in a too-limited abstraction from which you can't escape. (It's not just visual languages, either. The original Pascal, before the Turbo extensions, had exactly this problem.)
> The first is that you can make better abstractions in text-based languages, too.
Not always:
The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?
MIMD parallelism is straightforward with dataflow. (No worries about synchronization: processes wait until they've received all their inputs before running.) Again, shapes connected by arrows partially ordered in two dimensions is a more natural representation than text.
Finite state machines. Again, shapes connected by arrows is clearer.
>> The first is that you can make better abstractions in text-based languages, too.
>> Not always
Why are you writing and reading in text / code? Surprise, surprise - the English language is text / code. Please, to support your arguments send in some pictures or models or videos etc.
It's ongoing work, and visible progress has been slow over the past year or so. Recently I've been refactoring the code, and improving the type system. One thing worth noting is that representation of functions as a graphs makes type inference more straightforward.
English and other languages are text because our ears hear a single stream of speech and written languages reflect that. Historically, computer programs are single streams of instructions because computers have until recently had processors only capable of doing one thing at a time, and we've usually programmed with text (GRAIL and DRAKON being exceptions) because that's all most terminals could display.
But for finding your way around a city by subway, representing an electric circuit, an organic molecule, or an elementary particle interaction, we use diagrams.
> The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?
Oh yes. My company used a "visual" programming language for a workflow project and it's pretty much a directed graph with nodes -- the whole thing takes 50 printed pages to see the whole thing and is pretty much impossible to understand. And it's not even that complicated of a workflow.
> Finite state machines. Again, shapes connected by arrows is clearer.
I had a deja-vu reading this article, sounds just like the things that were promised in the 80s, then the 90s and probably other times I missed. There are periodic tides of centralization and decentralization washing over the IT world.
I do feel things are different this time around, though. SW distribution really has been significantly improved and there are much better ways of doing client/server applications now.
As to graphical app development UIs taking over programming - I have my doubts.
I also had a deja-vu moment. When I began to study CS a professor of us really tried to get us into electrical engineering instead of CS. His basic argument was, that in 10 years programmers will basically be unemployed or on the verge of it, because even nowdays there are visual code generators that can create better code than most programmers could. That was 2004 and I think he was referring to LabVIEW.
A lot of things have happened since then, but LabVIEW is still very much a niche application for a very specific domain. And code generators didn't magically abstract away integration, requirements optimization, scaling and architectural desision making.
> I had a deja-vu reading this article, sounds just like the things that were promised in the 80s, then the 90s and probably other times I missed
Even the Smalltalk environment in the 70s, sort of. Not in replacing code, but making an environment where any end user could create their own applications, so they wouldn't have to rely on programmers.
As far as I can tell, this is an advertisement for QuickBase.
I can't tell from this article or their homepage how they are replacing code, but it sounds like they're trying to fill the niche of Microsoft Excel and Access, letting a semi-technical user specify limited queries and behavior.
Letting more users access the data they need is a laudable goal, but of course there will always be some need for the kind of precisely specified behavior that you get from code. "The Future of Some Software Is No Code" might be a more appropriate title.
On one hand, it's a bit of a shame that the article focuses on "no code". What the linked applications all seem to do is a pretty standard package of workflow tooling, reporting generation and data source connectivity. If any of them do a better job than all the existing ones them good on them. In my experience, good tooling here is quite hard to come by and could be very useful/valuable.
On the other hand, on the odd occasion that I've had users buy a tool believing they're doing my job, it's ended up net positive for me. When it inevitably goes south, the reminder that what I do is actually harder than it looks has been beneficial. Obviously, I always get in writing that I wouldn't ever have to support their efforts at finger painting.
This reads like a promo piece for these companies. It's been tried many times and hasn't worked.
As a developer, I'd love anything that makes my job easier, but that usually is more control and explicitness. I think "always bet on text" is a more accurate future:
https://graydon2.dreamwidth.org/193447.html
I strongly agree. Text is just much more efficient in so many ways.
A tangent, this is related to why so many people - myself included - love the paradigm of Emacs as an OS, i.e. moving as much of their workflow and non-work tasks into the editor. It's because of - severely underexplored elsewhere - the power of the abstractions around text Emacs provides. When everything is text - including the UI - but the text isn't transient, like typically used in Unix, but at rest, like in text editors, you get to employ the same set of editing, navigation and search commands to do vastly different tasks. Combine with how so many things can be represented by text, and you get a very powerful tool.
Round and round we go. Textual code looks like the barrier when you start learning, but it's a boon when you've gotten past it. The big barriers to quality software are not typing or syntax, they're just the most visible from the outside.
Despite the goal being to "let anyone program", these tools rarely end up as more than toys. Why is that?
It's because learning to program is not a matter of learning syntax. If that was the barrier we'd have just put more effort into NLP and been done with it.
But traditional spoken/written languages are inadequate for the precision needed in programming, so we use more precise alternatives. The language is a tool that makes it easier to program, despite looking more intimidating from the outside.
That said, when you limit your domain you can make quality "codeless" tools. Shader Blueprints in Unreal come to mind as a good example. But a lot of the value they provide is in seeing the previews at every step because it's a very visual thing that you're making. And if you're hitting performance barriers, you'll probably need to rewrite it in text anyway.
Just because programming languages look scary from the outside does not mean that removing them will make programming easier. Most of the time it will make programming harder.
Precisely. As I frequently like to remind those around me (because I'm a total drag), "Coding isn't easy, but it's also not the hard part of programming".
I think this is the important distinction. These "codeless" tools really just shift the inherent complexities of software development instead of getting rid of them. Anecdotally, I had much harder time learning how to read/understand LabVIEW graphical "code" than I did learning C.
I used Unreal's Shader Blueprints as a positive example, but the more procedural Blueprints used in gameplay boggle my mind. I find them harder to read and much harder to write, and that's when they're well formatted.
Another point that I forgot to bring up is that graphical tools don't always let you setup functions, and when they do the added indirection usually makes them even more confusing. It makes it difficult to break out repeated logic and confusing to follow the code after you do break it out.
LabVIEW isn't a "codeless" tool. It's a programming language. It's very different from C (dataflow instead of imperative) and requires a different way of thinking.
Even simpler than that, most people simply aren't interested in programming. A lot of programmers seem to have difficulty comprehending this. As you say, there are of course barriers for many, but we can't continue with the premise that everyone could be a coder and would be a coder if X and Y were met.
I argue that programming languages are not complicated. Although most people butcher the English language, it's a far more complicated language than C, which has relatively few keywords and an unambiguous syntax. But programming languages, especially C, are tremendously repetitious and lack nuance because of the fact that they are so simple. Simplistic units in principle are really good at building different complex things, whereas things that are more complicated are usually better at articulating simpler ideas. No wonder nobody programs computers in English! A programming language that tries to meet parity with English, or any spoken language, would be an utter nightmare to deal with.
My point is that someone who has any innate interest in programming can make their way past the layer of intimidation, especially now more than ever with the sheer amount of information that didn't exist when I started coding. I remember when looking at code was intimidating because it didn't match my understanding of what a language was, and it was in the era of "Just F###ing Google It" when nobody on forums would help you, online documentation was terrible, and there was no Stack Overflow. Now, there is really almost nothing holding anyone back besides the will to do so.
There is a limited amount of things that most people are willing to learn. When one is hardly autodidactic, they will choose the path of least resistance and only learn when it is a necessity. When programming to any degree isn't a necessity for someone, they're not going to want to do it. Heck, sites like Wix and Squarespace are insanely easy to use, and I know people who want to make their own site for their business and drag their feet in using site builders because they find it annoying to understand what it even is they're doing when they're dragging around components. They don't want to have to learn, and would rather someone who is interested in building sites do the work for them.
What you describe certainly has been my experience. Many of the markup languages that were designed to make it possible for "non coders" to write interfaces just turned into another programming language, only clunky and irritating.
For example, tag libraries like the JSTL were designed to split the programming between interface and back end, allowing designers to manage the programming logic in the interface. HTML and markup tags were fine, but in my experience, once you get into loops, conditionals, and so forth, the designers almost always send it back over to the programmers, who now have to learn a new (and generally half assed, in my opinion) set of tags to implement programming logic. As I remember, they pushed this pretty hard (the head first books even devised a mock scenario where a corporate memo banned the use of JSP code in a page). Ruby on Rails went with ruby code and helpers, and I think it was vastly more successful. YMMV of course, but the experience led me to believe that if you're going to program, just use a programming language[1].
As for this article? Well, the sub title is: "It's accelerating how businesses are able to impact their strategy." So, we have a sense of what we're in for if we choose to keep reading.
Beyond that? Actually, I do think that things we used to write code for will be handled differently, and may not require programmers. This is nothing new for the industry. There was a time when a spreadsheet required a computing expert. Same for calculations, servers, publishing an article on what is now a "blog". Blogging engines totally accelerated how writers impacted their strategy.
[1] a lot of people don't quite understand the hype and, yeah, attitude of ruby and rails programmers in the early days. I do think this community went too far with it, but the scenario (a corporate memo banning something) does get at why. The java world had gotten sort of insane, and ultimately was starting to rely on things like memos from above because that was the only way to imagine why anyone would actually write the way the spec said. There really was a massive cheer when someone (DHH in this case) just finally put up a giant screen at a conference saying, literally, "fuck you". Although I think you can achieve with more civility, that kind of bluntness is necessary to beat back the insanity in this field every now and then.
> The reason we find ourselves Soft Coding is because we fear change. Not the normal Fear of Change, but the fear that the code we write will have to be changed as a result of a business rule change.
> It’s a pretty silly fear to have. The whole point of software (hence, the “soft”) is that it can change that it will change. The only way to insulate your software from business rule changes is to build a completely generic program that’s devoid of all business rules yet can implement any rule. Oh, and they’ve already built that tool. It’s called C++. And Java. And C#. And Basic. And, dare I say, COBOL.
Not only that, but writers around the world still use text to express their thoughts. And, 5000 years ago, they started with drawings. But, smart as they are, they realized it sucks, and that for anything beyond simple concepts, text is da best.
Oh man I can't wait to write my new tech in LEGO Mindstorms EV3 block code or Scratch or SIMULINK or literally just Visio drawings with a bunch of scripts on top.
It's a massive horrendous clunky pile of inextensible garbage 80% of the time. The only reason it's ever been wanted was so managers could visually see what you're doing and quite frankly as the person writing it I should be explaining it rather than them looking at it.
Yup. One of the most important things I've learned in my programming career is that reality is damn more complicated that it seems. At all levels - both physical and abstract.
The real problem is that humans imagine things and communicate them at very high abstraction levels, without filling in the levels below. Much like a children's drawing of a car is nowhere near detailed enough to serve as a blueprint for building one, our usual descriptions of stuff don't contain necessary details at all. If you want to build a real thing, all the work to fill in the lower levels of detail needs to be done. You can't magick it away. Today, that work is done 10% by the people writing specifications and 90% by programmers figuring things out. In the future it might be done by a computer - but that computer would necessarily need to be a human-level artificial intelligence, doing all the work programmers do to go from the way we communicate to a working program.
You don't fill all the lower levels of details. You're likely not caring about generated machine code, you're likely not caring about details of memory deallocation, you're likely not caring about Unicode quirks when you're comparing strings, you're likely not even aware which algorithm is used when you're multiplying two BigDecimals, you're likely not care which characters are allowed in HTTP header names, and so on and so on. A lot of implementation details are already implemented. There's no reason that programs won't be abstracted further away. Sure, it still is programming, but with less unnecessary details (so more people can do it).
Most programmers/developers don't deal with the problems that you mentioned on a day-to-day basis. They are already abstracted away, and most programmers/developers try to make sure that they deal with the actual problem at hand instead of repeating the same problem in each project. The actual problems are not going to get any easier. The abstraction levels will get higher, but the actual problems dealt with will not.
You're thinking of the lower-level details of the computer but the issue is the low-level details of the problem you're trying to solve. The amount of detail necessary to solve even the most basic business problem is far more than the average client can ever describe on their own.
All the computer abstractions help solve computer problems and in turn make it easier to implementation solutions but doesn't make the business problems any smaller.
Yes, what you describe is the point at which abstractions meet your problem from the bottom. You're not developing solutions yourself down to level of pure physics, but that's because we have a solid abstraction layer of digital computing. Your job is to work down from the problem idea until you connect to that layer.
It still doesn't change the fact that the surface area of that layer is enormous, and so is the space between it at the bottom and your problem at the top. All the details in between is what you need to figure out.
I'm not completely sure the bottom can be qualitatively raised very far up. The digital computing abstraction is a qualitative model change, from physics to mathematics. Experience suggests that when you decompose a business problem, the lowest algorithmic details very often end up on, or slightly above, that bottom layer - so you need the ability to work on that level. Of course, if you're willing to limit your scope and problem domain, then a lot of things can be abstracted further - but they won't generalize.
The fact that you can get Linux kernel developers who rail strongly and vehemently against compilers because the compiler optimized it against what you said, which wasn't what was wanted, strongly suggests that it's not a matter of precision.
More specifically, people generally have a vague idea of what they want. While you could explain a fully precise mathematical model that corresponds to that idea, people don't really have a good way to know if the model is correct or if there is some hidden corner case that causes problems. So they accept the model until they find one case where it was wrong.
It's hard to impart the true understanding of just how much details a real-world problem has without making someone try and solve some real-world problems.
Right on. What many, and especially this writer with his talk of tech being more "human" don't understand, is that code isn't a language _for computers_. It's a human language used to describe something unambiguously, to the point where it could be eventually interpreted as machine instructions.
People not understanding this has, in my experience, led to a lot of very bad decisions, especially around outsourcing. So many people in 2006 thought that American/Canadian developers would disappear in a few years as everything was outsourced. They didn't realise that writing a "comprehensive and precise spec" to send to a team of developers on the other side of the world, and have them implement _exactly_ what you asked them to, was actually creating more work.
I think it is a nice way to look at it. I always thought all people in all professions are trying to figure out some "code", just in different abstraction layers.
I mean, a lawyer learns the "code" of law. A psychologist learns the "code" of human, which has a lot of black boxes but one can still make partial sense of it.
The comic misses the point. Yes, it's still called "code", but as you point out, the abstraction layer moves another level up.
This is the whole point behind the reverence for "declarative programming" in the Erlang world (and probably others). Tell the computer what to do, not how to do it. The "how to do it" part should instead be the responsibility of the programming environment (which can - hopefully/ideally/eventually - do a better job than the programmer at organizing the "how" in a manner which appropriately balances efficiency and robustness).
I do believe that the majority of coding will be replaced by AI or some automated process requiring some inputs and expected results to "code" an application. However, this article reads like an advertisement, and it fails to go deeper into the topic at hand, unfortunately.
There is no such thing as "no code". You can hide it behind pretty interfaces but in the end, you are just using images instead of words.
And with images, people think of children books, easy, right? In reality, as soon as you introduce a tiny bit of complexity, it becomes closer to Chinese. In Chinese, you can still see the little drawings, but that's just the background of a highly complex language.
Whether you code in an English-like text based language or a proto-Chinese-like picture based language doesn't change the fact that you are coding. Most people end up preferring the "text" approach that is more adapted to computers, and ultimately easier.
At least 80% of Chinese characters are picto-phonetic -- meaning that you have a radical that only gives you a vague category for the lexical item and another part that gives you a hint of how to pronounce it (or would have when the character was devised, anyway; there's substantial drift). To think about this in terms of English, imagine the word "I" were written with a stick figure and a picture of an eye (except for most the meaning is a little more obscure than this). It's only a handful that are really like pictures.
There’s nuance in a spectrum between non-technical end-users developing simple workflows and forms, and trying to run an entire business on it with business rules, interoperability, standards, etc.
I worked at IBM back in Rational Rose's heyday (though not on the Rational team, thankfully). The sheer amount of configuration you'd inevitably end up doing was orders of magnitude greater than the actual thing you wanted to write.
As long as computational operations exist, there will need to be a language to represent those operations. As long as that exists, there will be more languages to streamline that, and so on and so forth.
Computers are not magic. They do not think. Even if they did, they would be constrained by the same fundamental linguistic bottlenecks that we human beings are.
To illustrate this point:
I will concede that no code solutions are possible when every human being achieves Buddhist Enlightenment.
This would be the human equivalent of a no code solution. No one communicating, or orchestrating external experiences to create an epiphany. Just an internal realignment of values.
Another illustration:
Convince all of your neighbors to agree with you without communicating to them in any way.
Coding is a fundamental axiom of information transfer. If you aren't doing it in some fashion, you aren't DOING anything. If you are doing it, then you are constrained by your encoding scheme. The thing that trips up most users is that they aren't consciously aware of their own encoding schemas, and are typically resistant to adopting someone else's. In the article's case, they are asserting that "visual" programming is not code.
Which is dead wrong.
It just means the new code is your visual motif or paradigm. (E.g. A box means X, a line means Y.)
Underlying that visual implementation is...nothing else but more code!
You will never compute without code. You will never COMMUNICATE without code.
This entire article is just a visual representation of a complete vacuum of common sense.
Note the irony:
My response is an example of resistance to adopting the author's encoding scheme. It is likely that his point is not communicable to me in its current phrasing because we have fundamentally different experiences and knowledge structures that get decoded from the same visual representation (the article). Or it is being clearly communicated, and it's just BS.
(E.g. when I see the phrase "no-code solution", it translates to me as a hypothetical solution that doesn't require communication of information according to a fixed set of schemas to orchestrate desired computing behavior. This is dead on arrival. If we are communicating, coding happens.
Either the author is mistaken, or I am. The only way to know for sure is for he and I to COMMUNICATE, establish a common coding schema between us, a "common sense" if you will, and to clear things up so we can both confidently say that we are saying the same thing about the same thing.
FYI: I've started a collection about awesome no code [1] - Why code? All about the Chief Digital Officer's (CDO) clicky-clicky-clicky dream future. No text. No numbers. No code.
It's not satire. It's "real world" marketing bullshit. Would you hire an accountant that tells you that numbers (and mathematics) are so last year. What really count is your customer experience (CX) journey and so on. Welcome the wonderful world of highly-paid buzz-word C-level business executives. You might also enjoy the Get Rich Quick "Business Blockchain" Bible - https://github.com/openblockchains/get-rich-quick-bible Reads like a satire too (but all "real world" examples).
There have been earlier attempts at this, e.g. The Last One: https://en.wikipedia.org/wiki/The_Last_One_(software) They work only to the extent that the generated programs were foreseeable by the software designers.
Oh great, another article claiming that cloud and APIs will make code go away. What do these people think drives APIs and provisions infrastructure in the cloud? We may get better abstractions for some forms of data, but there will always be a demand for code, even when we get hyper-intelligent AIs it will still need to be able to generate code.
At $WORK, management attempted to jump on the no-code train, forcing us to use Salesforce and OutSystems to attempt to write complex business systems. What we got was an unverifiable, totally vendor locked, poorly performing system that cost hundreds of thousands of dollars. It was an exercise in frustration.
Any system sufficiently complex to replace programming is indistinguishable from a poorly written and designed programming language. It's the same broken thought process that leads to business rules engines which themselves always end up being maintained by a specialized programming team. You can't magic away the skills and requirements that necessitate a programmer, you can merely make the programmers job easier or harder.
I'm curious, what were the worst parts about that experience? Was it the limitations of what was possible on those platforms, or were things possible but just too unwieldy? Can you imagine a scenario in which it didn't suck?
184 comments
[ 4.6 ms ] story [ 317 ms ] threadFor example I have yet to see a good way to visually diff graphs.
You can do exactly the same thing for graphs.
If you use text as a storage medium, you can reuse diff, grep, sed and other text-based tools. They won't be perfectly adapted to the language semantics, but good enough. Debugging with gdb is a similar situation: if you include DWARF in compiled binaries it works, otherwise your language needs its own debugger.
I think the best thing you could do is to convert your graph into some common format like dot and create a generic diff tool for that format to make it easier for the next person with similar needs.
(but there will be severe limitations and in practice the users will end up logging calls to IT support)
The skill set required for managing that complexity is basically the same as for a software developer - and software developers have developed their preferred tools for manage it, and the relevant reason that the tools are not better than they are is that it's hard to build good tools, not that software developers are inept for the task.
I'm not saying that the tools can not be improved, but I'm saying that the tools won't be graphical.
More intuitive prototyping tools are another thing though - I'm all for it.
It's possible that that is an accurate description of all "sales"; if they were properly/fully informed, it would be called "buying", not "selling".
Why not express tests directly in code like everyone else instead of pretending business people will ever write them, understand them or know their limitations? Cuke seems like extra busywork job security rather than GTD.
Gherkin just isn't a great language to demonstrate the benefits of that.
This assumption seems wrong to me and I’ll even suggest the exact opposite. Cloud software has traditionally been cumbersome since its the one size fits all approach. With the advent of the cloud, people were willing to sacrifice functionality for convenience. Now that everything is in the cloud this is not true anymore and we’re starting to see pushback at all levels. Almost every company has a different workflow that only custom software can serve best. This is why companies with more resources will win at the software game; assuming they know how to play. Molding software to your workflow is always better than changing your workflow to accommodate software.
The understanding of how systems and resources fit together to accomplish goals -- that's the hard part.
There are two things here. The first is sometimes programming languages are harder than they have to be and the other is that sometimes problems are hard.
1) Yeah, C++ is really complicated and you could probably replace it with language that was less complicated, but if you're trying to do something in the C++ problem space then you're still going to require a lot of difficult thought with respect to your problem, your solution, and the machine it's implemented on. You're not going to get away from writing driver code with a no code solution.
2) If you want to do arbitrary things, then eventually you'll need something that's turing complete (or really close to it if you're going to talk about things like Idris or Agda). A no code solution might be able to handle things as long as you follow a very carefully constructed path, but eventually your users are going to have reasonable requests that no code solutions won't be able to solve because if they could they would just be programming languages unto themselves.
If you're telling me that eventually CRUD apps will be mostly automated away, then I believe you. If you're telling me that eventually software engineers won't be needed then I'll see you in line at the unemployment office because the last two jobs to be made obsolete are software engineers and youtube personalities (and last I checked they're working on automating youtube personalities).
lol, love that! I'm not afraid, if it is to be, so be it, I'll just work on how to grow my own twinkies from a personal garden.
For example, users can always change a URL. This has allowed companies like Twitter to give a little URL-UI (UUI) to help power users while still letting normal people type in the search field. Way on the other end of the spectrum is a tool like Microsoft Excel where there is practically no limit to what a pro can do. Somewhere in the middle would be a sort of table-based design where admins could add simple rules (like layered tax rates, minimum requirements, or when a price change goes live) without needing to do a code deploy.
Don't. Read "worse is better" again. In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.
People who wouldn't know code from Welsh English made databases for libraries, of their CD/DVD collections/... just for fun even.
Today, that doesn't happen anymore. And the web frameworks we currently use for that by and large don't work on mobile and even those are losing in the marketplace for reasons I can't understand, but there is a new javascript framework we just GOT to use. CRUD apps these days ... need a web interface, an android one, an ios one, and more. Minimum number of programming languages required: Javascript, Java/Kotlin, ObjC/Swift, and a backend language (can't use Java for that ... that would make ... euhm ... that would make sense ? And yes, you could use even Javascript, but ... so let's use Python ... or Go).
And let's just not mention that such absolutely basic things as a data table that were lowest-common-denominator are now exceptional. Sorting by every column ? Rarely happens. Having all data in a single listbox with search, filter, and rapid scrolling ? Unheard of (because very impractical on the web).
So no worries about programmer jobs. Ever simpler things will require ever more programmers. Worry about enjoying programming.
That said, html + css is the wrong tool for applications and we keep jamming that square peg through the round hole.
Because CRUD apps were for one platform, running purely locally, not dealing with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, resolutions and orientations, or in arbitrary human languages. I think you underestimate the scope of modern CRUD applications.
Also related is typical business optimization - which usually means externalizing costs to users. Like, "CRUD apps were for one platform" - the cost of doing them for multiple platforms is at worst linear with the number of platforms, and most of that cost can be moved to a constant factor if you design your architecture correctly. It's a big deal, but it's not always that big of a deal. And contemporary alternatives result in applications sorta-working on multiple platforms at the price of one, but having half (or less) functionality.
The result may be complicated under the hood but may be easier to operate as well.
That's not to say that there's no place for frameworks, but it is to say that there's value to being able to piece together the equivalent functionality (or at least the critical subset thereof) from unopinionated "do one thing and do it well" components with relative ease and minimal pain.
See also: the proliferation of Excel spreadsheets driving business logic pretty much everywhere outside of Silicon Valley (and in some cases even within).
As an industry we have absolutely regressed in many ways. Web application make distribution easy but almost everything else is worse.
A third orthogonal axis is neither parallel to x and y, nor do x and y vary as you move along it.
Replace parallel with linearly indepent, and you are spot on.
If your model is 2D, then you are requiring a relationship between at least two of them.
And if your requirements are very steep, you're probably not going to get away from code, but if your goal is to build something quickly and make a few compromises, then maybe No-Code approaches are for you.
The ideal case, in my mind, is a case where apps can scale. A user needs a simple tool, so they build it in a UX-friendly way, which has limitations but can reach some basic data sources and can do some basic CRUD.
Then, the user starts reaching a point where they need to scale. Then, something like VBA can be written by the user or by some developer, and tied into the UX. Indices can be added to the database, and to a DBA it looks like any other CRUD app. Views and materialized views can be used to add information from other parts of the database.
If there's one difficult part, the system can call a service that has access to the database and can do computing more directly, communicating through a standardized JSON system. (Perhaps something like JSON API.)
Then, the tool starts getting popular, and is straining at the seams. Instead of having to create an entirely new project, the project can be exported using a translation layer to a pure programming language, with tests built automatically. Developers can then take it in any direction necessary.
The biggest problem is that it's hard to progressively scale small apps - every time a small tool created outside IT gets created, it expands until it starts being dangerous - excel anyone? - and then IT is brought in to build a full scale system that solves all the problems. IT then gets angry at the users for creating a useful tool instead of getting dragged out into the funding-design-create-test-bugfix process.
And that's why the No Code sounds so appealing. It's a structural PITA to scratch your own itch.
Electrical Engineering has already trod this path. Before HDLs became good enough for logic synthesis, FPGAs and ASICs were developed with schematics or manually mapping circuits into the target architecture. That process doesn't scale well as you end up wrangling with 2D spatial representations and constantly fiddling with low level details. Now, HDLs are the primary means of developing such hardware and the vertical tools are limited to specific data processing niches where there is some productivity advantage in reusing established design methodologies.
I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code. More than a few programs basically became wrappers around C libraries.
That's to say nothing about the unwieldy LabVIEW monstrosities that I'd regularly get asked to take a look at because they were complicated as hell. Massive programs, mostly because of copying and pasting. While you can wrap things up in functions and subroutines and etc., you have to know that you should do that. And I certainly can't blame a research scientist for not knowing that - it's not really their job to.
Fundamental software concepts like DRY don't disappear just because you're using a visual language.
Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms?
(a) doesn't bother me as using a low-level language for low level tasks is a perfectly reasonable thing to do.
> While you can wrap things up in functions and subroutines and etc., you have to know that you should do that.
If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.
It's high-level in the sense that you program by choosing a set of components. A very apt analogy might be Excel and VBA: It would be extremely difficult (if not impossible) to accomplish some tasks using Excel, and if you're using Excel as a "programming language" you will find yourself reaching for VBA to do certain arbitrary tasks.
> If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.
Sure, but saying people should do x is basically absolving yourself of the problem and throwing your hands up in the air. They don't do x, so it's sometimes our job to figure out why they don't x and how we can encourage people to do x over time.
LabVIEW is very much presented informally as "program without learning how to program" (very similar to the article), so people using it don't feel as though they should have to learn basic programming fundamentals.
One of the first hurdles faced by all beginning programmers is "what to do when a program gets too big to fit on one screen," or to understand in one sitting, etc. We all know at least some basic solutions to this problem: Variable naming, subroutines, etc. When LabVIEW programs grow beyond a single screen, which happens quickly, it becomes very cumbersome to navigate through multiple windows and their different viewing modes. Since a program can have multiple entry points, it's hard to figure out what a program "does" in a top down fashion.
Second, there's the reason why so many of us went back to CLI and text editors after experiencing the wonders of the GUI. I think that doing complex work with GUI based tools becomes physically laborious to the point of being debilitating. I came away from my LabVIEW sessions with splitting eyestrain headaches and wrist fatigue.
The physical work involved in laying out code also discourages refactoring.
Maybe, oh maybe, there's something right about text based programming languages.
There have been only two languages (Prograph and Max) with any similarity to LabVIEW which have gained significant numbers of users, so the space of visual dataflow languages hasn't been explored enough to write them all off.
LabVIEW was designed in the 1980s when nothing similar to base it on existed, and various design choices were committed to which didn't work out well. In the following decades, many advances in language design took place or were widely adopted and would be difficult to retrofit to an language of that era.
I've only read about LabVIEW, but I have a fair amount of experience designing another visual dataflow language, Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html).
In Full Metal Jacket's IDE, opening a function definition is done by right-clicking on its vertex (rectangle); connecting an output of one vertex to an input of a second vertex by dragging the mouse cursor in its general direction and releasing or, if the the second vertex is absent, right clicking on the output and dragging the vertex from another window. Hovering over a vertex displays its documentation string, hovering over inputs or outputs displays their types.
I adopted some ideas from functional programming languages - simple syntax from Lisp along with Gabriel's MIT approach, strong static typing with type inference from Haskell and ML, tagged data and a few other ideas from experimental dataflow hardware (I knew the people involved in this both at Cumbernauld and Manchester); and some vocabulary from graph theory. It was obvious to me very early on that there was no way anyone could honestly market dataflow languages at people who don't consider themselves programmers. Not only do you still need to design algorithms, you have to think in a completely new way.
And since there are easy to use examples of each of those in various categories, it's not impossible to imagine some tool will tie all of them together.
Writing a device driver in C is complex, sure, but pretty much all that complexity comes from the problem domain. C++ adds a little more incidental complexity, but if you use it to write a device driver, you're still mostly fighting "how my computer talks to hardware" - and at least that's the correct fight to be having.
But if you're writing a CRUD app for the web, the incidental complexity is off the charts. Five different languages (HTML/JS/CSS/{Ruby|Python|Whatever}/SQL), three or more frameworks (Bootstrap/React/Redux/Django/SQLAlchemy)...and you haven't even deployed yet.
There should be a middle position between "impoverished pseudo programming language" and "here's your five-layer web stack, have fun". If your app is basically three "if" statements and a "for" loop with some UI on top, I agree that you should write those statements in a real programming language. But you shouldn't need three layers of framework on top, just to put them in front of a user!
I think this is what everyone is talking about when they bring up VB and Delphi in this thread. I don't think that "Delphi for the web" is an impossible goal - and I've put my money where my mouth is, by building a sane development platform for the web - https://anvil.works. You do everything in one language (Python), with proper tooling support (hello, autocomplete!), and skip the BS.
(On the other hand, perhaps this is what you meant by "CRUD apps will mostly be automated away". If so, it's only in the sense that my time is being "automated away" when I use a GCed language rather than malloc.)
Heh, SQL (formerly SEQUEL) is the 'structured English query language', designed to be simple enough for anyone who knows a bit of English - not unlike Cobol.
Off-topic, but today I learned I've been pronouncing it as originally intended all this time.
And of course once you progress with your data needs you get into more complex aspects of the language where the simplicity of the language isn't as important as the concepts and ideas it does express.
When I was a kid, I had to type a valid line of source code to load and launch an application (often two separate lines). Today I can literally touch a picture of it with my finger to do the same thing.
There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.
And the end result of this is what? More or less code gets written? Is there a need for more or less programmers over time? What's the trend, do you think?
Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.
95% of the projects I've worked on have been some fairly simple permutation of ETLs, CMSs, and ops -- all of which are sufficiently constrained problem spaces that we've got good systems for them which work well without the need for Turing-complete programming languages.
But as long as we're constrained by legacy codebases, overly complex third-party APIs, and the need to maintain business models, we're not going to be able to make things as simple as we know they should be. It's not just services: I've got 100 legacy file formats on my disk, and they mostly are completely different and require different tools for no good reason.
I've wasted many months (years?) of my life figuring out how to plug the API from service X into the API for service Y and put the results on a simple webpage, with some CSS that a designer gave me. That's not the sort of thing that ought to require a Turing-complete programming language. It's almost all accidental complexity.
Someday we'll sort this all out, and then maybe we'll go on to discover some other unexplored area where we need lots of (Turing) programmers, or maybe we won't, but that's beyond the inflection point. Our next 50% barrier isn't technical, and as long as we've got artificial socioeconomic barriers in the way, I can't guess what's after that.
Most "software" needs these days are business related. Legions of engineers are just adding minute variations to the same CRUD frameworks to make slightly different products. I think the kind of programming that goes into making a CRUD startup and the kind of programming that went into making a device driver in the '80s is very, very different.
But these existed in programming languages before Python's inception, at least back to Lisp in the 60s. And newer languages like Go eschew some of the higher level flexibility of a Python on purpose.
Also, despite the widespread use of languages like Python, JS and Ruby, C/C++ and Java remain just as widely used as ever.
I can think of lots of useful web applications today built by people with no knowledge of linked lists (or at least, they didn't need any such knowledge for those applications). The entire CMS market seems to exist to enable this.
I bet spreadsheets are the most common form of programming on the planet. So at best it takes over a very large niche, becomes entirely mainstream and we forget it's programming at all.
(Of course spreadsheets can use 'real' PLs, but most people only use the basic formulas and ranges.)
Exactly. Creating a "simpler programming" for business users, in the end, only creates a 2nd language the IT staff has to support. Even getting business users updating something as simple as a quality CMS is an uphill slog.
A lot of these optimizations have already been solved.
Typically they're referred to as designers and web engineers.
Dumb advertisement article...
A visual coding language is just providing a different abstraction, but it is still in the same space as other abstractions like a high level language such as Python.
Now, it might be hiding more behind the abstraction than a traditional high-level language, but that is a difference in degree and not kind. It does, however, mean that there are going to be more things that can’t be expressed in the visual language because the abstraction is too broad to be broken down enough. This means that a lot of the tasks that need to be done can’t use the abstraction and need a different programming language.
But there are two problems here. The first is that you can make better abstractions in text-based languages, too. In fact, it's easier to do there. So the visual coding language is always easily caught by text-based languages. They may be easier to use for the layman, but they don't offer anything extra to the professional.
The second problem is that abstractions always have limits. Good (useful) languages give you a way to escape from the abstractions when you need to. Evil languages sucker you in and then trap you in a too-limited abstraction from which you can't escape. (It's not just visual languages, either. The original Pascal, before the Turbo extensions, had exactly this problem.)
Not always:
The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?
MIMD parallelism is straightforward with dataflow. (No worries about synchronization: processes wait until they've received all their inputs before running.) Again, shapes connected by arrows partially ordered in two dimensions is a more natural representation than text.
Finite state machines. Again, shapes connected by arrows is clearer.
>> Not always
Why are you writing and reading in text / code? Surprise, surprise - the English language is text / code. Please, to support your arguments send in some pictures or models or videos etc.
It's ongoing work, and visible progress has been slow over the past year or so. Recently I've been refactoring the code, and improving the type system. One thing worth noting is that representation of functions as a graphs makes type inference more straightforward.
English and other languages are text because our ears hear a single stream of speech and written languages reflect that. Historically, computer programs are single streams of instructions because computers have until recently had processors only capable of doing one thing at a time, and we've usually programmed with text (GRAIL and DRAKON being exceptions) because that's all most terminals could display.
But for finding your way around a city by subway, representing an electric circuit, an organic molecule, or an elementary particle interaction, we use diagrams.
Oh yes. My company used a "visual" programming language for a workflow project and it's pretty much a directed graph with nodes -- the whole thing takes 50 printed pages to see the whole thing and is pretty much impossible to understand. And it's not even that complicated of a workflow.
> Finite state machines. Again, shapes connected by arrows is clearer.
Only for mostly trivial state machines.
I do feel things are different this time around, though. SW distribution really has been significantly improved and there are much better ways of doing client/server applications now.
As to graphical app development UIs taking over programming - I have my doubts.
A lot of things have happened since then, but LabVIEW is still very much a niche application for a very specific domain. And code generators didn't magically abstract away integration, requirements optimization, scaling and architectural desision making.
Even the Smalltalk environment in the 70s, sort of. Not in replacing code, but making an environment where any end user could create their own applications, so they wouldn't have to rely on programmers.
I can't tell from this article or their homepage how they are replacing code, but it sounds like they're trying to fill the niche of Microsoft Excel and Access, letting a semi-technical user specify limited queries and behavior.
Letting more users access the data they need is a laudable goal, but of course there will always be some need for the kind of precisely specified behavior that you get from code. "The Future of Some Software Is No Code" might be a more appropriate title.
Apr 21 https://www.inc.com/greg-satell/how-no-code-platforms-are-di...
Apr 11 https://www.cio.com/article/3268508/leadership-management/en...
Mar 6 https://www.zdnet.com/article/do-you-really-need-developers-...
Feb 27 http://www.tucsonnewsnow.com/story/37601734/quick-base-power...
On one hand, it's a bit of a shame that the article focuses on "no code". What the linked applications all seem to do is a pretty standard package of workflow tooling, reporting generation and data source connectivity. If any of them do a better job than all the existing ones them good on them. In my experience, good tooling here is quite hard to come by and could be very useful/valuable.
On the other hand, on the odd occasion that I've had users buy a tool believing they're doing my job, it's ended up net positive for me. When it inevitably goes south, the reminder that what I do is actually harder than it looks has been beneficial. Obviously, I always get in writing that I wouldn't ever have to support their efforts at finger painting.
As a developer, I'd love anything that makes my job easier, but that usually is more control and explicitness. I think "always bet on text" is a more accurate future: https://graydon2.dreamwidth.org/193447.html
A tangent, this is related to why so many people - myself included - love the paradigm of Emacs as an OS, i.e. moving as much of their workflow and non-work tasks into the editor. It's because of - severely underexplored elsewhere - the power of the abstractions around text Emacs provides. When everything is text - including the UI - but the text isn't transient, like typically used in Unix, but at rest, like in text editors, you get to employ the same set of editing, navigation and search commands to do vastly different tasks. Combine with how so many things can be represented by text, and you get a very powerful tool.
Despite the goal being to "let anyone program", these tools rarely end up as more than toys. Why is that?
It's because learning to program is not a matter of learning syntax. If that was the barrier we'd have just put more effort into NLP and been done with it.
But traditional spoken/written languages are inadequate for the precision needed in programming, so we use more precise alternatives. The language is a tool that makes it easier to program, despite looking more intimidating from the outside.
That said, when you limit your domain you can make quality "codeless" tools. Shader Blueprints in Unreal come to mind as a good example. But a lot of the value they provide is in seeing the previews at every step because it's a very visual thing that you're making. And if you're hitting performance barriers, you'll probably need to rewrite it in text anyway.
Just because programming languages look scary from the outside does not mean that removing them will make programming easier. Most of the time it will make programming harder.
Another point that I forgot to bring up is that graphical tools don't always let you setup functions, and when they do the added indirection usually makes them even more confusing. It makes it difficult to break out repeated logic and confusing to follow the code after you do break it out.
It's still related to the topic, as that's one of the first places people go when trying to take the code out of programming.
I argue that programming languages are not complicated. Although most people butcher the English language, it's a far more complicated language than C, which has relatively few keywords and an unambiguous syntax. But programming languages, especially C, are tremendously repetitious and lack nuance because of the fact that they are so simple. Simplistic units in principle are really good at building different complex things, whereas things that are more complicated are usually better at articulating simpler ideas. No wonder nobody programs computers in English! A programming language that tries to meet parity with English, or any spoken language, would be an utter nightmare to deal with.
My point is that someone who has any innate interest in programming can make their way past the layer of intimidation, especially now more than ever with the sheer amount of information that didn't exist when I started coding. I remember when looking at code was intimidating because it didn't match my understanding of what a language was, and it was in the era of "Just F###ing Google It" when nobody on forums would help you, online documentation was terrible, and there was no Stack Overflow. Now, there is really almost nothing holding anyone back besides the will to do so.
There is a limited amount of things that most people are willing to learn. When one is hardly autodidactic, they will choose the path of least resistance and only learn when it is a necessity. When programming to any degree isn't a necessity for someone, they're not going to want to do it. Heck, sites like Wix and Squarespace are insanely easy to use, and I know people who want to make their own site for their business and drag their feet in using site builders because they find it annoying to understand what it even is they're doing when they're dragging around components. They don't want to have to learn, and would rather someone who is interested in building sites do the work for them.
Hence, why there are still programmers.
For example, tag libraries like the JSTL were designed to split the programming between interface and back end, allowing designers to manage the programming logic in the interface. HTML and markup tags were fine, but in my experience, once you get into loops, conditionals, and so forth, the designers almost always send it back over to the programmers, who now have to learn a new (and generally half assed, in my opinion) set of tags to implement programming logic. As I remember, they pushed this pretty hard (the head first books even devised a mock scenario where a corporate memo banned the use of JSP code in a page). Ruby on Rails went with ruby code and helpers, and I think it was vastly more successful. YMMV of course, but the experience led me to believe that if you're going to program, just use a programming language[1].
As for this article? Well, the sub title is: "It's accelerating how businesses are able to impact their strategy." So, we have a sense of what we're in for if we choose to keep reading.
Beyond that? Actually, I do think that things we used to write code for will be handled differently, and may not require programmers. This is nothing new for the industry. There was a time when a spreadsheet required a computing expert. Same for calculations, servers, publishing an article on what is now a "blog". Blogging engines totally accelerated how writers impacted their strategy.
[1] a lot of people don't quite understand the hype and, yeah, attitude of ruby and rails programmers in the early days. I do think this community went too far with it, but the scenario (a corporate memo banning something) does get at why. The java world had gotten sort of insane, and ultimately was starting to rely on things like memos from above because that was the only way to imagine why anyone would actually write the way the spec said. There really was a massive cheer when someone (DHH in this case) just finally put up a giant screen at a conference saying, literally, "fuck you". Although I think you can achieve with more civility, that kind of bluntness is necessary to beat back the insanity in this field every now and then.
> The reason we find ourselves Soft Coding is because we fear change. Not the normal Fear of Change, but the fear that the code we write will have to be changed as a result of a business rule change.
> It’s a pretty silly fear to have. The whole point of software (hence, the “soft”) is that it can change that it will change. The only way to insulate your software from business rule changes is to build a completely generic program that’s devoid of all business rules yet can implement any rule. Oh, and they’ve already built that tool. It’s called C++. And Java. And C#. And Basic. And, dare I say, COBOL.
The fact that, hundreds of years after Newton, mathematicians still use symbols to convey concepts strengthens your argument here.
- Some day, we won't even need coders any more. We'll be able to just write the specification and the program will write itself.
- Oh wow, you're right! We'll be able to write a comprehensive and precise spec and bam, we won't need programmers any more.
- Exactly
- And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?
- Uh... no...
- Code, it's called code.
In the end, we'll just move the abstraction layer to another level, that's it.
[1] http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv...
The real problem is that humans imagine things and communicate them at very high abstraction levels, without filling in the levels below. Much like a children's drawing of a car is nowhere near detailed enough to serve as a blueprint for building one, our usual descriptions of stuff don't contain necessary details at all. If you want to build a real thing, all the work to fill in the lower levels of detail needs to be done. You can't magick it away. Today, that work is done 10% by the people writing specifications and 90% by programmers figuring things out. In the future it might be done by a computer - but that computer would necessarily need to be a human-level artificial intelligence, doing all the work programmers do to go from the way we communicate to a working program.
All the computer abstractions help solve computer problems and in turn make it easier to implementation solutions but doesn't make the business problems any smaller.
It still doesn't change the fact that the surface area of that layer is enormous, and so is the space between it at the bottom and your problem at the top. All the details in between is what you need to figure out.
I'm not completely sure the bottom can be qualitatively raised very far up. The digital computing abstraction is a qualitative model change, from physics to mathematics. Experience suggests that when you decompose a business problem, the lowest algorithmic details very often end up on, or slightly above, that bottom layer - so you need the ability to work on that level. Of course, if you're willing to limit your scope and problem domain, then a lot of things can be abstracted further - but they won't generalize.
More specifically, people generally have a vague idea of what they want. While you could explain a fully precise mathematical model that corresponds to that idea, people don't really have a good way to know if the model is correct or if there is some hidden corner case that causes problems. So they accept the model until they find one case where it was wrong.
People not understanding this has, in my experience, led to a lot of very bad decisions, especially around outsourcing. So many people in 2006 thought that American/Canadian developers would disappear in a few years as everything was outsourced. They didn't realise that writing a "comprehensive and precise spec" to send to a team of developers on the other side of the world, and have them implement _exactly_ what you asked them to, was actually creating more work.
I mean, a lawyer learns the "code" of law. A psychologist learns the "code" of human, which has a lot of black boxes but one can still make partial sense of it.
This is the whole point behind the reverence for "declarative programming" in the Erlang world (and probably others). Tell the computer what to do, not how to do it. The "how to do it" part should instead be the responsibility of the programming environment (which can - hopefully/ideally/eventually - do a better job than the programmer at organizing the "how" in a manner which appropriately balances efficiency and robustness).
And with images, people think of children books, easy, right? In reality, as soon as you introduce a tiny bit of complexity, it becomes closer to Chinese. In Chinese, you can still see the little drawings, but that's just the background of a highly complex language.
Whether you code in an English-like text based language or a proto-Chinese-like picture based language doesn't change the fact that you are coding. Most people end up preferring the "text" approach that is more adapted to computers, and ultimately easier.
Access
Rational Rose
Logic Works ERwin
App Maker
PowerApps
OutSystems
VisionX
Mendix
QuickBase
... and a zillion others.
There’s nuance in a spectrum between non-technical end-users developing simple workflows and forms, and trying to run an entire business on it with business rules, interoperability, standards, etc.
As long as computational operations exist, there will need to be a language to represent those operations. As long as that exists, there will be more languages to streamline that, and so on and so forth.
Computers are not magic. They do not think. Even if they did, they would be constrained by the same fundamental linguistic bottlenecks that we human beings are.
To illustrate this point: I will concede that no code solutions are possible when every human being achieves Buddhist Enlightenment. This would be the human equivalent of a no code solution. No one communicating, or orchestrating external experiences to create an epiphany. Just an internal realignment of values.
Another illustration: Convince all of your neighbors to agree with you without communicating to them in any way.
Coding is a fundamental axiom of information transfer. If you aren't doing it in some fashion, you aren't DOING anything. If you are doing it, then you are constrained by your encoding scheme. The thing that trips up most users is that they aren't consciously aware of their own encoding schemas, and are typically resistant to adopting someone else's. In the article's case, they are asserting that "visual" programming is not code.
Which is dead wrong.
It just means the new code is your visual motif or paradigm. (E.g. A box means X, a line means Y.)
Underlying that visual implementation is...nothing else but more code!
You will never compute without code. You will never COMMUNICATE without code.
This entire article is just a visual representation of a complete vacuum of common sense.
Note the irony: My response is an example of resistance to adopting the author's encoding scheme. It is likely that his point is not communicable to me in its current phrasing because we have fundamentally different experiences and knowledge structures that get decoded from the same visual representation (the article). Or it is being clearly communicated, and it's just BS.
(E.g. when I see the phrase "no-code solution", it translates to me as a hypothetical solution that doesn't require communication of information according to a fixed set of schemas to orchestrate desired computing behavior. This is dead on arrival. If we are communicating, coding happens.
Either the author is mistaken, or I am. The only way to know for sure is for he and I to COMMUNICATE, establish a common coding schema between us, a "common sense" if you will, and to clear things up so we can both confidently say that we are saying the same thing about the same thing.
TL;DR:
No-code happens when world peace does.
[1] https://github.com/bigkorupto/awesome-nocode
Q: What's the name for someone who can't read & write?
- (A) Chief Alphabet Officer
- (B) Illiterate Know-All / Know-Nothing
- (C) No Alphabet Creative
- (D) Other - Please Tell
Q: What's the name for someone who can't read & write code?
- (A) Chief Digital Officer
- (B) Certified No Code Business Architect®
- (C) Quick Base / Mendix / Zudy / Pega / <Your No Code Corp. Name Here> Marketing Bullshitter
- (D) Other - Please Tell
Source: https://github.com/bigkorupto/awesome-nocode#no-code-trivia-...
> You don’t code software in Pega. You design it.
This has to be from a mindset that designing and coding are different jobs done by different people: http://wiki.c2.com/?ArchitectsDontCode
At $WORK, management attempted to jump on the no-code train, forcing us to use Salesforce and OutSystems to attempt to write complex business systems. What we got was an unverifiable, totally vendor locked, poorly performing system that cost hundreds of thousands of dollars. It was an exercise in frustration.
Or how about the future of mathemtatics is no numbers?
Or how about the future of civilization is no books?
Or how about the future of marketing is no bullshit?
And so on. Source: https://github.com/bigkorupto/awesome-nocode