4 ms·

Writing code, outside of spaghetti BASIC and similar, is a full time job. It requires hours and hours of thinking and planning. People already have full time j

Writing code, outside of spaghetti BASIC and similar, is a full time job. It requires hours and hours of thinking and planning. People already have full time jobs, sometimes two or more. The last thing they want is another, likely unpaid one, when they come home and sit down before the computer.

erikpukinskis 10y ago
This is the biggest mistaken belief of the programming industry. Where we're headed is multi-level architectures. At the bottom is what you think of as "all programming". It's low level code, with manual deployment, using a wide range of fairly arcane tools. You need to be a professional to do it. What is slowly emerging, which you suggest is impossible, is a layer on top of that. It is written in highly constrained code. You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. But you are working within a sandbox that your professional software engineering colleague built for you. Most of us software pros don't think about development this way. We think we're supposed to be releasing finished apps to end users. But 20 years from now, we'll think of our job as releasing libraries for "non-programmers" to use. DSLs that are foolproof, which end users will string together using simple function calls and literals and nothing else. Languages in which it's very difficult to express broken ideas. There's no reason the marketing team can't write this file: post("miami", "Bienvenido a Miami!") image("miami", "http://static.flickr.com...") paragraph("miami", "We've gotten more requests for a Miami location than the rest of our...") Well, there is a reason. It's almost certain that the programmers down the hall, like you, don't believe that a marketing professional could handle the "hours of thinking and planning" required to write that code. But again, they are all mistaken. Any smart, computer-savvy person could write that code after a few minutes of instruction. But first you'd have to build that API, and a realtime preview, that is editable from a nice simple web app. You could do the "hours of thinking and planning" so that your colleagues could write the high level business code. That's where this is all going. There will be a lot of programmers that work inside a sandbox like that, a few hours a week. Most programmers will work like that. And there will be a smaller number of seasoned pros will maintain those sandboxes.
- wvenable 10y ago
  > This is the biggest mistaken belief of the programming industry. Actually I think what you're saying is the biggest mistaken belief in the programming industry. The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch. > You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. If it's Turing complete then someone can and certain would write spaghetti code. Every constrained environment that ever existed for lay people to use ends up in the hands of frustrated programmers. > There's no reason the marketing team can't write this file. There's no reason why they couldn't just drag and drop such logic and prefer to do it as well. Most people have trouble understanding how to work with Turing complete languages to accomplish advanced tasks. Programmers aren't purposely trying to make their environments difficult -- in fact making everything as easy as possible has been the goal since the beginning. > You could do the "hours of thinking and planning" so that your colleagues could write the high level business code. Honestly that High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer. It's a job in itself different from other jobs. It will never be a job for non-programmers and maybe not even junior programmers.
  - erikpukinskis 10y ago
    > The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch. Yes, and it's working. All of those projects helped. A child will learn far more in their first year of programming today than I learned in my first year of BASIC. I think that trend is accelerating and we are very close to the hockey stick part of the accessibility graph. There are a LOT of people who have at least dabbled in programming today. > If it's Turing complete then someone can and certain would write spaghetti code. Sure. And yes, some poor schmo will have to deal with it. But most of the code won't be spaghetti code. Most of the code changes will just be string edits. Marketing has a vested interest in not breaking their pipelines. I honestly think a little instruction goes a long way here. It's not that people won't be learning coding best practices, it's that you won't need a year of training up front just to get started. I'm not talking about eliminating the learning curve, I'm talking about making it shallow and linear. > There's no reason why they couldn't just drag and drop such logic Visual logic programming has been a mixed bag. It does work well for some very constrained kinds of programs, like shader pipelines and audio programming. But generally research into visual programming has not gone well. Text has one very important benefit over visual programming: it's linear. That's nice because much of code execution is linear. It's actually a tree, but it's definitely not Cartesian. Drag and drop is also not very intuitive for most users. It's an invisible affordance. It requires dexterity. And it's also not very constrained... You can drag anything into anything. Most programming will be text. I don't think it will be pure ASCII but it will be linear text. > Programmers aren't purposely trying to make their environments difficult Of course not. They are trying to make it just easy enough for a full time professional to figure out and no more. > High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer I think you're forgetting about some programmers. You know the kind... They just want something complicated to do. Like "rewrite the entire system using a custom memory store instead of SQL" and then they disappear into the wilderness for 4 weeks and come out with it finished. Some requirements mean a lot of code to change. Some requirements require almost none. What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles. Marketing, support, finance, they'll just do that coding themselves. At least they'll do the patch and submit it for review. And the other stuff... Stuff that's more about code than business needs, that will still be the domain of the professional programmer. Current programmers will have a choice. Do I want to stay in mostly code all day and solve thorny problems? Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming.
syrrim 10y ago
Coding is only difficult because we have made it difficult. It should be possible for a user who is not overly familiar with programming to open up the source, find the part they want to change, change it, and rebuild the changed software. Instead, we have been making all our software as complicated to understand and edit as possible, and then only shipping binaries in order to hide the complexity. The advice of my window manager, i3, regarding source installs is: don't. Disregarding that advice, and after fighting with my package manager to get the required libs, `make` made it extremely easy to build. From there, the edit I wanted to perform required changing the value of a constant from 3 to 0. Not hours and hours at all. Making this feasible for everyday users is within reach. If the focus of the free software movement had been on making software that users can modify on a physical and practical level, rather than just a legal and technical level, we might see everyday users patching their software. That didn't happen, and it doesn't seem many people care about making it happen, and so the situation won't change.

