4 ms·

This is not serious, surely. It's a simple Python wrapper for gcc. And by simple, I mean, really simple. Meaning the GPL is the biggest file in the source tree

by wbhart 16y ago

This is not serious, surely. It's a simple Python wrapper for gcc. And by simple, I mean, really simple. Meaning the GPL is the biggest file in the source tree. And it doesn't work: igcc 0.1 Released under GNU GPL version 2 or later, with NO WARRANTY. Type ".h" for help. g++> int i = 0; g++> printf("%d\n", s); [Compile error - type .e to see it.] g++> printf("%d\n", i); [Compile error - type .e to see it.] g++> Yes, it does exactly what you think it does. It runs GCC on all the code you've entered. I've been to the future, and language development does not progress in this direction. Future languages certainly do not have all the elegance of C++ and all the speed of Python. Instead, why not write a C REPL on the front end of the LLVM Jit!? No one seems to have even thought of writing a Scheme REPL for the LLVM Jit. And that would be completely doable. Write it in C, use Boehm's garbage collector and the LLVM Jit.

buzzert 16y ago
This is exactly what I thought when I started running commands. The "interpreter" is so incredibly slow. Then I looked at the source code and just face-palmed. Python?? Really?
- devinj 16y ago
  It's slow because C++ compilers are slow. Python isn't so slow as to be the bottleneck here.
  - wbhart 16y ago
    That's right. In fact, if Python were used to incrementally compile to assembly, it actually mightn't be too bad. There'd be a relatively short delay every time you pressed the enter key as the new bit got compiled. The problem with the approach taken is that it compiles everything you ever typed every time you type something. I honestly can't think of a worse combination. C++ is the language, you need a Python interpreter to run it. And there's no incremental compilation, so it just gets slower and slower the more you do. People who write stuff in Python need to realise that sometimes you can't solve a problem just by wrapping something in Python. Occasionally you need to do some actual work. I'm afraid I see this all too often.

by wbhart 16y ago

buzzert 16y ago

This is exactly what I thought when I started running commands. The "interpreter" is so incredibly slow. Then I looked at the source code and just face-palmed. Python?? Really?

devinj 16y ago
It's slow because C++ compilers are slow. Python isn't so slow as to be the bottleneck here.
- wbhart 16y ago
  That's right. In fact, if Python were used to incrementally compile to assembly, it actually mightn't be too bad. There'd be a relatively short delay every time you pressed the enter key as the new bit got compiled. The problem with the approach taken is that it compiles everything you ever typed every time you type something. I honestly can't think of a worse combination. C++ is the language, you need a Python interpreter to run it. And there's no incremental compilation, so it just gets slower and slower the more you do. People who write stuff in Python need to realise that sometimes you can't solve a problem just by wrapping something in Python. Occasionally you need to do some actual work. I'm afraid I see this all too often.