/prog/ question in /b/

What the fuck?  He hasn't been SICP'd or ENTERPRISE TURKEY BULLSHITE'd yet.

http://img.4chan.org/b/res/86845375.html

>>1
And the reason you have posted about it here would be? Don't answer.

>>1
back to /b/, please

404

>>1
you do realize the futility of posting a link to a thread on /b/ is, right?
asshole.

>>5
Well, the thread is gone.
Let's talk about Java!

>>6
no, because Java is slow as fuck

>>7
i think you meant RoR.

Ruby is actually improving in speed these days.  Python is still slow as ever.

>>9
Lisp is still faster than both.

>>10
If by LISP you mean PYTHON, then yes, it is.

If by PYTHON you mean PERL, then yes, it is.

If by PERL you mean C, then yes, it is.

>>9
Well, of course a great language that compiles to machine code is going to be faster than any mediocre language that compiles to bytecode.

Python really needs a native compiler. The faggots on the Python forums seem to think compiling to bytecode and then packaging that with a light-weight bytecode interpreter into one .exe is the same thing.

>>15
I'd think that having a JIT runtime, with the option to bundle your bytecode with it is a much better solution.  So fuck you, nigger!

>>15
Python has some language problems (especially with some dynamic scoping issues) that need to be resolved before a native compiler is possible. Right now, a bytecode interpreter is necessary until starkiller's hypothesis (that any arbitrary Python code can be statically type-checked) can be proven one way or another.

IIRC, the PyPy project could compile RPython to native code (which is how they're bootstrapping the interpreter), and one of the goals of the PyPy project (albiet a far-reaching goal) is to eventually provide either JIT or static compilation of Python code.

But on the JIT side, there's already Psyco which does a pretty damn good job.

>>17
If it can be interpreted it can be natively compiled. In the worst case some edge cases are exactly as slow after compilation as they are when interpreted.

>>17
Funny how Lisp doesn't have this problem.

>>19
Yeah, LISP has two problems.

>>18
Yes. And the compiled form would be essentially the same as just embedding a lightweight interpreter because of all the dynamic shit that has to be done in the background. Psyco does JIT compilation of the bytecode in a much more reasonable manner and falls back to interpreter speed on edge cases, without making the entire thing an unreasonable mess.

Why continue beating a dead horse? Python already has over 9000 backends: it doesn't need another one.

>>21
Yes. And the compiled form would be essentially the same as just embedding a lightweight interpreter because of all the dynamic shit that has to be done in the background.
This sort of ignorance of compiler design and dynamic languages is what got us into this mess in the first place.

>>22
Which is why I don't fuck with dynamic languages. Excuse me while I hug my C compiler.

>>18
Not if the interpreter performs dynamic optimization

>>22
Would you be so kind as to explain why the statement you quoted displays ignorance of compiler design and dynamic languages? I want to learn.

>>25
To put it in layman terms: Native compiler compiles it for the CPU it will be running on. A bytecode interpreter will be like inventing your own CPU architecture and then using a program written for the CPU it will run on as an emulator between the two.

Now, excuse me while I go back to my ASM.

>>26
More like go back to 6th grade, you ignorant faggot.

>>26
back to /pr/, please

>>21
And the compiled form would be essentially the same as just embedding a lightweight interpreter because of all the dynamic shit that has to be done in the background.
Agreed (disregard >>22), but that "dynamic shit" is the reason why I'm using Python. I don't mind spending an extra second of CPU time if I can save a week of human time and have so much fun writing the program, plagued with "ABSTRACT BULLSHITE" that will allow me to make less mistakes and have a so much nicer, shorter time maintaining and expanding it as well.

>>29
You can still have some dynamic shit and statically compile stuff -- Sepples is a shit example of this with shitty RTTI. Haskell is probably a better example -- dynamic typing via inference can be compiled statically.

The Starkiller project^1,2 which I've mentioned a couple of times was a static type inferencer for Python. It works in almost every sane place, except when you're doing weird shit like dynamically importing modules and calling eval. I think there were also some issues resolving the dynamic scope (which is an issue, considering dynamic name resolution is a serious bottleneck in Python interpreters) but I can't find any references.

And, as I've fucking mentioned before, Psyco³ is a fucking crazy JIT for Python which caches the exact instructions executed by the interpreter when functions are called, then replaces the functions with those cached instructions such that future calls don't touch the interpreter at all. It does some hackish shit to work around the dynamic bits, but the end result is that code which the interpreter would bottleneck (tight loops and numeric shit) gets an incredible speedup.

AFAIK, Psyco only works on x86 machines and doesn't play nicely with embedded Python though (it definitely doesn't work for mod_python, which is where I wanted to use it).

As far as performance is concerned, last I checked PyPy hadn't really produced any results⁴ (though it hopefully will, eventually). It's got some damn cool sandboxing features⁵ though.

Anyway, did any of you faggots have something to discuss other than "BAWWWWW PYTHON ISN'T C AND DOESN'T PRODUCE NATIVE BINARIES YET"?

                               
[sup]References:
[1] http://web.mit.edu/msalib/www/urop/
[2] http://www.sauria.com/~twl/conferences/pycon2004/20040324/Starkiller.txt
[3] http://psyco.sourceforge.net/
[4] http://tuatara.cs.uni-duesseldorf.de/benchmark.html
[5] http://codespeak.net/pypy/dist/pypy/doc/sandbox.html

>>27,28

stfu

>>30
Anyway, did any of you faggots have something to discuss other than "BAWWWWW PYTHON ISN'T C AND DOESN'T PRODUCE NATIVE BINARIES YET"?
Too bad Python is slow as fuck.

>>32
Yeah, I know ;_;

That's why I write all my code in Java.

>>33
Loading the Java VM actually takes a second or two. For most applications (not bound by user IO), that means it's slower than Python.

>>34
REAL BENCHMARKS OF NON-TRIVIAL ENTERPRISE APPLICATIONS DON'T TAKE STARTUP TIME INTO ACCOUNT BECAUSE OUR ENTERPRISE APPLICATIONS ARE DESIGNED TO RUN FOR MONTHS AT A TIME WITHOUT NEEDING MAINTENANCE UNLIKE YOUR TOY PYTHON/LISP/HASKELL/RUBY PROJECTS.

inb4Erlang

>>35
Haskell is as fast as Java on single core processors, and outperforms it on multicore processors, probably because it's lazy.

>>31
lrn2dynamicOOLanguageOverheads

>>37
I, for one, welcome our new dynamicOOLanguage overlords.