7 ms·

Not a lot of support for his sentiments here it seems, but to understand where he's coming from you probably need to see the research he has been doing, largely

Not a lot of support for his sentiments here it seems, but to understand where he's coming from you probably need to see the research he has been doing, largely aimed at entirely different modes of programming -- visualizing boolean logic trees and all kinds of other stuff, aimed at making programming more accessible and concrete to regular people. You know in the movies where they have the futuristic user interfaces? Well we've been able to put graphics on the screen for decades, but "real" enterprise programming is still mostly pounding keys into text files and fussing over semicolons and curly braces. Visual interfaces are considered toys that "real" programmers don't need. And yet there's a chasm of capability between programmers and users, and it's actually true that what programmers do isn't something most "normal people" will ever be capable of. But is that because programmers have some wildly special form of intelligence that most people don't have, or is it because our tools suck? The divide between users and developers is as accepted and entrenched as it is archaic, not to mention a huge innovation and creativity bottleneck for the species, and by my estimation an embarrassing failure to innovate for our industry. Jonathan has been pushing back for decades. He's not grumpy or cynical, he's a relic from a time when the future of programming and "what programming even looks like" was still a wildly open question. I wish more people thought like him.

mixedCase 6y ago
What are your thoughts on the overrepresentation of people in the spectrum in tech? I think there's a very specific mindset (or "form of intelligence" per your words) that thrives working on a complex sandbox with very rigid rules and low tolerance for logical inconsistency, while most people simply have no tolerance for such inflexibility. And I think there's no tooling that can change that, and if there ever is there goes programming as an industry because it will be able to interpret loosely defined requirements, ask the right questions and find a logical solution to it.
- erichanson 6y ago
  Yeah I think it takes a special mind to use today's dev environment, but the distance from where we are today, to an interrogative system creator (which is a pretty cool idea btw) is eons; there has to be something more in the middle. I think it's always going to take someone with a systems-thinking mind to engineer a system that's any good, but lots of people have that, people who created their own business and thought through all the steps in their system and engineered the whole thing in their head. That's systems engineering, just not with code. But there's so much knowledge that's required to go from zero to custom software deployment that I'd characterize as non-essential complexity, today. Yeah I think programmers tend to make tools for programmers, for themselves and the way they think, which is totally natural and to be expected. But man these poor users. It's not so bad when they're using mainstream programs with millions of dollars in dev budgets behind them, but when you get further down the long-tail it just gets so awful and users are so helpless. The software an insurance agent uses, the charting app a therapist uses, the in-house warehouse management system people spend their entire day using, where if they could just make this field auto-focus or a million tiny other things, they would save so much time and frustration. Generally speaking, users edit data and programmers edit schema, and never the two shall cross. Users execute code but only programmers change it. What hope do we have of democratizing programming when these roles are about as foundational to computers as it gets? What would we have to unlearn to change this?
hn_throwaway_99 6y ago
> I wish more people thought like him. I don't, because instead of introspectively looking at why the world didn't turn out exactly like he wanted it, he blames others by dismissing their achievements as stagnation. Those futuristic looking user interfaces never caught on because while they look good in movies they suck for actual productivity, even for non-technical users. And when it comes to "non-programmer programming", just look at the success of tools like Zapier. I see tons of non-programmers using them to great success.
- erichanson 6y ago
  I wish more people thought like Zapier too. Their pipe flow designer thing is pretty star trek. The world is chock full of shit software that people have to use eight hours a day and absolutely hate. I mean, seriously, hate to the point of shaking and tears at the idiotic hoops they have to jump through all day long, every day, for years. Genuine mental health impact. They come home miserable and snap at their kids. Maybe he's channeling their frustration. And maybe we deserve it.
  - networkimprov 6y ago
    That's the widespread failure to apply insights from Human Factors and HCI research, much of which has been around for decades. A different problem than better programming paradigms.
    - infinite8s 6y ago
      Is it really? Programming is just really low level HCI.
  - osullivj 6y ago
    Sounds like you're talking about corporate environments, where the people using the software aren't the same folk as those paying for it.
- carapace 6y ago
  Go back to the page, look at the right-hand sidebar under "Links", it has: About me Email me Subtext Click on "Subtext". Read up.
noobermin 6y ago
Instead of complaining that the churning world of software is "stagnant" he could have just made a blog post talking about his ideas of what that futurist interface would be. That would have garnered a lot more of a positive attitude.
- jacquesm 6y ago
  Step one is to realize you actually have a problem. Then you can start solving it.
