Hacker News Reader

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.

Very good points. The problem is that people are normally not using other peoples shitty chairs to try to build a space station.

Exactly! This is what scares me about the modern day no-code movement.

You're missing that the computer can help, so it's more like a world where everyone is designing their own chairs, and the computer ensures that the chair is constructable, won't collapse, will fit a range of humans and so on, and finally sends it off to the 3D printer.

The accountant example is a really good one: most accountants likely do write their own Excel macros to suit particular customers or one-off situations.

I don't see anything wrong with it, just like everybody can do their own cooking.

People build their own furniture all the time when they buy things they need to assemble from ikea, target, etc.

People wire up electrical components when they hook up their TVs, computers, surround sound, etc.

People do their own plumbing when they hook up garden hoses or put on a new p-trap.

Mounting a TV bracket into studs or even hanging a picture is some slight carpentry.

These things work because there are standard connections and good design, but in many cases it took a long time to get to the current designs that are simple enough to be intuitive and come with any tools needed.

Standards and design have made these things possible. Even building a computer is similar. Many people's automation needs aren't so complex that they need to venture out of reasonable constraints.

You are using the wrong analogy. Computing isn't like building tools - it's about thinking better. Literacy is a better analogy - almost everyone is taught to read/write at an early age, and in fact not being able to do so is a significant hindrance to surviving in modern society.

Re. thinking better: I think we forget programming languages are just tools. (Almost) anyone can learn to program but it doesn't mean they're good at solving problems or are able to bring innovative/new/better solutions to solving current problems.

Reading and writing are just tools too.

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

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

2. https://i.redd.it/ngxi8665zb861.jpg

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.

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

I've worked in a company where programs were originally written with Max/MSP which is exactly that. It was muuuch harder to decipher for other humans than normal C++ & Javascript code.

Everyone I know using patcher tools end up switching to real programming after some years, and being much more happy like that.

I actually thought about buying a Wacom, because I make so many small scratch notes I throw away afterwards, to later find myself really needing them again. Besides, having hand drawn diagrams together with the code may serve as excellent comments.

Embedding diagrams in code seems like such a no-brainer. You can do it with a third-party extension in Visual Studio, but it’s still clunky and too hard to use.

This should be a basic thing that IDEs help you do.

Fair enough. I agree in the sense that typing isn't what takes up my programming time. 1000 lines of code at 100 wpm (which most coders could beat) is what, 10 minutes? I wish. I've spent hours on a single regex.

I think efficiency and accessibility are at odds with each other to some extent, and we've more neglected accessibility and flattening the learning curve, because we don't need it, we already know how to code. But custom software is basically a subscription service to the programmers that created it. I had a client that hired a guy who had invented his own programming language and built their whole system, then disappeared on not great terms. Boy were they in trouble.

But come to think of it, regex is a perfect example of something that could probably be interactively visualized and made more efficient. Let's ask google.

Yup: https://www.debuggex.com/

So I'm in vim or visual studio or whatever and I want to use this plugin and I... what? Google it in a browser and copy and paste regexes back and forth? This is so not 2021. The lack of a shared information model between tools/paradigms jumps out as a big shortcoming.

Text is also searchable. Can't stress enough how important that is.

And easily diff-able!

In the JetBrains IDEs, you can pop up a little inline interactive regex editor + tester widget, type in some candidate text, and edit your regex until the candidate text goes green.

> Text is much more informationally dense than audiovisual multimedia.

This has it backwards. Audiovisual multimedia have far higher raw bandwidth than text. I agree with your (implied) point, though, that text remains the preferred medium for technical use cases like programming for good reason: humans can't parse a firehose of audiovisual stimuli into precise mental constructs.

Text's typically linear structure and low information density are precisely why it has yet to be superseded, I think.

You are talking about bandwidth as if it was the same as information density.

I think the parent is taking about information as defined by Shannon. Essentially referring to entropy.

By that definition text is far more dense than AV.

https://en.m.wikipedia.org/wiki/Entropy_(information_theory)

I stand corrected; on this view text has more entropy due to limitations of our visual system and working memory (i.e., the encoding), no? We're pretty good at hashing short symbol strings to referents. If we could decode a grayscale image with the same precision, visual media would have higher entropy.

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

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.

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.

Is it really? Programming is just really low level HCI.

Sounds like you're talking about corporate environments, where the people using the software aren't the same folk as those paying for it.

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.

Why not, though? Programming itself is a layer of abstraction. Why did we invent this bespoke complicated and arbitrary syntax that can be explained succinctly with a comment in your native language, rather than just develop the computer to interpret commands in common native language syntax directly? I shouldn't have to remember that ls is list directory contents. I should be able to type all sorts of permutations of 'show me what stuff is here' in my language and not some bullshit syntax that someone came up with on a whim 50 years ago, if the computer was truly developed to be a tool for everyone.

