Showing posts with label muse. Show all posts
Showing posts with label muse. Show all posts

2009/04/07

Temptations of Software Engineers

Have you ever been tempted to use a technology just because of the technology itself? Was the technology such a fancy thing that you could not resist? Please do not do that! A result of your work would be barely usable in the real life. Do you know the superior Swiss knife with all the stuff inside? I am in doubt you could ever carve a little wooden ship for your son with it.
Let me tell you a true story of a software engineer and an application he developed.

Once upon a time, there was a guy who decided to learn Java and all its bright features, which brought the light on every programmer's possible problem. He chose a set of features that were most interesting to him including serialization, and multi threading. To be not all alone and to verify his code, he decided to take a community as a hostage. Let's inspect a couple of his mistakes.

First, serialization is good for remote method invocation, for sending objects over network, and even for storing small project configurations into a file. It should not be used as a primary data storage, since there are relational databases for such a purpose. If you wanted to be thread safe in a serialize-everything environment, you must keep all the objects in the memory and (de)serialize them only on an application start/shutdown. It is slow, complicated and inefficient way.

Second, multi threading is a powerful thing but it is like the fire - it can be very dangerous. Threads are not independent processes. You should be careful about them, especially if they are running third party code. Apart of that issue, the biggest problem was that Thread.stop() does not stop a waiting thread on all JVM implementations. It is not good idea to stick to an implementation detail. Later, Thread's methods stop(), suspend(), and resume() have become deprecated because it showed up that they are unsafe.

I could have continue here with similar cases but that should be enough to show what I meant by temptations. If the project were now buried deep in the binary scarp, everything was fine. Unfortunately, the community around it become large and the project is massively used nowadays. And the users must fight with those design issues hidden deep inside of it.

2009/04/01

Guts of Programming Languages

What makes it difficult to master a new programming language when you already know one or two? Is it a fancy syntax? Is it an API? I do not think so.

A syntactic sugar is not the real matter of the programming art. It should be only a hammer for your nails. Usually, a new syntax is not so much different. I mean how often do you meet a brand new paradigm? There is imperative, functional, logic and whatever programming, but you have probably chosen your way already.

Modern IDEs can help you with the API of the new language. Again, API should not be an obstacle. But there is still a thing that you must be aware of...

I do not know of any real programming language that isolates a programmer from its inside behavior (by a real programming language I mean a language that is commonly used for developing long running applications). You always need to be aware of a memory model, of a garbage collection mechanism, of a just in time compilation, of a target system architecture, of registers size, of a class inner representation, of a variable size in bytes...

There are too many "of". I wonder when there is a language that allows developers to concentrate completely on the main problem. A friend of mine suggested that PHP is such a language but I do not agree with that. It is a language which leaves a field of corpses behind itself and must finish processing sooner than anybody reveals this fact.

I have a favorite programming language, which isolates me at most. It is in the functional languages family, and it is called Haskell. You can even write a GUI application in Haskell, but an application server would be a death match.

So good luck in those hard times and do your best for you not to forget any single language implementation detail...

. .