Re: Dragonflame 0.3a is out!
Hi,
@SLJ, this is how it sounded to me as well. While I don't mind suggestions, even corrections, since this is an open source project once we release the code, questioning someone's knowledge just because you know something is not going to end well.
I still don't understand how @Ethin got the notion that I was unaware of the techniques, or knowledge about writing or using compilers. Maybe he had an introduction to assembly class, and thought he'd show us how much he learned?
At any rate, I am open to discussions, as always!
... I have to say, I was write on the byte code. It has to be ran through an interpreter instead of direct execution of the byte code.
Correct. I never said you were wrong concerning bytecode execution.
Look at Python, f
or instance. That can compile .py code into .pyc, .pyo etc files, but you have to have python installed on your computer to run that program. A newbie isn't going to want to do that, are they?
A programmer, no matter how much of a newbie he/she is, will have to do that eventually. There is no way avoiding it.
As for an end user, I am not sure why you think that they'd have to install an interpreter separately. It is the programmers task to release their program in a proper format. Python programs, such as NVDA, other tools such as BGT, mainstream games having a Lua interpreter, all do that. You don' thave to install anything extra to run them.
As I've said, interpreters are much slower than compiled programs because they not only directly execute the program, but they have to parse it line by line, which might be good for debugging and syntax error checking, but no one wants to insta ll Python, Ruby, Perl, etc in order to interpret their programs.
This is an interesting insight. It seems then that all the Php, Ruby, Python, Java, HSP, Inform, Euphoria, Smalltalk programmers, millions of people, are not included in your "noone" category.
Syntax checking and debugging happens even if you are using compilers that produce machine code.
Code interpretation can happen line by line, but nowadays there are far more efficient ways. This is why there are so many people developing lexers and parsers. Bytecode is most certainly not executed line by line. Thus, we cannot really categorise interpreted languages as just slow, line-by-line languages. To write a simple interpreter, line by line interpretation would work, but we are also talking about efficiency, which generates a whole new set of issues. But this is way beyond my post
As for interpreted languages being slow, yes, by nature they are slower than machine code. But quite often their speed is enough where speed is not important, such as scripting a game. Interpreted languages are getting more and more efficient, there are some quite amazing speed comparisons if you take the time to look for them.
Despite their slowness, they have a lot of advantages. Dynamic execution, duck typing, just to mention a few.
Please research this properly, because I really feel that a lot of things you have said are not based on neither experience, nor correct information.
By all means, I am not intending to instruct you. If you are interested, and seemingly you are, you have plenty of time to learn these things properly. One thing I am asking you however: next time, please do not draw conclusions hastily. As you see, they often result in confusion and thus not really contribute to our discussion.
Best of luck with DFE, once you have enough tim
e to "mess" with it. As always, we are here to help, even so, since we are in alpha stage for now!
Rob
URL: http://forum.audiogames.net/viewtopic.php?pid=160818#p160818
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com http://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
