3 ms·

Speaking of compatibility layers, there is one very direct consequence of being inefficient on a mobile platform: battery life. I've become somewhat sensitive t

• lispm 17y ago
  That's also 'Unfug'. Flash is just bad - especially if it does not use any hardware acceleration offered by the machine for video decoding. Battery life is not much affected by a dynamic language. Because no one with a clear mind will implement things like decoding of video in a dynamic language. But what people want is to implement GAME LOGIC in another language and not in C. The real battery life that matters is based on costly processes (like flash) and using costly services. Navigation is such a thing. There are many many applications for Navigation. ALL of them are a huge source of emptying your battery. I have used a single navigation application presenting a map and recording my track - battery life goes down to two hours. The reason is the screen, the internet connection for the map and the GPS receiver - all demanding power. But people want to use those things. So in a car the iPhone gets electricity from the car. On a bike there are electricity adapters also. There is NO reason to assume that a software written in a high-level language and translated to C will empty battery five times faster. YOU CAN WRITE BATTERY EMPTYING SOFTWARE IN ANY LANGUAGE - AND SOME OF THESE APPLICATIONS ARE VERY USEFUL - LIKE NAVIGATION APPLICATIONS. Take for example a program for the iPad that plots complicated mathematical formulas. Apple forbids translating the formulas to machine code on the iPad - because that would implement another programming language and runtime on the iPad. So Apple's restriction SLOWS things down. At the same time besides computing the formula the plotting application does mostly calling UI function (drawing, 3d stuff, etc.) and waits for user interaction (zooming, rotating, ...). You can write that part in any language - it is mostly calling platform functionality. So in this domain it either don't matter (because the UI code is mostly calling to the platform) or is getting worse because of Apple's policies (because you can't compile complicated formulas on the device, because that would violate Apple's developer restrictions).
  • mojuba 17y ago
    There is NO reason to assume that a software written in a high-level language and translated to C will empty battery five times faster. Do you know how (a + b) works in different languages? Have you ever looked into Python, Ruby, Java, C/C++ (and (+ a b) in Lisp if you wish)? The difference is huge. In dynamic duck-typed languages (a + b) means checking the types of the operands before you can decide what + means and before you actually do something, for example add integers, or maybe float's, or maybe concatenate strings, or maybe throw an exception if anything's wrong with the operands. Let alone variables take up more space - and that's another source of power consumption - because they can be of any type. From my observation, dynamic languages are 3 to 10 times less efficient. And I wouldn't bet on developers' "clear mind" like you said. Edit: and I'll let you go with "bullshit" (which you edited later) and a lot of irrelevant, emotional demagogy.
    • lispm 17y ago
      Most code in these languages is not computational intensive. That's not what they are for. Much of that code is calling platform functionality and library functions. Try to check some Perl on text processing vs. hand written C code. There is not much difference, because the Perl core routines are written in C anyway and optimized for that task. If you look at Python, it's again the same pattern. The core logic of some application is implemented in Python and the computational expensive parts are written in C (or even assembler) and called from Python. That's why these languages are often GLUE or SCRIPTING languages. (+ a b) can be optimized in Lisp. You might not know it, but Lisp has type declarations and several compilers are making good use of it. This widens the range of software that can be written in Lisp. Typically this allows the core logic to be written in plain Lisp and more challenging parts in Lisp with type inference and type declarations - the yet more challenging parts can be written in C or assembler - some Lisps have inline assemblers or inline C - all have extensive interfaces to call routines written to C calling conventions.
      • mojuba 17y ago
        I know applications may rely on API calls and may not be computational intensive. This is exactly why Python is not 100-200 slower than C, but only 3-10 times. (+ a b) can be optimized in Lisp (a + b) in C is always as optimal as it can be on a given platform. You don't put special effort to make it optimal ("oh, maybe I should declare a and b as typed... let's ask this on the forums if my compiler supports it and in what way").