Live data from Hacker News

The future is fewer people writing code?

techcrunch.com

171–180 of 256 posts

Re: The future is fewer people writing code?

#171
post #81

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…

Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative. Given the ease of preparing written text compared to drawing schematics nobody would go to the trouble of doing so if that weren't the case.

> Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative.

Blueprints don't change as much as software does. It's not generally interesting to diff, fork, reformat, or patch a blueprint.

Re: The future is fewer people writing code?

#172
post #97

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…

Quite true.

Apparently many programmers keep forgetting that the syntax is just a small part of:

- language itself

- toolchains (compilers, interpreters, AOT, JIT, hybrid)

- differences between implementations and specific behaviour

- libraries, both standard and the most well known third party ones

- IDEs

- build systems and deployment options

- extra tooling for correctness like static analysers

- culture of the people that usually cater for the language

Hence why it is easy to dabble and grasp concepts from multiple languages, but very hard to very quite proficient in a few of them.

Re: The future is fewer people writing code?

#173
post #88

Earlier quoted context omitted.

And it is on a whiteboard because it is not useful enough to record in a longer term medium. I'm not saying diagrams are useless, they just make a poor substitute for syntax.

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 represented on a diagram. How do you do namespacing for example? Which database schema will that box connect to? How will it reconnect?

All 'visual programming languages' fall back to text boxes constantly. Inevitably the contents of those text boxes are needed to understand or execute the visual representation of the program.

Re: The future is fewer people writing code?

#174
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…

Emojis = "picture-writing"

Re: The future is fewer people writing code?

#175

Earlier quoted context omitted.

The difference comes down to syntax vs. semantics. The problem with assembly isn't its syntax (mov eax, ebx is fairly readable), it's that the underlying semantics are too low level. Exploring new abstractions/semantics to use is very useful (local variables, first-class functions, algebraic data types, etc.), but optimizing solely for source program size leads to a language that's great for code golf and not much el…

Outside of J/K/APL few languages truly attempt to optimize for source size. Few people truly, deliberately optimize around source size outside those language programmers, demoscene types, and mathematicians/engineers-turned-programmers.

Add Ruby to the list. Many gems (and frameworks) advertise with how much you can pack into a single line of code, at the expense of seemingly impenetrable magic happening behind the scenes.

Re: The future is fewer people writing code?

#176

Earlier quoted context omitted.

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…

From a first principles perspective, it's me and the computer, and I want the computer to do something. My laptop has the following input devices: keyboard, mouse, webcam, and microphone.

I mostly use the keyboard and mouse. There are some places where the mouse is better than the keyboard. I was playing online chess today, and I like to drag and drop the pieces. It feels more natural and not that much slower than inputting the coordinates.

But when I was coding today, I needed to navigate through my code quickly. The mouse would have been much slower than vim's CTRL-D, CTRL-U, and /search_keyword, so I used the keyboard.

For the non-professional programmers, Project Bloks might be more like chess's drag and drop. It's more natural and not that much slower for simple tasks. I can see why non-professional programmers may like it.

Re: The future is fewer people writing code?

#177

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…

Emojis = "picture-writing"

And with emojis you can describe how to build a bridge precisely?

Re: The future is fewer people writing code?

#178
post #81

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…

Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative. Given the ease of preparing written text compared to drawing schematics nobody would go to the trouble of doing so if that weren't the case.

When I write "2.5 mm" this is not narrative. If you want to explain "2.5 mm" without using text, how would you do that? The only way to do it is to use something literal from the real world. That's what we're talking about when we're comparing blueprints to programming. I think the word is literal. Can't avoid the need for text when it's precision we're after.

Re: The future is fewer people writing code?

#179

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…

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…

Sure, we agree the code is not the important thing, but that's a very oblique point.

Where I disagree is that "removing the code" will help someone gain better understanding. It might help them dip their feet in and get at the core of what's important (hence MIT using scheme for its intro CS class for 30 years). However as soon as someone passes the beginner phase, the difficult thing is expressing the ideas succinctly and unambiguously. That's exactly what programming languages do.

A good analogy might be mathematics notation. You can explain basic math without any notation, but as soon as you get to more complex stuff you need the notation to help you reason about it and encapsulate the ideas succinctly. Similarly, graphical programming environments can do a ton of useful stuff (HyperCard is what got me into programming at the age of 10), but they will always always hit a wall (until true human-level AI anyway). The author definitely doesn't get that part.

Re: The future is fewer people writing code?

#180
post #169

Earlier quoted context omitted.

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 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 translate designs into executable code that can be less error-prone and more reliable than people typing letters into a text editor.

I disagree. Maybe you know, but I haven't seen any indication of the sort.

Post reply on HN