Comment by agentultra | Hacker News Reader

Comment by agentultra | Hacker News Reader

Parent Full thread

Different platform, different requirements.

If a language run-time or virtual machine promises, "you can write code once and run it anywhere," then they're not telling you the whole story. There's no such thing as, "cross platform." It's just a vague term that is commonly interpreted as, "major OS platforms," or, "most popular mobile platforms," etc.

Requirements are both technical and non-technical. If we just focus on the technical requirements you have to look at the data you're working with, your user, and how the program interacts in this system between the human and the rest of the world. If you're writing safety-critical mobile applications for remote workers that spend a week or more in the field you're probably not going to waste your resources on a memory-hungry VM just so that life is more convenient for you. That's starkly different to prototyping an application in a lab where convenience is paramount compared to cheap resources. I have yet to see any kind of language or run-time that lets you have it both ways.

One may say, "Yes agentultra, but what about generating the code for the highly-constrained environment from the higher-level language?" I love this approach. It's possible to generate efficient code this way. This approach still requires you to understand your target platform well enough to spot bugs in the generated code. So while it may be an approach to gain some leverage as a single developer or small team; you're still quite constrained but this DSL... the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.

I haven't yet found a way to "escape" the reality that different combinations of hardware and OSs require different solutions for different applications. It may seem like "all you need is Java" or X, Y, or Z -- but the reality is more nuanced than that.

> I have yet to see any kind of language or run-time that lets you have it both ways.

If there were such a language I wouldn't be asking this question on HN. I have yet to see a clear answer why there is no such kind of language or run-time.

> the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.

Why? Can be you more specific with an example?

> I have yet to see a clear answer why there is no such kind of language or run-time.

... I'm having trouble not being glib in my response. I want to say, because computers. But let's be a little hand-wavey for a moment.

As programmers we sometimes put too much faith in our poorly-thought-out abstractions. We think, "why is there not a library/runtime/VM that abstracts away all of these painful, tedious details? Surely someone must've invented a GUI library that runs on all platforms, perfectly." We look for ways to avoid the difficulty of thinking too hard about it. We just want to write an application and not think about operating systems, hardware architectures, memory allocation, etc, etc.

Well there are systems that do remove some of the effort in writing such applications. They will manage memory for you, abstract away the differences in various operating systems, and they might even provide a common library for writing a GUI that works across all of the platforms that the VM/runtime supports... this is a great tool to have.

However it has a cost. It has it's own memory model. It makes assumptions about what GUI interfaces are. It targets the common denominator between operating systems. It is, by necessity, quite complex on the inside... so as long as you can sit comfortably in the box and write programs that the system expects you to write you can safely ignore the hairy details of allocating memory, making system calls, managing resources, etc.

But if your application requirements pull you out of that comfort zone be prepared to have to deal with garbage collection algorithms and mapping your application's data to the runtime's model. That has a cost.

For some applications that cost isn't worth it or even feasible. How much battery power are you willing to consume? How many updates to the simulation can you make per second? How fast do you have to stream that data of the disk to this other component?

These languages and runtimes that claim to be "cross platform" are really just selling you a subset of functionality on a subset of platforms that you may or may not care about. It's never what you intuitively assume it to mean, "write once, run everywhere."

> Why? Can be you more specific with an example?

I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to write applications for that processor in a high-level language with all of the Common Lisp tools I was used to. However that DSL was restricted to that platform backend.

Had I a requirement to target another platform, say x86_64, I would have to write another backend for my high-level DSL and introduce plumbing to my build tools to produce the executable code for either platform. Great! Cross platform code!

Well... not really. I still had to write two different backends. And I can't really exploit the unique features of either. I can only really make use of the common denominator between both or else emulate features of one in the other at the expense of making one platform less performant/useful than another.

There's no such thing as "cross platform." It's just a marketing buzz-word. There are hardware platforms. There are operating systems. These are the things we program.

Abstractions are great but they're not free and they don't free you from thinking. It's an easy mistake to make because it comes so naturally to us humans -- we hate doing things that are difficult. But there's nothing natural about programming. It's hard.

Reply on news.ycombinator.com