Hacker News Reader

Comment by RyanCavanaugh | Hacker News Reader

As systems evolve into higher levels of abstraction, things that we used to consider to be "code" become "data" instead.

For example, in 1950, you would write a lot of code to accomplish what you can do today with a pivot table in Excel (which we don't consider to be "coding"). Page layout you'd write as code in 1996 is now "data" encoded in CSS.

At the same time, things that used to be major code concerns have been abstracted into the underlying systems. Garbage collection, privilege separation, caching, and so on continue to move lower in the stack. The trend toward programming languages that more natively support asynchronicity is another great example.

The better question to ask is: What tasks that we accomplish with code today will be accomplished with data tomorrow?

View on HN

There's a cautionary aspect to this in that simply adding parameters and making configuration data(e.g. much of the Java XML ecosystem) is not enough to squash out "coding". It takes some carefully thought abstraction to make a difference. In some places we've made progress, in others we've churned through tech without going forward.

It moving from imperative to declarative programming essentially.

At the same time, we'll (hopefully) keep pushing the boundaries of code further. Developing CSS and spreadsheet tools just made the code that we do have to write line-by-line more interesting and powerful. We'll never stop writing code, because there will always be people pushing the boundaries of abstraction, but one day, we might look back on today's programs as a mere step above machine code.

insightful. this question has been asked (at least) since i've been a professional programmer, which is 20+ years.

start of my career, >80% of my code was directed to memory management--allocating it, re-pointing it it, and de-referencing it under what seem now like impossibly tight optimization boundaries. I still work in compiled languages, but that fraction is now about 5%. Compiler & os optimization, hardware, etc. are the obvious reasons. Plenty of other challenges--some new some old, some completely contrived quickly occupied that attention vacuum.

> What tasks that we accomplish with code today will be accomplished with data tomorrow?

"Eventually" all of it? (mind the quotes)

If you save the config of a neural network, the "meat" of the NN so to speak, it's all "data" (matrices), but OTOH it's "code" (it tells the NN what to do).

How about things like video games? Frameworks/libraries/engines will certainly abstract away more and more of the nitty-gritty details, but the framework can't write the gameplay parts for you: those are essentially creative decisions.

I'd argue that writing anything like (State, Action) -> NewState transitions is, in fact, coding, even if it's done in a way that's much more declarative than we're used to.

Here we end up in almost a semantic argument. Is using graphical tools like Unreal's Behavior Trees and Blueprint 'coding' or gameplay 'design'.

Yes :-)

I think it's definitely "programming", though I'm willing to agree that "coding" seems to imply more typing text in some 80-column format and less clicking. People certainly call doing-stuff-with-LabView "LabView Programming" and it involves a similar interface.

Two other thoughts a) Do you think tools like this will ever actually replace all coding? My experience with graphical programming has been that it's great for simple things, but you often reach a point where it'd be way easier to write it as code, particularly if you're doing something the designers haven't anticipated.

b) I was actually interested in the contrast between ANNs, where the functional part is learnt from data--in part because we have no idea how to actually write a decent object recognizer from scratch--and something like a video game where you're necessarily designing/programming/coding up a creative idea that you have.

>> What tasks that we accomplish with code today will be accomplished with data tomorrow?

Ahem. There is no separation between data and operation. It's what you learn if you play around with Lisp or Prolog, or any kind of language that doesn't start with "here's some variables, here's some functions that operate on them".

Thanks for this insight! I love this idea of code growing up to become data.

Reply on news.ycombinator.com