dcolkitt 6y ago
> Well we've been able to put graphics on the screen for decades, but "real" enterprise programming is still mostly pounding keys into text files and fussing over semicolons and curly braces. Visual interfaces are considered toys that "real" programmers don't need. You should at least consider the counter-hypothesis that C-style keyboard pounding is fundamentally more productive than visual interfaces. This shouldn't be that surprising. Text is much more informationally dense than audiovisual multimedia. There's a reason why books are still the preferred medium for information transmission after thousands of years. Sci-fi style visual coding sure seems cool. But I highly doubt that it will ever be as productive as a skilled developer typing out variables, functions and classes.
- asdff 6y ago
  Research has shown you focus more writing than typing. Imagine if you could program by rough drafting how your function works on paper. Like with arrows and all sorts of messy things connecting the structure of your code, but entirely understandable to another human what your function was to do without needing to understand a lick of code. Take this example(1) from the R subreddit about how to do matrix math, and the arcane R foo required to actually do something that is pretty simply explained in OPs image(2) to anyone with zero background in R or programming at all. Now, imagine how much more productive the world would be if the computer could take an instruction in a readable form like the OPs image, rather than the R jargon code actually needed by the computer to do the math described in the image. People would be learning to write their own functions right along side learning how to do math on paper. Instead, people today pay six figures and spend four years to learn how to turn the math they learned by hand in high school into something that can be ran on a computer, same as it was 30 years ago. 1. https://old.reddit.com/r/rprogramming/comments/kn2rgb/how_do_i_do_this_very_simple_thing_in_r_thanks_in/ https://old.reddit.com/r/rprogramming/comments/kn2rgb/how_do... 2. https://i.redd.it/ngxi8665zb861.jpg https://i.redd.it/ngxi8665zb861.jpg
  - valenterry 6y ago
    Such things have been tried. They usually fail because of underestimating the amount of ambiguity, complexity manamagement and performance problems. SQL came pretty close - I mean, it was specifically designed for non-developers. Guess who's mostly using not nowadays.
cheschire 6y ago
I’m sorry, I still don’t buy it. Entry level programming concepts are now presented to kids in literal toys. “Real” enterprise programming has a heavy bit of tooling available now that wasn’t there in ‘96 with testing frameworks of all sizes, intellisense style code completion tools... I predict the next major functionality that will come is pre-trained machine learning that be dropped into code as simply as boolean statements are today. Or wait that’s a dream that isn’t here yet so I should be cynical and lash out at my kids’ LEGO Boost set for its antiquated battery tech or something.
tsimionescu 6y ago
This is like envisioning a world where everyone is building their own chairs and doing their own pottery. People who can do carpentry, or pottery, or programming are not in any way better or smarter than the average Joe. They have a different specialized set of skills than many other people, and they have the time to actually use those skills. Even if everyone knew carpentry and pottery and programming, they would not be using these skills in their day-to-day lives, because they have their own job to do. An accountant will not start programming their own accounting software, or even their own plugins - they will use some purpose-built software written by someone else, because it is a far more efficient use of their time. It's also important that programming is a fundamentally tedious endeavor. Even with the most high-level imaginable PL, where there would be no machine details to think about, you need to exhaustively define every detail of your business goal, much further than you would ever think about it in regular work. I am a programmer and I personally enjoy this kind of deep dive, but I have been in many meetings where I was trying to extract those details from domain experts and getting increasingly frustrating for them with all the probing. Even worse, you often hit points where you just can't get past some hand-waving, and now it's your job as a programmer to evaluate the trade-offs between different strict implementations of what is a fundamentally fuzzy requirement. And getting out of the fantasy of the perfect PL, you also then have to work with a real computer with real limitations that someone needs to know how to work in while representing the problem domain (e.g. replacing real arithmetic with floating point arithmetic and dealing with the new problems that stem from that). You also have to spend large amounts of time researching what others have built and re-using it when and where it is possible, and working withing the trade-offs those others have made - since there's no chance of writing every program from scratch, and there is no such thing as a general purpose domain specific library.
- auggierose 6y ago
  Very good points. The problem is that people are normally not using other peoples shitty chairs to try to build a space station.
  - saasdev 6y ago
    Exactly! This is what scares me about the modern day no-code movement.
