The future is fewer people writing code? • Hacker News Board

Re: The future is fewer people writing code?

#161

Post by pystack » Fri, Jul 22, 2016, 8:47 PM UTC

nickbauman wrote: post #41

pmlnr wrote: post #6

“50 years from now, I can’t imagine people programming as we do today. It just can’t be." Dear writer, let me introduce you to FORTRAN, COBOL, LISP, or BASIC. These are alive languages, all 50+ years old. Coding didn't change much. The languages, the methodologies, the ideas change, but the approach is the same, and whoever thinks this will soon (50 years is not _that_ far) changes, have never had to debug something…

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…

As someone who is awful at Pictionary, I hope so as well. Just today, I defined a class with 4 functions. I had another function that created an instance of the class and called one of the functions. It changed a variable that would show up in the web browser formatted by CSS. And I can't even draw a dog in Pictionary...

Re: The future is fewer people writing code?

#162

Post by mempko » Fri, Jul 22, 2016, 8:47 PM UTC

I'm sorry the future is clear. Perl 6 will be the last programming language. The only way coding will become visual is when we use unicode symbols to do diagrams in perl 6.

Re: The future is fewer people writing code?

#163

Post by Jtsummers » Fri, Jul 22, 2016, 8:49 PM UTC

pystack wrote: post #159

Jtsummers wrote: post #104

Earlier quoted context omitted.

You agree with the author. >> No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. The real benefit of something like Project Bloks is that it actually removes the code; it allows children to begin thinking programmatically, without the obstacle of syntax. And this is a tough distinction to make, because people often use “programming” and “coding” synonymously…

Once I figure out the difficult specific and rigid details, I just want the most productive way to communicate these details to the computer. Writing code is the most productive, because it is more exact and I am faster typing than drawing/dragging/clicking. For example, with Vim, I can do a quick "Ack def function_name" to find the definition of a function. For learning purposes, Project Bloks looks great. But when…

I agree and I disagree at the same time.

For professional programmers, many people on this forum, the format that we use (text) is almost certainly the most efficient (yet conceived). It's made better with better tooling, of course, like IDEs that help us refactor, show errors in code as we edit, etc.

The author's point is that many more people will be programming in the future (hopefully) than are today. But not as professional programmers. For them, tools like (but not, of course, the same as) Project Bloks will be better.

Hell, we already do this today for ourselves. How many people get into the code-behind on GUIs regularly? Do you detail in code "button x will be placed to the left of button y, the center point between them will be ...". No, we often use some combination of markup language (XML-based like XAML, or something else) or visual designer (that may be generating a markup language version behind the scenes).

Then we connect the dots, the various objects to various actions or data sources, and off we go.