I'm not confident it's going to change for the better and democratize what computers can truly do, simulate and model. People who've already paid the cost of memorizing all the ins and outs of complicated computer syntax don't really care how much of a hill they've had to climb anymore now that they've learned enough to be familiar. Now you have this memorization lock in, where you've spent years and perhaps thousands with university learning some dense programming language and start building your tooling around what you've learned, and in the process you force the next generation to have to learn that syntax if you are to hire them, and so on and so forth. That's why we've been typing ls since the 80s and we will still be typing ls in 50 years. I'm sure the authors of ls would find that horrifying.

Even when telling an actual human being to do something there are misunderstandings and misinterpretations. The idea that it's feasible with our current technology to just design programming such that we can just write natural language and the computer will do what we envisioned is absurd. Natural language is very imprecise and squishy and not at all suited to programming. Attempts to make code look more like natural language such as AppleScript and COBOL suck.

This is all complaining about the insignificant problems of programming. Syntax is something you get over after you're out of school. A good Java programmer will also be a good Common Lisp or C or APL programmer within months of first seeing that language.

The complexity of programming lies in coming up with abstract models for real-life problems, and in encoding those models in sufficient details for a machine to execute them. It also lies in knowing the details of how the machine functions to be able to achieve performance or other goals (e.g. avoid parallelism pitfalls). Until we have AGI, none of these problems are even in principle solvable with better tools to the point that someone who hasn't invested in learning how to program for a few years will be able to do anything that isn't trivial. The best possible visual PL can't change this one iota.

What could be doable is creating more DSLs for laypeople to learn, rather than trying to do very complex things through a GUI. One of the few areas where there has been tremendous success in having non-programmers actually do some programming is in stuff like Excel. That is a very purpose-built system, with clear feedback on the steps of computation, very limitted in what you can actually program, but comprehensive enough for its intended domain, and is probably by far the most utilized programming environment, dwarfing something like vim by an order of magnitude.

>This is all complaining about the insignificant problems of programming

To me, syntax is a huge problem. Sure, you learn it in school. Computer Science School. Not everyone is a computer scientist. Some people are political scientists, environmental scientists, mathematicians, statisticians, etc., all of whom have their own difficult four years of schooling, and simply don't have the time to learn this complicated syntax without trading something else off. You don't think its a big deal since you've already paid that price of time. Well, not everyone can afford to pay that time, and it's a damn shame that in order to make full use of all a computer can do, you need to spend this time learning this sometimes remarkably clunky syntax before you can even begin to work on your real life problem. Imagine how much more technological and societal progress we would make if everyone could make computational models about their question at hand without having to spend years and thousands of dollars working with unrelated example data in undergrad, sometimes even using instructional languages that have no use outside of school. To me, that's the world that The Jetson's live in.

Because human language is not specific enough. Code isn't complicated, it's unambiguous. You can always alias ls but that doesnt change the model much does it?

> just develop the computer to interpret commands in common native language syntax directly?

We have that: e.g. Google Assistant. (If you don't mind needing an internet connection, and sending your voice to the cloud.)

> I shouldn't have to remember that ls is list directory contents.

Nobody's had to do that in 35+ years, except those of us who prefer that sort of thing. The rest click on some folder icon or something.

True - but it seems like some middle ground might be possible - where the power of the shell is all available, but with the cognitive support that the GUI provides also present.

Google Assistant et al do not do that. I can't ask Siri to show the contents of my directory. I can't ask Siri to run anything on the command line at all. These voice assistants just do a number of predefined functions, they don't offer 1:1 control of your device the same as traditional inputs. Yeah, that's true that most people use a GUI, but the point still stands. You have to remember these distinct workflows to do something readily explained in person. An old person might have to take a computer class because they want to send an email, whereas an intutively designed system would take that persons input, "email jake" and do all the behind the scenes stuff we do ourselves to compose emails for us. An ideal computer is a secretary that can do everything you can think of since you are both versed in the native language. Siri is not a perfect secretary, Siri is like an elevator man only able to press one of the couple dozen buttons on the wall for you.

> I shouldn't have to remember that ls is list directory contents

I mean, surely you use your own abbreviations when writing, no ? How would you abbreviate "list directory contents" ?

For instance I have `alias l=ls -lha` - and if it was instead list-directory-contents I would have `alias l=list-directory-content -lha`

e.g. just look how hard powershell sucks with those long verbose command names, it's unuseable

Isn't that essentially Microsoft and Apple’s business model and how they got to where they are today?

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

Or Excel for that matter.

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.

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?

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.

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.

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.

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.

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.

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.

I see it as just a very difficult problem. Flip the problem around and you can maybe see my point of view. IDEs for text programming are getting more intelligent, to the point where in certain languages, arranging function calls and assigning parameters could almost be done completely with autocomplete menus. Go a few steps further and you can connect these things without the frequent naming-of-things exercise that programmers undergo.

Part of the reason I am so bullish on visual programming is that it lets us skip the excessive naming-of-things that is part of text programming. I would rather copy-paste a pile of colors and shapes that describes an algorithm and connect it to the right inputs and outputs. I think nameless shapes would be more immediately recognizable than identifiers from all the various naming schemes people use in their code.

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.

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

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

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

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.

Interface builders sort of work like that (creates the boilerplate for UI elements and formatting).

But again, NeXT interface builder predates 1996.