Live data from Hacker News

The future is fewer people writing code?

techcrunch.com

181–190 of 256 posts

Re: The future is fewer people writing code?

#181

Earlier quoted context omitted.

There's a serious gap in the writer's mind about computation and programming. It's like the author is suggesting that "eventually we won't need writing: it will be replace by writing-thinking or picture-writing". It's completely absurd. Specific, complex ideas can only be described and communicated in text. Not pictures. Blueprints, for example, have a pictorial element to them, but their fundamental value is our abi…

I don't think we can distinguish text and pictures so easily. Look at Chinese, look at Egytian hieroglyphs. Even when "hierglyphics" is used as as a term of abuse of for programming languages synatax -- it ends up pretty popular. I thoroughly hated LabView when I had to program in it, but it did convince me that a graphical programming language could work -- if only it refrained from doing the cking stupid things tha…

"I don't think we can distinguish text and pictures so easily. Look at Chinese, look at Egytian hieroglyphs."

My understanding is linguistics research has pretty thoroughly debunked this idea.

Don't remember the experimental design (was a long time ago, sorry), but I believe a study showed Chinese readers basically translate the characters back into the sounds of spoken language in their heads, before any processing of meaning takes place. In other words, pictographic mnemonics may be helpful when first learning the characters, but play no role for a fluent reader.

I suspect a similar thing will be true with programming for a long time to come. Even if you try to replace keyboard characters with other icons, it will be just substituting one arbitrary association between symbols and meaning with another. (Which is basically what language boils down to, anyway.)

Re: The future is fewer people writing code?

#182
post #165

Earlier quoted context omitted.

Cars are not "basically just giant computers" on the inside. Computers are used to control various engine parameters, and aspects of the transmission and suspension, but all the parts that make the car go are just refined versions of what existed in the 1960s. Okay, so now we use computers to control valve timing instead of mechanical means. But the principles of what valves are and how they make the engine work are…

The concept of what change is more or less significant can be pretty subjective. I'm not talking about things like fuel efficiency, although those are some really interesting facts. Autopilot in 1947! didn't know that one. Yes, cars and jets still use the same basic architecture for what makes them move, but the control mechanisms for that architecture have completely changed. To bring your comparison closer to the s…

"Take an engineer designing a jet in 1966 and put them with a 2016 team. They will have to learn an entirely different workflow."

Send them to the "PCs for seniors" course at the local library to learn the basics of clicking around on a computer. Then a one or two week training course on whatever software is used to design planes these days.

Getting up to date on modern "workflow" is not going to be a major hurdle for someone smart enough to design a jet. Heck, it's very likely there could be someone who started designed jets in 1966 and still designs them today. (Post retirement consultancy.)

Re: The future is fewer people writing code?

#183
post #165

Earlier quoted context omitted.

Cars are not "basically just giant computers" on the inside. Computers are used to control various engine parameters, and aspects of the transmission and suspension, but all the parts that make the car go are just refined versions of what existed in the 1960s. Okay, so now we use computers to control valve timing instead of mechanical means. But the principles of what valves are and how they make the engine work are…

The concept of what change is more or less significant can be pretty subjective. I'm not talking about things like fuel efficiency, although those are some really interesting facts. Autopilot in 1947! didn't know that one. Yes, cars and jets still use the same basic architecture for what makes them move, but the control mechanisms for that architecture have completely changed. To bring your comparison closer to the s…

[deleted]

Re: The future is fewer people writing code?

#184
post #88

Earlier quoted context omitted.

I'm going to disagree on that. Every day I wish I could intermix textual and pictorial representations of logic in the programming I do. In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. The flowchart and decision tree exist for a reason to describe algorithms.

> I'm going to disagree on that. Every day I wish I could intermix textual and pictorial representations of logic in the programming I do. In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. I've done this. It doesn't work. You need more details than can be cleanly represente…

Sure, the contents of the text box is necessary. But treating the contents as a black box is not something new, and I don't see it as a problem. That's pretty much every function call ever - all I'm interested in is the calling signature. A combination of pictures and text would suit me far better than what we have today, which is text everywhere, and diagrams / flowcharts afterwards if you get around to writing documentation.

Re: The future is fewer people writing code?

#185
post #106
post #90

Earlier quoted context omitted.

There's an important distinction though between being able to write a compiling (or even functional) program and being able to write a program that serves a particular purpose.

I'm talking about human-guided programming without using traditional programming language, creating a design document to lay out what it does and how data flows and allowing the computer to sort out the details based on a stored data set.

"creating a design document to lay out what it does and how data flows and allowing the computer to sort out the details based on a stored data set."

This is exactly what programmers do today. We just call the "design document" a "program".

Over time, our design documents become higher and higher level, with the programmer having to specify fewer details and leaving more of the work of sorting out the actual details to the computer.

Re: The future is fewer people writing code?

#186
post #88

Earlier quoted context omitted.

I'm going to disagree on that. Every day I wish I could intermix textual and pictorial representations of logic in the programming I do. In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. The flowchart and decision tree exist for a reason to describe algorithms.

