Hacker News new | ask | show | jobs
by coderjames 3488 days ago
>To fix this, we need to increase the currently tiny number of people who are able to write, modify, combine and share software. We need a tool that makes writing software easy and fun, and accessible to everyone. A tool that enables software literacy.

Global access to niche knowledge doesn't seem like an effective use of the world's time to me. Let's look at this same idea, but replace "develop software" with "perform brain surgery."

> To fix this, we need to increase the currently tiny number of people who are able to perform brain surgery. We need a tool that makes performing brain surgery easy and fun, and accessible to everyone. A tool that enables neurosurgical literacy.

Just like Software Engineers don't need to know how to perform neurosurgery, accountants, marketers, burger flippers, and salespeople don't need to know how to write software. I'd rather the CEO of the company I work for spend time on growing the business, not learning how to write a "Hello, world!" program.

8 comments

Ok, but what makes brain surgery a good analogy? Why not replace "writing software" with "hopping on one foot" instead?

Most of us own computers that can run software, but we don't own the equipment required to do brain surgery. More people have problems that can be solved by software than can be solved by brain surgery.

I think software is more like basic arithmetic: a bit of training (plus the pen and paper you already have) and you can do something yourself that used to require a professional. Of course, software is way more powerful!

A lot of people use software, but does that really mean they need to know how to create their own?

sbov's car analogy suggestion is apt: a lot of people drive cars, but should they be expected to be able to maintain their own?

A kinda related side observation:

I found my brief stint working with Max/MSP (a visual language typically used by musicians) to be illuminating. This is a tool for non programmers (musicians in this case) to write software for their own use and it succeeds at this. Its kind of like excel for musicians. But, just like excel, the software created by these people, while functionally they work and do what the musician wants, are written in pretty terrible spaghetti code (giving visual programming a bad name in the process), because the users never learned software engineering principles (even simple ones like abstraction).

Just as with excel, this is fine for write-only once-off tools and I certainly do think that more excel-like tools that allow non-programmers to solve their own problems are necessary and will help in software literacy. However, I don't think that these tools or skills will achieve a world where most people can write and modify software in general because they won't have been trained in the software principles we take for granted. Try and debug a large non-programmer-created excel sheet sometime for example. :)

My point is that its not exactly like basic arithmetic, but as you say its not thaaat different either. Yes, some excel-like tools and a bit of training will allow more people to create their own little solutions to their day to day problems, and this is something worth striving for, but it won't be enough to let them create/modify large software in the general case. For that, they need the full blown mathematicians training (or, some of it, anyway).

> you can do something yourself that used to require a professional

I suppose THIS is what the goal is or should be. Not to make everyone a programmer, but to allow people to do more things for themselves that they previously required experts for.

I haven't used it personally but I have heard the same issues come up with LabView visual programming for laboratory automation and instrument control.
The difference is most people won't need brain surgery in their lifetime. A more relevant comparison would be car maintenance.
Well, most people don't know how to fix their car, so the result seems to be the same to me.
Another fault with his logic is that programming languages are very specialized and very powerful tools. You could try to dumb them down to make them work for the average person (which has been done ad nauseum at this point) but then they would no longer be capable of solving certain classes of problem either simply or quickly.

To go back to the car analogy, yes most people understand at least at a rudimentary level how modern cars function, but most people also lack the tools to do anything but the most basic of maintenance on a modern car. Even assuming they had the tools available, they still wouldn't understand how to use them or even how to diagnose certain classes of fault. We could say that in order to allow everyone to perform maintenance on their cars at home that car manufacturers aren't allowed to use anything but standard tools to build their cars, but that would basically undo the last ~30 years of advances in the auto industry. Want to own a Tesla? Oh sorry, non-standard parts, going to need to pull that off the market. The situation in the programmer world is basically the same, yeah we could make everyone program in something like BASIC (and even that is probably too complicated for most people), but that's kind of like tieing one hand behind your back and then jumping in the deep end of the pool. Programming is hard enough as is, we don't need to start introducing handicaps.

I don't like the car analogy too much since a car is basically a tool while computers are a medium. I agree with you that programming languages on the other hand, definitely are tools.
He meant that people usually have cars that they need to run well. They just pay someone else to take care of it.