erikpukinskis 10y ago

This is the biggest mistaken belief of the programming industry. Where we're headed is multi-level architectures. At the bottom is what you think of as "all programming". It's low level code, with manual deployment, using a wide range of fairly arcane tools. You need to be a professional to do it. What is slowly emerging, which you suggest is impossible, is a layer on top of that. It is written in highly constrained code. You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. But you are working within a sandbox that your professional software engineering colleague built for you. Most of us software pros don't think about development this way. We think we're supposed to be releasing finished apps to end users. But 20 years from now, we'll think of our job as releasing libraries for "non-programmers" to use. DSLs that are foolproof, which end users will string together using simple function calls and literals and nothing else. Languages in which it's very difficult to express broken ideas. There's no reason the marketing team can't write this file: post("miami", "Bienvenido a Miami!") image("miami", "http://static.flickr.com...") paragraph("miami", "We've gotten more requests for a Miami location than the rest of our...") Well, there is a reason. It's almost certain that the programmers down the hall, like you, don't believe that a marketing professional could handle the "hours of thinking and planning" required to write that code. But again, they are all mistaken. Any smart, computer-savvy person could write that code after a few minutes of instruction. But first you'd have to build that API, and a realtime preview, that is editable from a nice simple web app. You could do the "hours of thinking and planning" so that your colleagues could write the high level business code. That's where this is all going. There will be a lot of programmers that work inside a sandbox like that, a few hours a week. Most programmers will work like that. And there will be a smaller number of seasoned pros will maintain those sandboxes.

wvenable 10y ago
> This is the biggest mistaken belief of the programming industry. Actually I think what you're saying is the biggest mistaken belief in the programming industry. The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch. > You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. If it's Turing complete then someone can and certain would write spaghetti code. Every constrained environment that ever existed for lay people to use ends up in the hands of frustrated programmers. > There's no reason the marketing team can't write this file. There's no reason why they couldn't just drag and drop such logic and prefer to do it as well. Most people have trouble understanding how to work with Turing complete languages to accomplish advanced tasks. Programmers aren't purposely trying to make their environments difficult -- in fact making everything as easy as possible has been the goal since the beginning. > You could do the "hours of thinking and planning" so that your colleagues could write the high level business code. Honestly that High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer. It's a job in itself different from other jobs. It will never be a job for non-programmers and maybe not even junior programmers.
- erikpukinskis 10y ago
  > The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch. Yes, and it's working. All of those projects helped. A child will learn far more in their first year of programming today than I learned in my first year of BASIC. I think that trend is accelerating and we are very close to the hockey stick part of the accessibility graph. There are a LOT of people who have at least dabbled in programming today. > If it's Turing complete then someone can and certain would write spaghetti code. Sure. And yes, some poor schmo will have to deal with it. But most of the code won't be spaghetti code. Most of the code changes will just be string edits. Marketing has a vested interest in not breaking their pipelines. I honestly think a little instruction goes a long way here. It's not that people won't be learning coding best practices, it's that you won't need a year of training up front just to get started. I'm not talking about eliminating the learning curve, I'm talking about making it shallow and linear. > There's no reason why they couldn't just drag and drop such logic Visual logic programming has been a mixed bag. It does work well for some very constrained kinds of programs, like shader pipelines and audio programming. But generally research into visual programming has not gone well. Text has one very important benefit over visual programming: it's linear. That's nice because much of code execution is linear. It's actually a tree, but it's definitely not Cartesian. Drag and drop is also not very intuitive for most users. It's an invisible affordance. It requires dexterity. And it's also not very constrained... You can drag anything into anything. Most programming will be text. I don't think it will be pure ASCII but it will be linear text. > Programmers aren't purposely trying to make their environments difficult Of course not. They are trying to make it just easy enough for a full time professional to figure out and no more. > High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer I think you're forgetting about some programmers. You know the kind... They just want something complicated to do. Like "rewrite the entire system using a custom memory store instead of SQL" and then they disappear into the wilderness for 4 weeks and come out with it finished. Some requirements mean a lot of code to change. Some requirements require almost none. What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles. Marketing, support, finance, they'll just do that coding themselves. At least they'll do the patch and submit it for review. And the other stuff... Stuff that's more about code than business needs, that will still be the domain of the professional programmer. Current programmers will have a choice. Do I want to stay in mostly code all day and solve thorny problems? Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming.

syrrim 10y ago

Coding is only difficult because we have made it difficult. It should be possible for a user who is not overly familiar with programming to open up the source, find the part they want to change, change it, and rebuild the changed software. Instead, we have been making all our software as complicated to understand and edit as possible, and then only shipping binaries in order to hide the complexity. The advice of my window manager, i3, regarding source installs is: don't. Disregarding that advice, and after fighting with my package manager to get the required libs, `make` made it extremely easy to build. From there, the edit I wanted to perform required changing the value of a constant from 3 to 0. Not hours and hours at all. Making this feasible for everyday users is within reach. If the focus of the free software movement had been on making software that users can modify on a physical and practical level, rather than just a legal and technical level, we might see everyday users patching their software. That didn't happen, and it doesn't seem many people care about making it happen, and so the situation won't change.