Re: The future of Perl?

[wjw]

A while back I ran into a video (maybe a TED talk?) regarding The Machine. I have to wonder what impact a fundamental shift in hardware would have on any language(s). It has been a while and I have not gone back and re-examined this, but assuming a fundamental advance in hardware, is there much of a future for anything we know?

It depends on "how much future" one includes in their definition of future of course. My point is that it may not be the nature of a given language itself that determines it's demise, but instead it could be that computer languages as a whole might simply become irrelevant because the listener might evolve beyond the core concept of what we call a language.

So, enough SciFi for the moment I guess.... having a Asimov/Hienlein moment... ...It happens....

[BrowserUk]

I have to wonder what impact a fundamental shift in hardware would have on any language(s). It has been a while and I have not gone back and re-examined this, but assuming a fundamental advance in hardware, is there much of a future for anything we know?

Hardware advances tend to be transparent to languages, the OS hides them behind established device/file paradigms.

Memristors are just memory. The fact that it's persistent will be managed by the OS rather then languages.

Silicon photonics speed up memory and device access, but is otherwise transparent to languages.

Even where hardware advances can be usefully utilised at the language level -- virtual memory; threading -- it tends to be years if not decades before support filters into languages.

Hardware supported virtual memory has been around forever; but at the language level we still pretend that we have a single, linear memory space where the stack and heap occupy the same space despite the fact that in reality they occupy different chunks of physical ram.

Threading is ubiquitous in hardware now, and available to many languages; but no-one has yet really found the sweet spot for how to encapsulate them; hence we have either raw low-level; or some, mostly inappropriate, metaphor for them.

Basically, I don't think hardware really affects languages. There will always be a C/C++ compiler; and most other compilers and interpreters are built on top of that.

Maybe someone will come up with a radically different architecture; but I see no signs of it yet.

[Loops]

Your comments about hardware, and virtual memory in particular, reminded me of this good talk by Gary Bernhardt:

The Birth & Death of JavaScript

If you haven't seen it and have a few minutes to spare, it's enjoyable and maybe even a little thought provoking about whether hardware virtual memory is a good use of resources going forward.

And as for a radically different architecture, the Mill CPU has a great series of talks on video devoted to its development. It doesn't challenge your point about languages transparently supporting underlying system variations. But it will provide a very different target for compilers and JIT's which may favor some languages over others.

[BrowserUk]

That was an interesting watch. Amusing in a scary kind of way.

The Mill Machine sounds interesting; but if it ever comes to market, it will still remain transparent to the applications programmer.

[wjw]

Thanks for that BrowserUK. Those points are informative to me, and seem to be on the money.

Clearly the example I used is a poor one for having tried to make the point I was attempting to make. (My lack of depth of knowledge in the arena). Perhaps our understanding of language is driving our innovation in hardware instead of the reverse. I wonder what might happen if the reverse was approached more aggressively. Maybe that is what is happening at a certain level in the fields of bio-mimicry and maybe even in quantum computing.

At any rate, I think you are right; hardware does not affect languages at this point in time, but I don't doubt that it will in the future. I find it hard to believe that all machine languages by nature have to operate at the basic level in one of two states. I think the success thus far has limited the innovation.

I have gone way off track relative to the original post and suspect I better stop. Thanks for the interesting meditation.

[BrowserUk]

I think you are right; hardware does not affect languages at this point in time, but I don't doubt that it will in the future.

Hm. All the signs are that more and more, languages will present higher and higher level abstractions of the programming model and the hardware will adapt to the software view.

For example, storage system manufacturers are beginning to move away from the bytes, blocks and files view of the disks and SSDs they manage, and moving to an Object-oriented view, which does away with the need to convert binary memory objects to some intermediate format (eg.JSON) so they can be written out as files via the file system.

CPUs currently have 3 or 4 levels of caching; much of which is split into separate instruction and data caches. I wouldn't mind betting that it won't be long before we have another type of on-chip caching; namely, a dedicated stack cache. Due to their nature and use, stacks have really good locality of reference, which makes breaking them up into typically short (16byte) cache lines and mixing them up with the random access of heap storage, is sub optimal. Better to have stacks cached in 2k or 4k chunks and keep them in memory between task switches where possible. Segregating stack caches would allow relatively small amount of dedicated on-cpu real estate to keep the stacks of many/most threads alive between context switches, whilst preventing the stack memory from 'polluting' the general data caches.

Further, hypervisers are well on their way to virtualising everything: disks, memory, networks, ports, cpus, gpus et.al. Essentially, the 'computer' where your programs run is nothing more than a figment of the hypervisors imagination. The programmers view may be of a single 32-bit cpu with 2GB of ram and a local harddrive; with the reality being that it is a VM that may be running on 1 of 32 cores on a 64-bit 4-cpu blade in a farm of machines with 128GB memory and the drive provisioned from a multi-tiered remote drive array.

And the actual hardware might be x64, or ARM or Solaris or Power 8; and neither the program nor the programmer need be aware which.