Similarly people usually have computers that they want to run programs on. They don't write them themselves though - they pay someone else to take care of it.

People don't commonly need brain surgery. It wouldn't really be a useful skill unless it is your full-time job.

Anyway I don't think you need an analogy to reason about this.

but if you were informed about how your car worked, you would know that the 200$ "break pad cleaning" recommendation your dealer was asking you to do is pure bullshit.
I disagree with your analogy. In my opinion, programming is more analogous to composition. Most courses of study require at least one composition course, because no matter what discipline you're studying, it's important that you be able to organize your thoughts and express them clearly as well as understand the formal expressions of others.

I personally experience a huge overlap between ordering my thoughts for writing and making a mental model of a problem and its programmatic solution. Yet it's easier for most people to pick up a pen or open a word processor and express themselves than it is to write a working program.

Why should it be so? Apart from implementation details of hardware platforms and runtimes, you're really talking about expression in different units: subroutines rather than paragraphs, APIs rather than outlines, user stories rather than theses.

To bring it back to your analogy, consider what a tool that lowered the barrier to entry to brain surgery might do. It might certainly do things like list the particular skills, tools, and medications required to perform certain procedures. It might provide a check list of crucial steps and a sort of troubleshooting tool. It isn't going to make an expert out of an unskilled user, and a particularly skillful surgeon might not benefit from the tool at all, but on balance, it would raise the baseline competency of many users and help ensure that certain critical requirements were met.

A good assisted programming tool would do the same. It would help the user accurately model the problem, it would advise the user of certain best practices, and it would certainly warn the user of common mistakes. This is all very much in line with a good word processor, with features like spellcheck and document templates.

So I disagree that programming is analogous to brain surgery. Programming itself is a tool for the expression of an idea and much more akin to composition, and there is no good argument in my opinion against tools to assist with either. Remember that for a large part of our history, literacy was considered a niche skill, and widespread literacy led to explosive growth of our knowledge of the world. I'm not one of those "literally everyone should learn to code" types, but there is quite a lot of potential in spreading programming literacy, even if you feel most people have no business practicing it.

Why not we (software developers) take the route of improving end-user software and letting people easily accomplish their mundane everyday tasks, instead of letting them program as a remedy to the sorry state of software? Have you looked at it that way? Would people buy a car that required them to tweak it and service it right after it went out of the showroom?
I think you misunderstood me. I'm not saying that people should become literate in programming so they can program their own solutions, although that'd obviously be good. I'm saying that we should encourage people to become literate in programming if only so they could express their needs more clearly and evaluate solutions better.

I likened programming to composition. Most people who took composition courses don't necessarily need to write papers on a daily basis, but they certainly benefit from being able to interpret and evaluate material. If I could get people to understand the general concept of a data type, I'd certainly have an easier time of communicating with them and satisfying their needs.

That's definitely an approach we should keep trying. But it hasn't worked out very well so far and I'm convinced that it's impossible to create an application that fits 100% of the needs of 100% of its users. I would definitely buy a car that allows me and maybe even makes it easy to tweak it. But I wouldn't want one that requires me to do so.
> Apart from implementation details of hardware platforms and runtimes

The platform described to share all this knowledge and code is beyond what humanity can build today. The manifesto described that we share "All cells exist in a single, globally shared hierarchy". The trust problem has many forms, from trusted medical info on Wikipedia, Facebook fake news filtering, to open Github code with hidden backdoors.

See a list of 100+ projects that are struggling with trust and full decentralisation: https://github.com/redecentralize/alternative-internet

