Showing posts with label ruby. Show all posts
Showing posts with label ruby. Show all posts

Thursday, November 01, 2007

My Own Scripting Language for .NET Framework

I've wrote about dynamic languages and that they are good at combining already written components into full application. As I'm programming at C# now which isn't very laconic and simple language I have an idea of scripting language for .NET Framework. There are a lot of languages ported on it, among them: Python, Ruby, etc. But I still has an idea of implementing my own interpreter. It will be very useful in implementation of DSLs for my own applications. At least if I wouldn't be .NET programmer I'll get a lot of experience in developing interpreters. It's not a simple task but very interesting and useful.

Currently I'm working on library of common classes for .NET. I wasn't pleased with standard implementation because I didn't find a way for customization, e.g. changing path of saving configuration file.

Also there is a LogFile class, which implements DebugListener abstract class. I attach it to Debug to write down messages about errors.

P.S. I've passed all laboratory works in programming and think now I'll have more time for non-study programming.

Monday, October 29, 2007

Dynamic and static languages

As I've mentioned I'm reading a "Design Patterns" by Erich Gamma. Yesterday I've finished reading about structural patterns. I have to say that this book contributed a lot to my understanding of object-oriented programming, not only in a way of giving information about patterns, but also about whole programming. While reading I've often found examples of difference between dynamic programming languages and static ones.

In most cases dynamic languages looked better that static. Some methods hard to implement in static languages are easy to implement or built in dynamic languages: creating prototypes, changing behavior of object on-the-fly, programming by interface not implementation. It's not a secret dynamic languages such as Perl, Python, Ruby, etc. usually require less amount of code lines than static like C++. This mainly provided by different approaches to code handling: static languages are usually compiled, while dynamic are interpreted.

Dynamic nature of languages like Python provide rather wide abilities to work with classes and objects but in most cases programmers doesn't need available but rather low-level features (does we need very often put definition of function in if-statement?). And the cost is slow execution speed. Moreover if there is an error in program developer will know about it only when interpreter will reach this piece of code, while some of such errors could be caught during compilation.

As I think, is that in most cases interpreted languages are enough good for very big range of application what is proved by current trends in programming. But compiling languages still are rather popular. They are much better in implementing complex algorithms which uses a lot of resources. I agree with J. Ousterhout in article "Scripting", that static languages are useful for complex data structures from basic data types, which are often accompanied by low-level difficult to understand algorithms; and with dynamic (scripting) languages we can combine this elements to systems. Present dynamic languages (at least as I know Python and Ruby) provide an ability to plug into program modules written on C/C++. Thomas and Hunt in "Pragmatic Programmer" wrote a lot about DSL (Domain-Specific Languages). They can be thought as scripting languages with very tight integration into application. I think in future we can expect not only the expansion of using of dynamic languages but also developing of more tight integration between them and static languages.