Hacker News Reader

Comment by dasil003 | Hacker News Reader

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 architecture to replicate this. Until computers can understand humans at a human-level this will not be possible. Several breakthroughs will be necessary, and even still I expect decades/centuries before it happens if it even happens. Essentially we're talking about the Singularity.

View on HN

> 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 do a massive amount of mental backflips just to save a few characters, thanks.

There isn't anything wrong with this kind of obsession tbh. We do need SOMEONE inventing, experimenting with new languages and if someone else is excited about doing so I'm quite ok with that :)

Many people looking for the "perfect language" want one that minimizes cognitive costs. An initial increase (comprehensive type systems like in MLs; rust's notion of ownership and lifetimes; Spark Ada's comingling of specification, code, and types) in cognitive cost which, once internalized, results in reduced cognitive costs for certain tasks. Less time spent developing tests. Less time debugging. Less time spent in maintenance (not because it's not needed, but because it goes faster when it's done).

Or learning one javscript framework after the other where you do the same thing with different syntax.

Do you write in assembly?

If not, you clearly see some gain in more terse syntax.

Seems like a good thing to explore, although perhaps it should not be one's sole focus in life.

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

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.

Not sure. I mean yes you can abuse some languages and fit an entire program on 1 line (see any golf project). But I can generally grok a 100 line scala program in the same time as a 100 line Java program, and the scala program is usually about twice as dense. (So I am groking scala twice as fast).

I generally find this to be true for myself, too. Although I would add the qualifier that I find Java to be an exceptionally wordy language, for lack of a better term. It seems to take a lot of talk to do a little in Java even compared to other object oriented languages.

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

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.

I am obsessed with programming paradigms, not languages.

Best way to learn a new programming paradigm is by learning a new programming language conducive towards a certain manner of problem-solving.

So yes, I am obsessed with programming languages. But not for the reasons you listed.

The language is the medium. I like writing code that I can look at and be happy, for no real reason. For traditional art, some prefer oils some prefer water-colors. It's the same for programmers. http://programmers.stackexchange.com/a/16164

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. But the fact of the matter is thinking
  programmatically needs to be divorced from writing code: the former
  offers large educational value to a broad range of students, while
  the latter offers very little.

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 it comes to real work, I'd happily learn the syntax, as it lets me be more productive.

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.

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.

How is Project Blocks different than the multiple (rather unsuccessful) failed attempts at graphical (even drag-and-drop) programming languages of the past?

its much faster to put together a functioning system than it was 10 years ago. For example in ROR, install devise and you already have a login system. I imagine things will keep getting incrementally easier / faster until one day we wont need a 'programmer' to do what we want.

google isn't unaware, I'll try not to put words in his mouth, but a google exec said something along the lines that we aren't very far from needing half of the programmers/ IT people we have today

> google isn't unaware, I'll try not to put words in his mouth, but a google exec said something along the lines that we aren't very far from needing half of the programmers/ IT people we have today

In one way, that's a scary idea (a lot of people will end up looking for work elsewhere). On the other, what programmer wants to do the stuff that can be automated away or done by a non-programmer? Or wants to reinvent the wheel because of NIH syndrome?

> what programmer wants to [...] reinvent the wheel because of NIH syndrome?

Almost all of them?

Hard to imagine, when I see all the stories about tiny modules in Node.js...but easy to imagine when I see how many JS frameworks are out there.

Still, so much of what we do these days is just tying together other people's libraries, connecting them together and maybe doing a bit of data conversion. My first step when I need to do something is to find out if someone else already wrote the software. Then I can just install+configure+move on to more interesting things.

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.

I agree with you. Programming languages are dramatically simpler than human languages. Anyone can learn the syntax and grammar for a programming language in a few months (at the very worst). Not only that, but they reduce the amount of expression possible so that you have to be very precise in your descriptions. While beginners find this difficult to deal with, it's actually a massive help because there are only a few ways to express something and the compiler/interpreter often tells you when you get it wrong. Again, compare that to a human language where you have a huge amount of expression available to you and it is often nearly impossible to realise if you are being precise enough to describe the problem/solution well. A good way to demonstrate this is simply to try to write a computer program in your native human language, without restricting yourself to pseudo code. It's pretty easy to leave out important details and to end up with a huge mess of incomprehensible garbage.

There are many people who think that a visual language or some other abstraction will simplify the problem of coding. I really don't think so. While things like diagrams are great for helping people comprehend something, they are absolutely terrible for expressing something. Just look at how difficult it is to draw really good diagrams. Consider the fact that we have had cook books for hundreds of years, but almost none of them are described solely with diagrams. Words are how humans prefer to communicate.

I think we often fall into the same trap with programming languages or frameworks. We say, "Look how easy it is to do this trivial thing. It's 100 times easier to do trivial things with this framework than without it". We are completely blind to the fact that the framework makes it 100 times harder to do ordinary things and 1000 times harder to do complex things.

I think the author was saying something different, with which I agree.

There's a POV from which code is the details needed to get something done, and the less, the better. In my life, the less visible the code task has become, the more power I've gained. A couple of examples:

When word processors stopped needing to be told stuff like /b at the beginning and end of words I wanted boldfaced, it got better. I found the whole WYSIWYG thing enormously helpful. The portion of time I devoted to typography was released for improving content.

LabView made it possible for me to assemble data acquisition and control systems with drag/drop icons and drawing connections instead of coding a PID module and then a gain module and then a Kalman filter function and ... you get the idea. Less code to write, more stuff done.

By analogy: Today, I turn a dial to make a fire to cook my dinner. I turn a valve to get water. I drive a car to go places. Yes, I've rubbed sticks together, I've winched a bucket up from a well, and I maintained a horse for mobility when I was a kid. I'm pleased and empowered by no longer needing those skills.

In the same way, I look forward to the disappearance of coding as a prerequisite to creation. I'm immensely grateful to the people whose coding is making that happen.

This is a strawman. Coding has never been a prerequisite to creation. People were creative forever, and then computers came along and created new avenues for creativity. The vast majority of which is done with applications, and applications have improved by leaps and bounds every decade.

Only a very tiny portion of creative work requires actual programming, like demo scene programmers. Even video games and Pixar movies have far more artists then programmers. It's true that more and more programmers are required to extend and maintain the software, but the growth of the end-user base has far outpaced the programmers. The majority of programmers are implementing business logic of which they have minimal high-level creative input.

The things we can do with computers without code has only increased. Pontificating on how it would be better if we didn't have to write code is like someone who once used a circular saw pondering why can't artisanal wood carving also be done with simple straight-forward, easy-to-use tools instead of difficult-to-use hand tools. I mean its crazy how often we hear this refrain about coding as opposed to other professions. No one asks why can't we have a gadget to perform an appendectomy at home instead of paying a surgeon thousands of dollars, but for some reason people think that coding is somehow unnecessary magic which could be done away with by a bit of clever rethinking. But code is not some rube goldberg device designed to obfuscate and impress; code is a medium, like a blank canvas, or a sheet of typing paper, the only difference is it can control physical things. It is not one concrete thing with a specific purpose which can be optimized like a word processor, or a stove, or a faucet or a car. Less code doesn't mean a simpler world, it just means less of what code can do.

I appreciate the thoughtful reply, thank you. But it's not a strawman. That's when you advance an argument that wasn't at issue.

I supported the article's thesis, that fewer people will be coding in the future, and provided a couple of anecdata points from my experience. I don't think code is unnecessary magic to be done away with. It's essential magic that becomes invisible when done well, to everyone's benefit.

And to clarify, creative work isn't limited to the arts. The creative impulse is common and has multiple outlets. Engineering is every bit as creative as portraiture or sculpture or crafting LOTR on a ginormous graphics processor farm.

My observation is that as the need for coding has decreased due in large part to increased computational sophistication, it's gotten easier for a wider range of people to do contributive work.

Suppose you have something to say about climate change. If you need to model it, you have several global models you can run, without having to code FEA and planetary atmospheric physics from scratch.

Or pick an artistic field - I know a hand weaver who uses commercial software to visualize her designs before she heads off to her hand loom. She'll never code a simple if/then/else statement, but the (invisible to her) code in the app lets her do things she'd never have time or resources to try otherwise.

Even in your medical example - I'll guess that fewer than 2% of the surgeons who use a Da Vinci medical robot could do anything useful with the code that runs that system. And if learning to code the robot were a prerequisite to using it, it would be a failed product.

I like your thought of a device for home appendectomy. Why not, really? Ultrasound imaging, vital signs sensing, actuators for retractors, scalpels...and lots of invisible code to make it work well. Just the thing for clinics in parts of the world where there is appendicitis but no doctors.

Code may not be designed to obfuscate, but it does that to many who would otherwise be able to use computation to do something new and useful. I think the more sophisticated code becomes, the less it will be a critical skill for most people. Which is good. We'll be free to figure out the next important thing and work on making it trivial.

Disagree that conclusion follows from quote. "Blocks" doesn't teach sufficiently deep thinking, and can only really solve problems within the domain of (foreseen by) the system itself.

Seems like a gross overestimation of time needed for said advances and complexity of such systems. There is already a research-grade approach to learn to generate short programming-challenge-like programs from natural language description: http://arxiv.org/abs/1510.07211

>This paper envisions an end-to-end program generation scenario using recurrent neural networks (RNNs): Users can express their intention in natural language; an RNN then automatically generates corresponding code in a characterby-by-character fashion. We demonstrate its feasibility through a case study and empirical analysis. To fully make such technique useful in practice, we also point out several cross-disciplinary challenges, including modeling user intention, providing datasets, improving model architectures, etc. Although much long-term research shall be addressed in this new field, we believe end-to-end program generation would become a reality in future decades, and we are looking forward to its practice.

Yeah, well I could be wrong, I'm not up to speed on the research, however the claims of general purpose AI have been "just around the corner" for half a century now so I'll take that bet.

Came here to say this. And text is still by far the most flexible modality, not physical blocks. Show me a templating or metaprogramming engine written in LEGO blocks and I'll show you a Grey Goo scenario.

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

Reply on news.ycombinator.com