Site Sections
Posts
69
Comments
233
Trackbacks
162
June 2006 Entries
The Evolution of Languages
 Ron Garet did write about his personal experiences at NASAs JPL and how Lisp did perform in outer world (deep space) AI robotic projects. He was kinda disappointed by the way Lisp was abandoned in favor of C and Java because of C-Lisp integration problems. I think it would be interesting to have a look at todays programming languages and their possible future.
The programming languages differ in many aspects such as
Today the most widely used languages are imperative programming languages. With Microsoft pushing .NET the market for general purpose programming languages is consolidating. Thats a good sign. Why would I need more than one programming language at all? They are different but why are C/C++, Java and C# such a big success while others also well designed ones (e.g. Lisp) are not? The first thing that comes to my mind is ease of use and the effort to become good at it. Java makes it so easy that some think it has made programming too easy. Perhaps Java is todays BASIC to which we soon will point with the finger and say:  "Java has no goto statement. Thats a bad thing". Because it is so easy to learn it is one of the first languages that our kids will be exposed to. That means that the programing language world is dominated by imperative languages with a virtual machine inside it for the next decades. I hope this will result in an  ueber language with a basic syntax for all common things (why do I need to learn again and again how to loop over an string array in another language?) and a high quality Base Class Library which can be accessed by any language that does build on top on the used VM. While the syntax already does look similar of C/C++, C# and Java the used programming paradigm is the same. With the introduction of LINQ, which brings many constructs formerly only seen in functional programming language to the masses, different programming paradigms are supported within the very same language in a natural way.
The convergence of languages which drives us to one syntax, one Base Library and support for every  Programming Paradigm will give us the flexibility we need to build even more complex systems in the future. That does sound too good to be true. But what if I need a hand optimized assembly routine for certain constructs? Well you can program today already low level assembly code with managed languages like C#. By analyzing how you need to arrange your looping constructs you can influence the JITer (Just In Time Compiler) to spit out different machine instructions. Greg Young has put up a very nice article how you can basically program assembler by using C#. The ability to write performant code in a very high level language will be the key success factor for a future ueber language which does bring all together. The low level hackers can do their assembly thing and the Java kids have their easy to learn BASIC. To make this happen we will need much more flexibility at the JIT side. Let's suppose you want to write a sophisticated 3D Game using managed code. Since the CPU is not good enough for high speed rendering we could annotate portions of our code to be optimized for the GPU (Graphics Processing Unit) which will execute there. Imagine the possibilities you would have if you could write things like this:

[JITWith("GraphicsCard_GPU_Module")]
void 3DProcessing()
{
      foreach(Point p in Points)  // This code is executed on your graphics card!
      {
           Draw(p);  
      }
}

By the possibility to extend the JIT compiler we do not have any managed unmanaged transition in our high level code anymore. I believe that the language war is not only fought with syntax and libraries but also at the JIT level. Perhaps we have in some years one common language syntax and many JIT extensions to create highly optimized domain specific code.
To have only one syntax is surely whisful thinking (but I like the idea) as it turns out that many complicated (read algorithmic) problems are not easy to implement with mainstream languages because unorthodox solutions will usually collide with good programming practices and the syntax. A smart syntax that is very expressive and does not impose much structure to your program (like enforcing OO) does attract people which write algorithms. So far I have (please correct me if I am wrong) seen the functional programming paradigm mainly in the field of: 
  • Parsers
  • Compilers
  • Algorithms
The less structured syntax elements a language demands the easier it is to change the implementation of an algorithm totally because the structure of your algorithm does dictate the overall structure of your code and not the syntax of the language (e.g. C++ by enforcing OO where it does simply not fit) . In a highly flexible development environment (e.g. robotic research) where radically new ideas are constantly integrated into your code base the functional approach does work very good. But the lack of syntactic structure makes it hard to coordinate the work of many people which do usually work on a small component of a large project. This is where information hiding the and the success of Object Oriented Design comes into the game which brings us nearer to the goal of truly reusable components. Languages emerged to help us to support OO design intrinsically by enforcing it inside their syntax (C++, Java, C#, ...) . With Software Product Lines an old idea has made it into daily business that does create reusable components which are assembled into a commercial product. To make the product line idea work you need common stable interfaces which do not change too much over time. This requires many syntactic elements that hinder your creativity but help to enforce corporate policy at source code level (e.g. Java). No big mental abilities are needed for this, only a certain degree of discipline and the ability to judge where you should cut your program into smaller components to keep it maintainable. From this point of view I think we should be able to do very well with only two general purpose programming languages where one  does support the component fraction whereas the other does help the quick and dirty prototypers. DSL (Domain Specific Languages) could be integrated as LINQ already shows us today into both to get a solid syntactic foundation that could much longer than todays rapid language evolution. Michael Stal has posted a nice article about his point of view how DSLs could be integrated into general purpose programming languages.
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati
Posted On Friday, June 23, 2006 9:19 PM | Feedback (0)
Why .NET Tracing is not reliable

 This time I wanted to write something about the .NET Framework that is solved not optimal of the .NET Framework. My unsuspecting victim is the well known System.Diagnostics.Trace class. Static classes have the big plus that they are easy to use but they can be very hard to maintain if you want to extend it (no derivation) and have a lifetime problem with the objects that are created inside it. The Trace facade is in my opinion a prominent example of  how you should not design a reliable static facade class. It's has many features that are nice but it's at the same time a fine example of design that has lost its vision. It tries to do too many things at the same time without succeeding in the optimal solution for all the goals it might have. Tracing should be fast, right? The .NET Trace definitely not the fastest solution. Yes it's flexible and can be very good configured inside your App.config file. But if you have used the Microsoft Logging Application Block of Enterprise Library 2.0 once then you know how much farther design for flexibility can be done. But I must admit that the Entlib TraceListeners does derive from the .NET ones. Below is a +- table about the .NET Trace regarding Performance Reliability and Extensibility.
In the following article I will show you what reliability issues there are and how to solve them.

Performance Reliability Extensibility/
Ease of use
+ TraceSwitches allow to configure at run  time what  should be traced.


- DefaultTraceListener  uses OutputDebugString  which  is by far the slowest method to trace.


 		 - I loose traces if I do not call Trace.Close/Flush from time to time.

- Static Trace.Close is a mistake because I cannot really close something that is static.

- A Trace.Write after a Trace.Close causes loss of all following traces in case of file based listeners.

(+ Some Listeners do reopen itself after being closed. The File Listener can do this if you init it with a file name)
 + Dynamic Trace Switch Configuration

+ Dynamic Trace Listener Configuration

- Other (Logging) solutions are far more flexible.

- It is nearly impossible to write a program that does  capture all traces even during application shutdown.

The most obvious reliability problem I did find is demonstrated with a very simple Console Application:

Show More ...

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati
Posted On Monday, June 12, 2006 9:18 PM | Feedback (0)


Article Categories
Archives
Post Categories
Image Galleries
Programming