Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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").


what is a + b with two arbitrary large numbers in plain C? It can't even add correctly and implements something else than a plain addition. How can it be 'optimal'?

The effect of type declaration on numeric operations is pretty much the same for all Common Lisp compilers that support that. The type declarations themselves are standardized. What is often different is the amount of type inference a compiler does.

    * (defun twice (a) (declare (fixnum a)) (the fixnum (+ a a)))

    TWICE
    * (disassemble 'twice)

    ; disassembly for TWICE
    ; 02AB2CBF:       488D0C12         LEA RCX, [RDX+RDX] 
    ;       C3:       488BD1           MOV RDX, RCX
    ;       C6:       488BE5           MOV RSP, RBP
    ;       C9:       F8               CLC
    ;       CA:       5D               POP RBP
    ;       CB:       C3               RET
You think this will be five times slower than C?

Actually I would prefer C code to be slower and more safe by default. For that I would trade speed in a lot of places.


Fine. Back to the original discussion, I will be left guessing why languages like Lisp and Pascal were left out, even though they may be as efficient as C. Let's say, for example, because of the lack of iPhone-specific infrastructure (APIs etc). Supporting 5 rather than 3 languages would be too much, I guess, considering the 2 are not terribly popular.


Apple is not supporting them anyway. These platforms mostly support themselves.

Guess what, Lisp and others have C FFIs and Objective C bridges and can call Apple's library.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: