programming interpreter

I have just finished the interpreter for my programming language. What should I do with it?

Use a specializer to make it a compiler.

Toss it away, start afresh.

>>2
No. That's retarded. There's a reason I made an interpreter in the first place.

>>4
Which is?

>>2
That's just stupid.
If you compiled a file with bad syntax, you'd get an executable that printed an error message.

>>5
I'm making a game, and I want it to be highly customizable.

>>7
Then use Lua.

>>1
I hope that the language includes the fabled dick-and-balls operator (.|.), as well as the boobs operator ((.)(.)).

>>9
You forgot the owl operator
((.),(.))

What about the butt operator? You need that for a butt loop.
(_|_)

>>11
Can I put a boner array in that butt loop?

It supports all of those plus larger arrays than python.

>>7
>highly customizable.
Why is it with these types that have only seen Python and some other languages whose main implementation is interpreted think that compiled is incompatible with customizable.

Had they understood how compilers work, they wouldn't be having that thought. In fact, in practice, best speed are achieved by either full compilation or JIT, with pure interpretation being the slowest. Optional interpretation at runtime is also possible for certain kinds of code. But straight-out dismissing compilation is very silly. That is not to say that if your design is as braindead as PHP's or newLISP's, in that you constantly eval dynamically constructed code(FEXPRs) because you can't make real macros, or the whole thing is based on dynamic scope, with no trace of real lexical scope (there's nothing wrong with dynamic scoping, as long as you're not forcing that kind of scope on by default and without giving the users options). Just look at languages like Common Lisp - almost all implementations are compiled, and it's a very dynamic language which allows you to change just about anything at runtime, but while you can do that and it does carry some speed penalties for the initial change (for example, you recompiled a set of functions in a system), the majority of code doesn't do that too often, if at all, so it benefits from compilation heavily. Other languages prefer JIT compilers, such as JVM/.NET-based ones, or Lua.

A full-fledged compiler or a JIT will almost always have better speeds, unless all you're doing is constantly compiling/recompiling the code, which in my experience is something you don't do to often at runtime, and if you really are doing that as much at runtime, you can optimize the compiler for speed or just switch to a runtime interpreter(quite a few Lisp implementations do have an interpreter for evaluating simple pieces of code which would cost more to compile).

Just admit that it's a lot more work to make a full-fledged compiler than it is to make an interpreter.

>>1
Let me guess, you started the toy language /prog/ challenge?


thought so

>>11
Don't forget the balls-pair operator
(_(_) (_)_)

>evaluating simple pieces of code which would cost more to compile
 what code you are interpreting faster than executing it in binary?

>>17
While the compiled code will always be faster, the cost of efficient compilation can sometimes be high. For example, you have something which generates simple pieces of code for you, and those pieces are rather simple, fast to interpret and would only be ran once. That's a case where an interpreter will perform better than a compiler, simply because compilation costs are too high. Normally compilation costs are a one-time thing which is done before even running the program, and even in cases of runtime compilation, it's still usually a one-time thing, but if it's not, and the code is simple enough, interpretation is faster. Languages which depend heavily on runtime generated code for everything (for example how newLISP doesn't have true macros, but has FEXPR's which just call eval) are usually faster as interpted only, and compilation is either too costly and doesn't give too much of a benefit since you're constantly generating new code. Such languages are usually considered badly designed, simply because the problem they're trying to solve has been shown to be solved without requiring runtime code generation much, if at all (Common Lisp and Scheme show this, but of course, CL supports runtime code generation, it's just not a mandatory component since it has macros which run at compile time, as opposed eval-time).

>>7
Hello, drwho

>>15
No, he didn't.
In fact I wrote that before I read through this thread.

>>16
Ugh. You guys and your stupid ternary operators.