If i want to create small and simple programming language(object oriented language with general purpose) what would be better choice for implementing it - assembler or using other high-level language?I mean,for example as far as i know Ruby use the C language,maybe i'm wrong i don't know but on the official Ruby website there is the source code that Ruby uses(functions,variable declaration and so on) and it's written in C.Is there some good reason for implementing my language with assembler language?Using assembler would be very complex task and ofcourse would be much harder/slower to implement my language with assembler than implement it with an existing high-level language,but with assembler you have full control on everything.So can anyone give me some advice?

Base level languages like C and C++ will also be much faster when running than a higher leel language will be. In that way it is beneficial to create a language off the most base level language you can, it will have fewer levels to go through when running.

I haven't came up with any languages myself so I am not the best one to be talking, but there is my 2 cents on the topic.

Hmm.. that seems pretty hard... but IMO.. you should create something very similar to C++... I think every OOP language was built basing it from C++..

Similar from C++ and as easy as JAVA.. with lots of easy to use libraries.. that way its not hard learning.. and basic principle could easily be applied..

Taken from the Object Oriented Programming wiki

hmm.. nice Info.. I thought C++ was the founder of OOP.. lmao.. well thats an opinion from a n00b like me..

First of, you need to know if you want to create a language that compiles to a target plattform (native, JVM, CLR, parrot) or you roll out your own interpreter.

If you compile it to a target plattform, the language you implement the compiler doesn't really matter (well, if speed doesn't matter), since you only generate code, but not execute. On the other hand, if you implement your own interpreter, I'd choose C, a fast and nice language.

Yeah,i want to implement my own interpreter/compiler,not to compile to a target platform.Maybe i'll choose the C language.I can't find better low level language which runs on Windows.Ofcourse the perfect choice for implementing high-level language would be assembler but that would be enormously hard task.

Writing a new OO Programming Language is a huge undertaking. I'm not trying to scare you away but you should know what you're getting into.

First it would be easier if you chose C than assembler. Asm will make your hands bleed by the time you finish a half decent compiler/interpreter with it. You can also try other higher level languages like PLT Scheme.

To create a general purpose programming language, you'll have to be top notch in your language theory. The language is general purpose if its Turing complete. Its easy to make a language Turing complete (even Brainf*ck is) but what'll be the biggest challenge is to create OO semantics inside it. Most OO concepts require quite a lot of thinking before they can be implemented - like multiple inheritance/mixins. Again, good theoritical background will help immensely.

Well, most software is not implemented entirely in an Assembly language, if it's using any at all. If you choose C/C++, you can optimize the parts that need to be optimized with inline assembly, or with an external assembler. Using C/C++ makes the software have some degree of portability.

If you write a compiler that generates native code, the language the compiler is written in isn't a major concern. Granted, you probably would want to write it in a language compiled to native code, but since you only have to compile once before executing, the speed of the compiler is mostly a non-issue (unless the performance is horrible).

If you're compiling to byte-code, a JIT-enabled VM will probably be the best choice in terms of performance, except for small programs, where the overhead of the JIT compilation process outweighs the time it takes to interpret and execute the bytecode directly. Some JIT-enabled hosts will selectively JIT compile bytecode (such as the Sun Java Hotspot VM) based on how much a certain piece of code is being executed.

JIT-compiling byte-code is probably a rather complicated task, especially if it's selective.

If it's purely interpreted byte-code, then making portions in Assembly language may yield some benefit. Of course, writing highly optimized assembly is not easy, and the fastest way of doing something is often not the most obvious. A C compiler will have this kind of "knowledge" built in, where someone doing it manually will have to do research to figure out how quickly certain instructions execute.

If you want to make something that will work on multiple platforms without using a bytecode interpreter, you might want to study the design of the GNU Compiler Collection (GCC). It's design abstracts the machine details away from the parser and internal code generator. There is are Java, ADA, Fortran, Objective C, C, and C++ front ends that use the same core internal code generator, and it can produce native code for many platforms. Studying it would be a major undertaking though, as it's codebase is rather large.

This post has been edited by perfectly.insane: 13 Jun, 2008 - 03:56 PM

If you are interested in learning about language design then I suggest first writing your own procedural interpreter -- something simple like a BASIC interpreter.

This is really not all that terribly hard. You can use parser tools to Flex/Bison/Yacc/Gold Parser etc. To generate your language and parse it.

How complicated things get depends upon how complicated you want your language to be. I have written several little "scripting" languages for some of my programs and it really is not difficult (I usually implement a version of BASIC since that is where I began programming).

Once you have had some experiance with that then you may want to look into compiling your programs into a "Byte-Code" which in this case is nothing more than a binary representation of the tokens generated when parsing.

At this point you will have a pretty good understanding of languages and how they work and will be far more equipped to work on an object oriented language with a VM. (which is actually two or three programs -- a compiler to byte-code, a VM to execute the byte-code and, if you are fancy, a JIT).