> In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. As long as it is very simple. Electronics already have a highly developed visual language for describing their functions - but if what was going on inside every chip was illustrated just as what was going on between chips,…

Yes, and that's how I would use a language that would allow mixed picture and text logic flows. At a certain level of abstraction block diagrams greatly assist understanding program flow, and it is redundant that I have to write the code and then draw the block diagram later for documentation.

Going back to electronics, I don't think anyone would argue that schematic block diagrams are inferior to reading the raw netlist. Similarly, I feel programming could be improved if IDEs for popular langauges would allow connecting functions together in a streaming manner. Of course, I am aware this exists, Simulink, LabView, FPGA schematic workflow, but these are niche languages that I don't work in.

Re: The future is fewer people writing code?

#187
post #165

Earlier quoted context omitted.

The concept of what change is more or less significant can be pretty subjective. I'm not talking about things like fuel efficiency, although those are some really interesting facts. Autopilot in 1947! didn't know that one. Yes, cars and jets still use the same basic architecture for what makes them move, but the control mechanisms for that architecture have completely changed. To bring your comparison closer to the s…

"Take an engineer designing a jet in 1966 and put them with a 2016 team. They will have to learn an entirely different workflow." Send them to the "PCs for seniors" course at the local library to learn the basics of clicking around on a computer. Then a one or two week training course on whatever software is used to design planes these days. Getting up to date on modern "workflow" is not going to be a major hurdle fo…

My point was not that they wouldn't be able to learn it, only that the tools and methods of design have changed and become much more automated. That process has not stopped, only accelerated. The people in this article are saying that the process of making software in 50 years will be very different from the modern method. It will rely heavily on automation and what was done manually by writing in programming languages will be integrated into systems in which the intent of the designer is interpreted by a machine. You can see it in IDEs today. They already analyze and interpret code. This is extremely primitive compared to what we will have on 50 years. The progress of machine intelligence is clear and doesn't require any major breakthroughs to continue for the foreseeable future. It will be as irresponsible for most people to write everything manually in 50 years as it is not to use a debugger today. No doubt there will be people doing things the same way, just like we have traditional blacksmiths today, but we will not have billions of people typing into terminals in 50 years. The criticism is against the idea that in the future, everyone will need to learn how to code in the same way as everyone needs basic arithmetic. That is not a plausible version of the future. It's trending the other way, more automation, more code reuse, less manual entry.

Re: The future is fewer people writing code?

#188
post #165

Earlier quoted context omitted.

The concept of what change is more or less significant can be pretty subjective. I'm not talking about things like fuel efficiency, although those are some really interesting facts. Autopilot in 1947! didn't know that one. Yes, cars and jets still use the same basic architecture for what makes them move, but the control mechanisms for that architecture have completely changed. To bring your comparison closer to the s…

"Take an engineer designing a jet in 1966 and put them with a 2016 team. They will have to learn an entirely different workflow." Send them to the "PCs for seniors" course at the local library to learn the basics of clicking around on a computer. Then a one or two week training course on whatever software is used to design planes these days. Getting up to date on modern "workflow" is not going to be a major hurdle fo…

[deleted]

Re: The future is fewer people writing code?

#189
post #169

Earlier quoted context omitted.

Design is always going to be a part of creating something. What this article is arguing is that manual typing of text by humans using traditional programming languages will not be the primary means of implementing those designs in the future. We don't yet know how to make computers into good designers, but we know that we can create tools that translate designs into executable code that can be less error-prone and mo…

My question is how is drawing rather than writing simplifying anything i.e. what is the gain from moving from traditional programming to some sort of theoretical picture programming? Is it that you can draw lines between things rather than just assuming that the line from one symbol points to the next symbol on the line? Does that simplify things, or make them more complicated? > we know that we can create tools that…

Drawing rather than writing is just one method. A lot of it will likely be conversational. I could imagine a designer with an AR overlay speaking to a computer which offers several prototypes based on an expressed intent. The designer chooses one and offers criticism just as a boss would review an alpha version and suggest changes. The machine responds to the suggestion and rewrites the program in a few fractions of a second. The designer continues the conversation, maybe draws out some designs with a pencil, describes a desire, references another program which the machine analyzes for inspiration, and the machine adjusts the code in response. This is just one of many possible examples. The point is that software design is trending toward more automation. Coding is not a new essential skill that everyone will need on the future. Human-machine interactions are trending toward natural and automated methods, not manual code entry. Most people need to learn to be creative, think critically, analyze problems, not learn the conventions of programming languages.

Re: The future is fewer people writing code?

#190
post #169

Earlier quoted context omitted.

Design is always going to be a part of creating something. What this article is arguing is that manual typing of text by humans using traditional programming languages will not be the primary means of implementing those designs in the future. We don't yet know how to make computers into good designers, but we know that we can create tools that translate designs into executable code that can be less error-prone and mo…

My question is how is drawing rather than writing simplifying anything i.e. what is the gain from moving from traditional programming to some sort of theoretical picture programming? Is it that you can draw lines between things rather than just assuming that the line from one symbol points to the next symbol on the line? Does that simplify things, or make them more complicated? > we know that we can create tools that…

[deleted]
Post reply on HN