pfdietz 6y ago
The idea of programming with pictures goes way back. I mean, to the 1950s. It's one of the classic mistakes, like fighting a land war in Asia or going in against a particular ethnic group when death is on the line.
- smolder 6y ago
  I do not believe for a second it's a mistake to have visual representation or manipulation of software, it's just exceedingly difficult to make anything as versatile as text grammars and compilers. No one's done an adequate job because the ROI is terrible for building such things when you can't depend on massive adoption, which you can't.
  - pfdietz 6y ago
    I think it's a proven mistake to use visual representations in place of textual representations for creating software. The information density is low, it's difficult to work with, browse, and search, and (a real killer) merging in version control systems is a nightmare.
    - khooke 6y ago
      Given the current day struggle to merge code with whitespace differences, merging differently arranged visual programming elements where the end result is the same but the positioning of the elements is just different sounds like a tough problem. Although linking of elements is probably key, rather than visual positioning. I imagine this is something IBM VisualAge had to deal with back in the late 90s. If I remember right local history was a key feature of VisualAge, a feature that carried across to Eclipse and is still there today.
  - khooke 6y ago
    I think the limitation that no-one has managed to solve is that visual programming paradigm approaches tend to focus on solving a specific type of problem (drag and drop GUI builders are a perfect example), and this means their usage is narrow and they're never been widely adopted. Building a generic visual programming tool that can be used to solve any type of business problem across any business domain is very difficult if not dare I say it impossible.
imtringued 6y ago
>visualizing boolean logic trees and all kinds of other stuff, aimed at making programming more accessible and concrete to regular people. Here's an art analogy. You make it easier to create art by making an algorithm that takes fuzzy beginner line art that is not following proportions and has all sorts of problems and turn it into professional line art via ML. People will struggle at the far more challenging skill of choosing what to draw because it innately requires knowledge of human anatomy, perspective and many other skills beyond knowing how to use a pencil. Programming languages are equivalent to a pencil, tablet or other any input method in this analogy.
908B64B197 6y ago
> And yet there's a chasm of capability between programmers and users, and it's actually true that what programmers do isn't something most "normal people" will ever be capable of. But is that because programmers have some wildly special form of intelligence that most people don't have, or is it because our tools suck? Every time I used a "No-Code" solution it got me 95% where I wanted to be. The remaining 5% took twice as long as the first 95% because now I had to "go behind the scenes" and figure out the custom API exposed by whatever tool I was using. And then figure out a workaround that would inevitably break with the next version of the tool. And even with the No-Code, it's still being able to decompose a problem into smaller sub-problems, find the similarities and make sure they are well defined. I think there are a lot more folks with these abilities but you'll find them in math and engineering departments mostly.
- erichanson 6y ago
  Agree about no-code. But UI that generates code is a pretty cool paradigm. For most common patterns, end users don't need to know that there's a bunch of boilerplate code under the hood, but if that isn't sufficient, that remaining 5% can be reached by just jumping into some auto-generated code that's readable and well-commented. Mere mortals can do the 95% themselves and then call in a wizard for the hard parts, or try to figure it out on their own. Plus, any non-generated solutions can be highlighted, so it builds up a record of the places where the UI fell short.
  - 908B64B197 6y ago
    Interface builders sort of work like that (creates the boilerplate for UI elements and formatting). But again, NeXT interface builder predates 1996.

mixedCase 6y ago

What are your thoughts on the overrepresentation of people in the spectrum in tech? I think there's a very specific mindset (or "form of intelligence" per your words) that thrives working on a complex sandbox with very rigid rules and low tolerance for logical inconsistency, while most people simply have no tolerance for such inflexibility. And I think there's no tooling that can change that, and if there ever is there goes programming as an industry because it will be able to interpret loosely defined requirements, ask the right questions and find a logical solution to it.

erichanson 6y ago
Yeah I think it takes a special mind to use today's dev environment, but the distance from where we are today, to an interrogative system creator (which is a pretty cool idea btw) is eons; there has to be something more in the middle. I think it's always going to take someone with a systems-thinking mind to engineer a system that's any good, but lots of people have that, people who created their own business and thought through all the steps in their system and engineered the whole thing in their head. That's systems engineering, just not with code. But there's so much knowledge that's required to go from zero to custom software deployment that I'd characterize as non-essential complexity, today. Yeah I think programmers tend to make tools for programmers, for themselves and the way they think, which is totally natural and to be expected. But man these poor users. It's not so bad when they're using mainstream programs with millions of dollars in dev budgets behind them, but when you get further down the long-tail it just gets so awful and users are so helpless. The software an insurance agent uses, the charting app a therapist uses, the in-house warehouse management system people spend their entire day using, where if they could just make this field auto-focus or a million tiny other things, they would save so much time and frustration. Generally speaking, users edit data and programmers edit schema, and never the two shall cross. Users execute code but only programmers change it. What hope do we have of democratizing programming when these roles are about as foundational to computers as it gets? What would we have to unlearn to change this?

hn_throwaway_99 6y ago

> I wish more people thought like him. I don't, because instead of introspectively looking at why the world didn't turn out exactly like he wanted it, he blames others by dismissing their achievements as stagnation. Those futuristic looking user interfaces never caught on because while they look good in movies they suck for actual productivity, even for non-technical users. And when it comes to "non-programmer programming", just look at the success of tools like Zapier. I see tons of non-programmers using them to great success.

erichanson 6y ago
I wish more people thought like Zapier too. Their pipe flow designer thing is pretty star trek. The world is chock full of shit software that people have to use eight hours a day and absolutely hate. I mean, seriously, hate to the point of shaking and tears at the idiotic hoops they have to jump through all day long, every day, for years. Genuine mental health impact. They come home miserable and snap at their kids. Maybe he's channeling their frustration. And maybe we deserve it.
- networkimprov 6y ago
  That's the widespread failure to apply insights from Human Factors and HCI research, much of which has been around for decades. A different problem than better programming paradigms.
  - infinite8s 6y ago
    Is it really? Programming is just really low level HCI.
- osullivj 6y ago
  Sounds like you're talking about corporate environments, where the people using the software aren't the same folk as those paying for it.
carapace 6y ago
Go back to the page, look at the right-hand sidebar under "Links", it has: About me Email me Subtext Click on "Subtext". Read up.

noobermin 6y ago

Instead of complaining that the churning world of software is "stagnant" he could have just made a blog post talking about his ideas of what that futurist interface would be. That would have garnered a lot more of a positive attitude.

jacquesm 6y ago
Step one is to realize you actually have a problem. Then you can start solving it.

dcolkitt 6y ago

> Well we've been able to put graphics on the screen for decades, but "real" enterprise programming is still mostly pounding keys into text files and fussing over semicolons and curly braces. Visual interfaces are considered toys that "real" programmers don't need. You should at least consider the counter-hypothesis that C-style keyboard pounding is fundamentally more productive than visual interfaces. This shouldn't be that surprising. Text is much more informationally dense than audiovisual multimedia. There's a reason why books are still the preferred medium for information transmission after thousands of years. Sci-fi style visual coding sure seems cool. But I highly doubt that it will ever be as productive as a skilled developer typing out variables, functions and classes.

asdff 6y ago
Research has shown you focus more writing than typing. Imagine if you could program by rough drafting how your function works on paper. Like with arrows and all sorts of messy things connecting the structure of your code, but entirely understandable to another human what your function was to do without needing to understand a lick of code. Take this example(1) from the R subreddit about how to do matrix math, and the arcane R foo required to actually do something that is pretty simply explained in OPs image(2) to anyone with zero background in R or programming at all. Now, imagine how much more productive the world would be if the computer could take an instruction in a readable form like the OPs image, rather than the R jargon code actually needed by the computer to do the math described in the image. People would be learning to write their own functions right along side learning how to do math on paper. Instead, people today pay six figures and spend four years to learn how to turn the math they learned by hand in high school into something that can be ran on a computer, same as it was 30 years ago. 1. https://old.reddit.com/r/rprogramming/comments/kn2rgb/how_do_i_do_this_very_simple_thing_in_r_thanks_in/ https://old.reddit.com/r/rprogramming/comments/kn2rgb/how_do... 2. https://i.redd.it/ngxi8665zb861.jpg https://i.redd.it/ngxi8665zb861.jpg
- valenterry 6y ago
  Such things have been tried. They usually fail because of underestimating the amount of ambiguity, complexity manamagement and performance problems. SQL came pretty close - I mean, it was specifically designed for non-developers. Guess who's mostly using not nowadays.

cheschire 6y ago

I’m sorry, I still don’t buy it. Entry level programming concepts are now presented to kids in literal toys. “Real” enterprise programming has a heavy bit of tooling available now that wasn’t there in ‘96 with testing frameworks of all sizes, intellisense style code completion tools... I predict the next major functionality that will come is pre-trained machine learning that be dropped into code as simply as boolean statements are today. Or wait that’s a dream that isn’t here yet so I should be cynical and lash out at my kids’ LEGO Boost set for its antiquated battery tech or something.

tsimionescu 6y ago