Just like 80% of my (early career) programming was really just gluing together a bunch of data sources for generating reports, much of what businesses need is in the same vein. Relatively (compared to the scale professional programmers like to think of our own work) trivial applications, that exist at a relatively high level (they're not writing a new DB server), connecting pieces together based off logical rules.

Re: The future is fewer people writing code?

#164

Post by Jtsummers » Fri, Jul 22, 2016, 8:53 PM UTC

pmlnr wrote: post #6

“50 years from now, I can’t imagine people programming as we do today. It just can’t be." Dear writer, let me introduce you to FORTRAN, COBOL, LISP, or BASIC. These are alive languages, all 50+ years old. Coding didn't change much. The languages, the methodologies, the ideas change, but the approach is the same, and whoever thinks this will soon (50 years is not _that_ far) changes, have never had to debug something…

It should be noted that that quote is not from the author, but from someone that the author is quoting.

Re: The future is fewer people writing code?

#165

Post by ewzimm » Fri, Jul 22, 2016, 9:04 PM UTC

rayiner wrote: post #151

ewzimm wrote: post #126

Earlier quoted context omitted.

I was focusing on 50 years into the development of the technology as a rough analogy. By 1966 it was much more mature, but look at how much things have changed. A mechanic from 1966 would find today's cars completely unrecognizable. They might appear somewhat similar from the outside, but on the inside they're basically just giant computers. We now have cars with varying levels of self-driving capabilities, drones re…

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 subject at hand, this article has nothing to do with the design of computers themselves. We could use the same basic Von Neumann architecture in 50 years and still get rid of traditional programming languages as a primary method of designing software, just like we use the same basic engine designs from 50 years ago but use entirely different methods of designing and controlling them now.

Take an engineer designing a jet in 1966 and put them with a 2016 team. They will have to learn an entirely different workflow. Now computers are heavily involved in the design process and most of what was done manually by engineers is now written into software. The same situation will happen 50 years from now for people who design software.

Take an extreme example like game creation. In 1966, you could make a computer game, but you were doing manual calculations and using punch cards. Now you download Unity and almost everything but the art design and game logic is done for you. Game design moved quickly toward these kinds of automated systems because they tend to have highly reusable parts and rely mostly on art and story for what separates them from the competition. But there's no reason why this same concept wouldn't apply to tools used for any kind of program.

The horse to car comparison was only meant to show that the development of a technology in the first 50 years (or any arbitrary number) will not necessarily look like the next 50 years. Well-established tools quickly fall out of use when a disruptive technology has reached maturity, even if that tool has been used for thousands of years. Right now, software design is difficult, buggy, and causes constant failures and frustrations. Once we have established and recorded best practices that can be automated instead of manually remaking them every time, there will be no need for manual coding in traditional programming languages. Machines are getting much better at understanding intent, and this will be built into all software design.

Re: The future is fewer people writing code?

#166

Post by cinquemb » Fri, Jul 22, 2016, 9:04 PM UTC

dasil003 wrote: post #91

Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming. No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. What the author doesn't realize is the enormous amount of processing power, shared culture and empathy that goes into human interaction. Even mighty Google doesn't have the compute power or the architect…

What the author doesn't realize is the enormous amount of processing power, shared culture and empathy that goes into human interaction.

Much of this isn't even useful for getting a task done, but mainly to keep the human in the loop as to how things can proceed… wasteful. I personally can't wait for prevalent brain computer interfaces. I don't think there is a need for computers to "understand" humans as far as it can observe the things we are optimizing for and do it better whatever way…

For me if I could choose between typing into keyboard on the seconds-hours timescale- latency in vs us timescales via other transmission channels, I'd pick the later every time, and twice on Sundays (which i guess is no surprise since I actually worked on such systems lol).

Re: The future is fewer people writing code?

#167

Post by gnud » Fri, Jul 22, 2016, 9:05 PM UTC

50CNT wrote: post #51

buckbova wrote: post #5

> To get there, programming tools should first use our language. For instance, to turn a button red, we shouldn’t have to write code. We should just be able to point to the button and select a shade of red. We've had that for over twenty years.

Concentrating on the "our language" part, we could probably create something that changes setting based on natural language. You'd say Turn the color of button3 in pane4 red Which would be equivalent to pane4.button3.color = 'red' Which is...actually a bit shorter, and a lot more precise. Who'd have thought. CSS is actually pretty close, descriptive and all. #pane4 #button3 { color:red;} Neat coincidence on the numbe…

Good! Now, the button should be a slightly different shade if the user is logged in. And it should be blue if the user is an administrator. And the customer requested that it shouldn't show up at all if the user lacks the 'foo' privilege.

Re: The future is fewer people writing code?

#168

Post by humanrebar » Fri, Jul 22, 2016, 9:06 PM UTC

bdrool wrote: post #97

dasil003 wrote: post #91

Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming. No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. What the author doesn't realize is the enormous amount of processing power, shared culture and empathy that goes into human interaction. Even mighty Google doesn't have the compute power or the architect…

> Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming. Programmers make it all the time too, or at least something very similar. See all those people who are on the endless quest for the "perfect" language, which usually means one which allows for writing the shortest code, sometimes at a very high cognitive cost for very little payoff. No, I really don't want to d…

> See all those people who are on the endless quest for the "perfect" language

To be fair, many programming language enthusiasts understand this and seek languages that properly frame the problems that need to be solved.

Sometimes languages seem to have a high cognitive cost because they expose that the underlying problem has a high cognitive cost. Some things that seem really simple are actually rather complex, like string manipulation and data sharing.

Re: The future is fewer people writing code?

#169

Post by ewzimm » Fri, Jul 22, 2016, 9:08 PM UTC

pessimizer wrote: post #127

ewzimm wrote: post #106

Earlier quoted context omitted.

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.

Why do you assume that this design document would be simpler to create than the traditional computer program? Because otherwise, this is exactly what happens now.

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 more reliable than people typing letters into a text editor.

Re: The future is fewer people writing code?

#170

Post by humanrebar » Fri, Jul 22, 2016, 9:10 PM UTC

adrianratnapala wrote: post #150

nickbauman wrote: post #41

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 thoroughly hated LabView when I had to program in it, but it did convince me that a graphical programming language could work

That's funny. I came away with the opposite opinion. Text is much better at describing details and it's much easier to be consumed by various things: people, editors, analysis tools, web apps, test engines, code generators, code transformation tools, ... I could go on.

Languages like LabView never have a complete toolchain (Prove me wrong by posting a small piece of editable LabView in a reply to this HN comment). They work well as domain specific languages, but that's about it.