Comment by Pacabel | Hacker News Reader

Comment by Pacabel | Hacker News Reader

Parent Full thread

The arguments in favor of considering an interpreted language as a suitable alternative are not very convincing.

Slower execution is indicative of waste. When it comes to interpreted languages, even those that are very well implemented, any slowness is directly related to energy loss. This is very problematic when it comes to mobile devices, even modern ones, as this energy is generally coming from a rather limited source (the device's battery).

While this may not be a problem if one or two apps are written using a wasteful interpreted language, it can become a much bigger issue when the entire ecosystem is implemented in such a manner. It'd be irresponsible to unnecessarily reduce the battery life of the devices of thousands or even millions of people.

And while many mobile devices today probably are more powerful than desktops from a decade ago, I don't think it's correct to say that those desktops "ran interpreted apps just fine". They didn't. There's a reason why Java has a bad reputation for performance problems, even today: many desktop apps written in Java performed horribly on computers of that era. And Java was perhaps the best-performing of the interpreted or quasi-interpreted languages.

I think his point is not that an interpreted language is the right thing. His point is that the assumption that it must be a compiled language is the wrong thing - that we need to re-examine way more of our assumptions than we usually examine when defining the "next" language.

Author here: you are correct.

You can go beyond even this assumption: is the Von Neumann model of programming even necessary? Of course, dataflow languages have been around for years, but there are other models out there that might work better; e.g. see Subtext [1].

I'm a professional PL designer also, though working under the pretext of a researcher. Those of us who are disgruntled are trying to start a support group :)

[1] http://www.subtext-lang.org/

Sean, I’ve read some of your research and it’s great! I agree completely. Hell, even the concept of “to create software means some set of sequential steps” is presuming quite a bit. Although I don’t have too much experience creating software otherwise, I at least acknowledge we really barely have any concept of what we’re doing and what’s possible.

Most of the time it's not the CPU that is using most of the energy. It's the mobile or wireless connection, the GPS and the screen.

I think that hardware factors like those are generally irrelevant when it comes to purely software issues, like we're discussing here. In this case, we're talking about an energy consumption penalty imposed solely at the software layer.

Aside from arguments about the screen perhaps not needing to be used as long when the software completes its operations faster, I think it's probably safe to say that such hardware-specific energy consumption due to the factors you mention would be constant in both the case of compiled applications and the case of interpreted applications.

>In this case, we're talking about an energy consumption penalty imposed solely at the software layer.

The point is that we may be wasting time talking about a negligible amount of the total battery assumption.

Good point. A better argument against the interpreted approach is that interpreted languages to a larger degree tend to be rather dynamic. With a platform like iOS where release cycles are fairly lengthy(not that this is really Warranted IMO) a static language is much more sensible. It's obviously a lot better to find as many bugs as possible before shipping and I would argue that this is much easier in stricter static languages. Frontend javascript for example is fine being dynamic and interpreted because it's easy to hotfix issues

I don't see a reason why a modern language, static or dynamic, could not have both a compiler and an interpreter. Most Lisps have both, Haskell has both. Also, most interpreted languages actually have a compile phase before the actual interpreter.

I do agree with you on that any platform should have a staticly typed language as a first class citizen.

What would be the use case for the interpreted version? I would assume it would be usable for the development process, surely running interpreted code on devices would be a total waste if compiled code is available?

During development is probably the best use case I can think of. With editor integration an interpreter is a tremendous help when coding. At least Lisps, Ruby, Python and Haskell have this kind of "development environments' to a some degree. I think GHCI even doubles as a debugger.

The reason the CPU is not using most of the energy is because it's not used all the time. And that's by design. Every single thing possible under the sun is done to keep the CPU off for even a split ms on mobile.

Because if you start using the CPU all the time, your battery is done.

Reply on news.ycombinator.com