Three simple rules!

It great that I can write anything on MY personal blog. Here I am putting down 3 simple rules for those who do not think that they are obvious.

1. It okay not to be omniscient.

It is not possible to know everything about everything in this world (leave alone other worlds!). Hence smart people have areas of interest. It is okay to say "I don't know" (unless that is what you have to say about just everything!)

2. Focus on the "your" issues.

There are a lot of issues and problems in this world ranging from "nuclear proliferation" to "sexual oppression". Focus on issues that will make YOU a better person first; maybe its competence, health, whatever. This will help you and in turn, a lot of people around you. The current "state of the world" is not a good enough reason for your plight.

3. Realize where you stand in relation to the world.

If you think that you should be the center of attraction, try to list a few reasons. Is it genetic superiority or is it inborn talent? Are the manifestations so obvious to others as well?

Otherwise try to put in some smart work and try to be what you aspire to be. In short, it is better not to believe that "you are the culmination of all history" (like Calvin, the 6 year old, believes)

If the above were obvious to you, you are not part of the intended audience.

Relevance of Domain Specific Languages

I just read Brian Slesinsky's Weblog on Why most of us won't be inventing little languages. It is true because the languages nowadays are not equipped with the facility (except languages like LISP).

I feel that we need the combination of both; generic and domain specific (derivable from the generic language) languages. The flexibility should be present in a language to mold it into a domain specific language (as in LISP using Macros)

When we are developing a reasonably complex application we would want a domain specific language that we could create/change ourselves with ease. This would speed up the development and would help the thinking process. We may also want to "refactor" commonality into a more domain specific language as we go on.

The speed of development comes mainly due to the reduction in the amount of code that needs to be written in a domain specific language and the fact that it helps in thinking about the problem.

But as Brian said, if we are developing a library we would want others to understand and use it. Hence for an API you would want to provide a wrapper in the generic language. Majority of the developers usually try to understand just enough of a library to use it. The wrapper written in a generic/ well known syntax would serve just that.

For example, take the case of imaging..
A domain specific language, in which we can specify transformations, kernel operations, etc., would enable the API developer to add huge amounts of functionality very quickly. On top of it if she adds a wrapper for developers to make direct calls, it would be easy to use.

Anyone who wants to dive deeper and change things would have to understand the domain specific language but that is the price one has to pay for getting so much functionality/ bug-fixes so fast. However the core part would be very concise than if it were to be written in the generic language.
Another way is to "expand" the code written in domain specific language to a readable, generic language.