9 ms·

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. An

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).

pcunite 8y ago
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.
3pt14159 8y ago
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.
candiodari 8y ago
> 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.
- ebiester 8y ago
  What I wouldn't do for a tool like powerbuilder today... That said, html + css is the wrong tool for applications and we keep jamming that square peg through the round hole.
- naasking 8y ago
  > 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.
tylfin 8y ago
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.
- fh973 8y ago
  I think orthogonal (at least from its usage in math-related contexts) means the two don't have anything to do with each other.
  - taoistextremist 8y ago
    Nah, that would be skew. Orthogonal crosses but goes in a different direction.
    - zinclozenge 8y ago
      Except you can have orthogonal vectors that don't intersect.
    - cliffy 8y ago
      Orthogonal is frequently used to mean two (or more) things are independent of one another. I have never heard skew used in that way.
      - karatinversion 8y ago
        Yes, the poster above has assumed the meaning of 'orthogonal' from its etymology, but the use he criticises comes from statistics (https://stats.stackexchange.com/questions/12128/what-does-orthogonal-mean-in-the-context-of-statistics https://stats.stackexchange.com/questions/12128/what-does-or...)
      - 0x445442 8y ago
        I believe in the, quite common, context just used it's meant as non-parallel. Or the two ideas don't track at all.
ebiester 8y ago
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.
- shams93 8y ago
  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.
  - kevin_thibedeau 8y ago
    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.
wgerard 8y ago
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.
- DonaldFisk 8y ago
  > 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.
  - wgerard 8y ago
    > 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.
sveme 8y ago
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.
- petra 8y ago
  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.
meredydd 8y ago
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 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.)
- woah 8y ago
  Sounds like.......... a framework
  - TomK32 8y ago
    which hides away complicated things like sql behind an more accessible api...
    - Koshkin 8y ago
      > complicated things like sql 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.
ken 8y ago
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.
- goatlover 8y 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.
  - ken 8y ago
    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.
deleted 8y ago
[deleted]
robotresearcher 8y ago
> 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.)
- contextfree 8y ago
  from my POV spreadsheets are code (there's a formula language after all), just laid out differently and with a very different IDE.
  - deleted 8y ago
    [deleted]
  - robotresearcher 8y ago
    That's my point. And while niche, the niche is enormous and important. Spreadsheets are a huge success in domain-specific programming for everyone.
    - hestefisk 8y ago
      And huge success in functional programming.
zacharytelschow 8y ago
> 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.
- commandlinefan 8y ago
  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.
  - copperx 8y ago
    Aren't query planners already intelligently optimizing? A lot of these optimizations have already been solved.
shamas 8y ago
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. Dumb advertisement article...

pcunite 8y ago

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.

3pt14159 8y ago

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.

candiodari 8y ago

> 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.

ebiester 8y ago
What I wouldn't do for a tool like powerbuilder today... That said, html + css is the wrong tool for applications and we keep jamming that square peg through the round hole.
naasking 8y ago
> 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.

tylfin 8y ago

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.

fh973 8y ago
I think orthogonal (at least from its usage in math-related contexts) means the two don't have anything to do with each other.
- taoistextremist 8y ago
  Nah, that would be skew. Orthogonal crosses but goes in a different direction.
  - zinclozenge 8y ago
    Except you can have orthogonal vectors that don't intersect.
  - cliffy 8y ago
    Orthogonal is frequently used to mean two (or more) things are independent of one another. I have never heard skew used in that way.
    - karatinversion 8y ago
      Yes, the poster above has assumed the meaning of 'orthogonal' from its etymology, but the use he criticises comes from statistics (https://stats.stackexchange.com/questions/12128/what-does-orthogonal-mean-in-the-context-of-statistics https://stats.stackexchange.com/questions/12128/what-does-or...)
    - 0x445442 8y ago
      I believe in the, quite common, context just used it's meant as non-parallel. Or the two ideas don't track at all.

ebiester 8y ago

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.

shams93 8y ago
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.
- kevin_thibedeau 8y ago
  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.

wgerard 8y ago

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.

DonaldFisk 8y ago
> 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.
- wgerard 8y ago
  > 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.

sveme 8y ago

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.

petra 8y ago
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.

meredydd 8y ago

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 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.)

woah 8y ago
Sounds like.......... a framework
- TomK32 8y ago
  which hides away complicated things like sql behind an more accessible api...
  - Koshkin 8y ago
    > complicated things like sql 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.

ken 8y ago

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.

goatlover 8y 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.
- ken 8y ago
  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.

deleted 8y ago

[deleted]

robotresearcher 8y ago

> 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.)

contextfree 8y ago
from my POV spreadsheets are code (there's a formula language after all), just laid out differently and with a very different IDE.
- deleted 8y ago
  [deleted]
- robotresearcher 8y ago
  That's my point. And while niche, the niche is enormous and important. Spreadsheets are a huge success in domain-specific programming for everyone.
  - hestefisk 8y ago
    And huge success in functional programming.

zacharytelschow 8y ago

> 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.

commandlinefan 8y ago
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.
- copperx 8y ago
  Aren't query planners already intelligently optimizing? A lot of these optimizations have already been solved.

shamas 8y ago

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. Dumb advertisement article...