Hacker News new | ask | show | jobs
by betterunix 4636 days ago
It most certainly is true, if you can spend an unlimited amount of time coding. Python is too slow? You can isolate a subset of Python and write an interpreter that emits very efficient machine code for that subset, then write all your code with that subset. Sure it will take a long time, but so what? -- we started with the premise that the amount of time we spend writing our programs is irrelevant.
2 comments
frozenport 4636 days ago
Yes, you can call a binary C/C++ function from Python.

The important point is that C++ does it for me, automagically.

link
chetanahuja 4634 days ago
So you can write a really efficient program in Python if you change the definition of what Python does (that's what you're doing by rewriting the interpreter)? I think you're moving the goalposts here.
link
betterunix 4634 days ago
Why would you need to change what Python does (i.e. the semantics of the language)? All I said was that you would find a subset of Python that is useful for your project, then put together a Python compiler that is very good at optimizing that subset. This is not at all unprecedented: Microsoft does this with the C compiler used for Excel and ITA software did this with Lisp when they modified CMUCL's code generation routines (CMUCL and the SBCL fork are particularly interesting here, as they expose their code generation modules to the programmer, reducing the effort needed to hack your compiler).

The point is that these things require a substantial time commitment, which is what I said in the first place. If you have unlimited time to work on your project, you can use whatever language you want -- your time is unlimited -- and still meet all functional and performance requirements.

Of course, time is rarely unlimited. Usually you need to meet a deadline, and that means that you need to prioritize, and your priorities will guide your language choice. In my experience, functional requirements are typically higher-priority than performance (with a reasonable margin). Getting the right answer slowly is usually better than getting the wrong answer quickly; getting all features to work is usually more important than producing a fast system that implements only half the features.

link