HN Explorer

How hard for a modern programmer to learn a language from the future?

2 points by breatheoften ↗ HN
Suppose somehow, an advanced, popular, widely used language from the future is made available to modern day programmers.

How hard would it be for a modern programmer to learn to program in a language designed and used 100 years in the future?

9 comments

[ 3.3 ms ] story [ 27.1 ms ] thread
noemit
more in depth: its safe to assume that things will get more and more human-friendly, not the opposite.
drallison
Programming languages taxonomically fall into a few families which are similar in many respects. Between families there are also significant similarities. Almost no programming language is strikingly distinct and without a cohort of two. Future languages will, I believe, look a lot like current languages.

Future programming languages may appear very from different contemporary languages for much the same reason movies made in the 1940's and 1950's look their age. Movies depend upon conventions, styles, and assumptions to provide clues to plot, characters, situational understanding, and context. Today's programming languages have one set of assumptions; future programming languages have a different set of assumptions. Not everything about a computation is expressed in the programming language.

dragonwriter
> Programming languages taxonomically fall into a few families which are similar in many ways.

Truish, but...

> Future languages will, I guess, look a lot like current languages but with a few extra features.

The number of useful-to-distinguish language families isn't constant; the fact that languages are usually found in families doesn't mean that new language families aren't created over time.

brucephillips
When was the last time a new language family was created?
drallison
Prolog in 1970 or so. Erlang in 1986.
dragonwriter
While it has roots in the ML family (which, being from 1973, is one of the newer families itself), Haskell (1990) could be considered the branch point of a distinct new language family which also includes Curry, Agda, Idris, Elm, and others.
tiredwired
100 years in the future you will be able to describe an idea to an AI which will create whatever the idea is for you. "OK Google, make a Facebook without all the fake news." No programming languages.
cimmanom
The direction in which programming has developed over the past 70-some years is ever-increasing levels of abstraction.

40 years ago, good old C was considered a "high-level" programming language. Now it's about as "close to the metal" as 99% of software developers will ever have to get (outside of toy assemblers in school).

Now the highest levels of abstraction programmers work with on a daily basis are with scripting languages like Python that completely abstract away things like pointers and memory management, and that run on virtual machines and thus across completely unrelated operating systems or even CPU architectures. Many of these languages have rich ecosystems of packages that abstract away much of the tedious complexity of everything from making an HTTP request and parsing the response to reading and writing CSV files.

But even higher levels of abstraction are available to non-programmers - consider the marketing manager who strings together functionality from multiple richly functional SAAS programs to make a completely custom workflow in a point and click manner.

In another 100 years, the barrier to entry will be even lower; and more and more of the footguns will be hidden behind layers of abstraction; and complex functionality will be something that's pieced together from existing components.

There will of course still be room for defining custom logic. And someone will need to develop and maintain and update all those abstractions and the programming languages themselves.

But I imagine that to one of us, picking up the hot new programming language of 2118 would be a bit like how it would be for a 1965 Assembly programmer to pick up Python.

That assembly programmer would probably spend the first few days trying to figure out how to allocate memory or determine the contents of a register using Python and then realize how totally unnecessary that is and how much they can do in how little time if they stop worrying about being parsimonious with hardware resources.

We'd probably spend a few days wondering how to do something that seems unimaginable not to have to do - instantiate a class or catch exceptions or something. And then realize that those things are already taken care of and we can accomplish 100 times as much in a line of code as we used to be able to.