This is like envisioning a world where everyone is building their own chairs and doing their own pottery. People who can do carpentry, or pottery, or programming are not in any way better or smarter than the average Joe. They have a different specialized set of skills than many other people, and they have the time to actually use those skills. Even if everyone knew carpentry and pottery and programming, they would not be using these skills in their day-to-day lives, because they have their own job to do. An accountant will not start programming their own accounting software, or even their own plugins - they will use some purpose-built software written by someone else, because it is a far more efficient use of their time. It's also important that programming is a fundamentally tedious endeavor. Even with the most high-level imaginable PL, where there would be no machine details to think about, you need to exhaustively define every detail of your business goal, much further than you would ever think about it in regular work. I am a programmer and I personally enjoy this kind of deep dive, but I have been in many meetings where I was trying to extract those details from domain experts and getting increasingly frustrating for them with all the probing. Even worse, you often hit points where you just can't get past some hand-waving, and now it's your job as a programmer to evaluate the trade-offs between different strict implementations of what is a fundamentally fuzzy requirement. And getting out of the fantasy of the perfect PL, you also then have to work with a real computer with real limitations that someone needs to know how to work in while representing the problem domain (e.g. replacing real arithmetic with floating point arithmetic and dealing with the new problems that stem from that). You also have to spend large amounts of time researching what others have built and re-using it when and where it is possible, and working withing the trade-offs those others have made - since there's no chance of writing every program from scratch, and there is no such thing as a general purpose domain specific library.

auggierose 6y ago
Very good points. The problem is that people are normally not using other peoples shitty chairs to try to build a space station.
- saasdev 6y ago
  Exactly! This is what scares me about the modern day no-code movement.

pfdietz 6y ago

The idea of programming with pictures goes way back. I mean, to the 1950s. It's one of the classic mistakes, like fighting a land war in Asia or going in against a particular ethnic group when death is on the line.

smolder 6y ago
I do not believe for a second it's a mistake to have visual representation or manipulation of software, it's just exceedingly difficult to make anything as versatile as text grammars and compilers. No one's done an adequate job because the ROI is terrible for building such things when you can't depend on massive adoption, which you can't.
- pfdietz 6y ago
  I think it's a proven mistake to use visual representations in place of textual representations for creating software. The information density is low, it's difficult to work with, browse, and search, and (a real killer) merging in version control systems is a nightmare.
  - khooke 6y ago
    Given the current day struggle to merge code with whitespace differences, merging differently arranged visual programming elements where the end result is the same but the positioning of the elements is just different sounds like a tough problem. Although linking of elements is probably key, rather than visual positioning. I imagine this is something IBM VisualAge had to deal with back in the late 90s. If I remember right local history was a key feature of VisualAge, a feature that carried across to Eclipse and is still there today.
- khooke 6y ago
  I think the limitation that no-one has managed to solve is that visual programming paradigm approaches tend to focus on solving a specific type of problem (drag and drop GUI builders are a perfect example), and this means their usage is narrow and they're never been widely adopted. Building a generic visual programming tool that can be used to solve any type of business problem across any business domain is very difficult if not dare I say it impossible.

imtringued 6y ago

>visualizing boolean logic trees and all kinds of other stuff, aimed at making programming more accessible and concrete to regular people. Here's an art analogy. You make it easier to create art by making an algorithm that takes fuzzy beginner line art that is not following proportions and has all sorts of problems and turn it into professional line art via ML. People will struggle at the far more challenging skill of choosing what to draw because it innately requires knowledge of human anatomy, perspective and many other skills beyond knowing how to use a pencil. Programming languages are equivalent to a pencil, tablet or other any input method in this analogy.

908B64B197 6y ago

> And yet there's a chasm of capability between programmers and users, and it's actually true that what programmers do isn't something most "normal people" will ever be capable of. But is that because programmers have some wildly special form of intelligence that most people don't have, or is it because our tools suck? Every time I used a "No-Code" solution it got me 95% where I wanted to be. The remaining 5% took twice as long as the first 95% because now I had to "go behind the scenes" and figure out the custom API exposed by whatever tool I was using. And then figure out a workaround that would inevitably break with the next version of the tool. And even with the No-Code, it's still being able to decompose a problem into smaller sub-problems, find the similarities and make sure they are well defined. I think there are a lot more folks with these abilities but you'll find them in math and engineering departments mostly.

erichanson 6y ago
Agree about no-code. But UI that generates code is a pretty cool paradigm. For most common patterns, end users don't need to know that there's a bunch of boilerplate code under the hood, but if that isn't sufficient, that remaining 5% can be reached by just jumping into some auto-generated code that's readable and well-commented. Mere mortals can do the 95% themselves and then call in a wizard for the hard parts, or try to figure it out on their own. Plus, any non-generated solutions can be highlighted, so it builds up a record of the places where the UI fell short.
- 908B64B197 6y ago
  Interface builders sort of work like that (creates the boilerplate for UI elements and formatting). But again, NeXT interface builder predates 1996.