That's an awesome list, thanks. There seem to be two concept intermingled here though. First is decentralization which I'm a big fan of not only for social and humanitarian reason but also because I'm convinced that it's the better design. And while there are many problems still unsolved, there are also very promising approaches. The other one is trust which is required in centralized and decentralized networks but has a very different taste in both and I think it might be actually easier so solve in an open, decentralized environment. Lastly, I wanted to point out that while all cells exist in a single address space, that doesn't mean that every cell is accessible to everyone.
We went to the moon. A lot of people said that was beyond what humanity could build then, too.
This was an insightful and thought-provoking response. Thank you for taking the time to write it. Given how much a word processor's spelling and grammar checking improves my own writing, I can definitely see how an equivalent assisted-programming tool could help people.
We have pretty good static analysis tools now which warn the user of common mistakes at the code construction level. But at the architecture and design levels I don't think there is much that tools can do short of AGI.
There is plenty a tool could do to aid software design. You might sit down to plan a new program and launch your programming assistance tool. It might ask questions like what platform your program should run on, what time or storage constraints it must run under, whether it's a server or intended for users, and so on. As you go, it creates a project scaffold for you to build on and makes recommendations: to consider .NET since you're targeting Windows, to follow this security tutorial since you'll be using a database for persistence, to use a particular pattern for the application's core responsibility, etc.
Oh, I think we could go a lot further as a society if we had more understanding of basic software and related concepts like revision control.

It hurts my head watching people sometimes, going through major contortions to achieve something just because they do not know a few commands or programming ideas. Is it “better” to develop massive, twisted dependencies on programs like Excel, when a few lines of real code would have been equivalent and infinitely more maintainable (not to mention vendor-independent)? Is it better to have massive, manually-copied-around duplicates of files because no one knows about revision control systems? Is it better to do things manually, like repetition, that computers do extraordinarily well?

Programming not only gives you the power to solve arbitrary previously-unknown problems but it puts you in the mindset to assume that an external tool will work better than an internal one. It makes you stop waiting for Your Only Vendor to “implement” feature X, and instead realize that there are already 4 other ways to do that with existing tools.

I thought long and hard about a apt analogy and decided on "literacy" because I'm hoping that using computers as a medium for formulating and exchanging ideas would have a similar effect as reading and writing had.

I can very well imagine that a couple of hundred years ago people thought that writing was some niche knowledge and it's perfectly fine to leave that to the monks.

My goal is not to make everybody a professional software engineer just like everybody should not be a professional author. But people should be able to use the medium to discover and understand powerful ideas.

Interestingly, that is precisely the way I've been framing the problem for several years now. For example, here's a comment from a couple of years ago: https://news.ycombinator.com/item?id=8308881. And one from a couple of months ago: https://news.ycombinator.com/item?id=12668086.

"I think we're in a preliterate state with programming: it's hard for anyone to quickly look at a program listing and answer the basic sorts of comprehension questions we might test school kids on for prose.

"What we find easy is to read programs we wrote. Recently."

Here's my manifesto based on the same starting insight as you: http://akkartik.name/about. And my project (with one other collaborator): https://github.com/akkartik/mu

Nice to meet ya! I'd love to chat more at some point once the HN rush dies down, perhaps over email (address in profile). We seem to be attacking the same problem but from very different directions. I'm focusing on new methodologies rather than tools, and heading down to fix the foundations before creating empowering interfaces on top. Cross-pollination of ideas would be useful.

Nice to meet ya as well! Your material looks very exciting. I'll drop you an email once I've digested it all.
I don't think it's a good analogy.

The typical U.S resident interacts with or otherwise has their life significantly effected by software not only every single day, but likely nearly _every single minute_.

The same is not true of brain surgery -- it's probably not even true of 'medicine' in general.

I absolutely agree with the OP that being an empowered individual in this environment absolutely requires some degree of 'computational literacy', and optimally would involve nearly every person, yes, actually knowing how to write software to some extent, the more the better.

I don't agree this is realistically going to happen though. The Hypercard future is not the road we went down. I do think this has pretty major unfortunate impacts on the degree of alienation and loss of control most people are likely to continue to experience in our highly digital society though.

But I think the best thing we can do right now is focus on some notion of accessible "computational literacy" within the present actually existing environment, not thinking we're going to get everyone to the point of being able to build actually-useful software. But they still can _understand_ software better. A hypercard-like learning environment might be useful for this. But it's unlikely to change the face of software development any time soon.

Many many people write scripts in Excel. It is easy and accessible to the majority of people who have computers today. Some accountants and quants would even call it fun.
yeah but 40 years ago people said this about spreadsheets, and 25 years ago about web browsers, and 50 years ago about computers