Thursday, December 17, 2009

Should Java become Dynamic?

Other than scripting needs, I have never ever tried using dynamic programming languages. Javascript is a good example for the constructs that you see in other strictly dynamic or scripting languages, ofcourse some are object oriented.

The core of Java was never to wander into areas already tried and tested by other OO and scripting languages, but to arrive at a community consensus ( corporate and developer ) in terms of where general purpose languages should move towards. There were/are some very clear directions conceived/followed from the onset of Java. We are able to see the maturity of enterprise software development in a phenomenal way in this regard.
Even dire contradictors to Java as a paradigm shift would find it hard to reject the fact that it has created more confidence in the community about the ultimate purpose of programming languages. We could talk about this purpose issue in sometime.

The significant question which has come up with the emergence of Ruby, Groovy, Spring about simplicity and ofcourse, the mild emergence of Smalltalk in the developer community has instilled a confidence with pro-dynamic theorists that Java would eventually become a dynamic / dynamic typed language and would accept more and more scripting features as a dire need from the community.
Java world has always been accepting in terms of popular demand. Has been the strength and trumpcard for the langauge and platform all along.
Dynamic programming as a result would become applicable in concepts and implementation would so surely evolve from there into other constructs which are today forbidden in the Java World. But, to what extent is the question.

Even in the non-enterprise scenario, the issues of maintainability, predictable code are pivotal. Purists might argue against to some level in this regard. But mainstream programming would surely agree.
Prototyping, test scripts are places where there is already a clear need for dynamic constructs. Here, the static approach of Java creates Havoc. Anyone who has tried out agile/XP or a decent amount of test scripting would agree with this.

One of the reasons why the much talked about XP is still a dream even in Java world ( with powerful theoritical acceptance for the idea) is because of this. How many applications lack consistent coverage ( particularly products with enough business logic content/rules) of test scripting in mainstream. Where is the convincing argument for this from the community till date for management approval. Should XP be in books or be practiced only in Show-Off projects?

Many of these questions would open up the need for dynamic scripting within the Java world in similar areas. But the necessity for static typed code for enterprise applications is too strong an argument to be thrown down by whimsical statements...

Off-late, I am trying my hand at Smalltalk which is more OO than Java and in some sense can be called its Guru. This statement gives due credit to smalltalk for its strong OO fundamentals ( even primitives are Objects), concept of JVM and others.
There are other features of simpler coding style, image based rather than source code based development, dynamic typing and many others areas where they contrast. Having originated from the same stem ( if i can call it) they have branched out in areas very clearly. Where smalltalk allows for scripting as an important need of a powerful language and maintains it till date, Java wanted to create a consensus and was more sure about static typing, sensible developer comfort, maintainable code.

How much does smalltalk wants to allow bare scripting inside its OO code. Does anyone see a logical anamoly here. How much freedom is enough? As a smalltalker when u script in workspace you feel procedural and suddenly when you shift into OO coding, dont you feel that you are doing something else with the language (which is fine). What I am pointing out here is, the contradiction in approach visible here is the root idea behind Java all along and is not an easy argument to trash.

Who will draw the line and where for simplicity? Who will enforce discipline into coding style and purpose here?

Being a general purpose language, Is the crux really about safety or developer convenience?

Why cant Java atleast be bit dynamic and let the architect decide where to draw the line.

And dynamic language proponents understand the fact that as long as its dynamic it might remain niche and not completely general purpose.
What can the smalltalk purists say about this?

Can we conclude that dynamic typing and scripting is just a matter of convenience and surely not a dire argument to conclude on the general purpose / enterprise software development debate?

Let see in years to come...

Wednesday, December 9, 2009

Is Java going to transform?

I have spent about ten years in Java development. It started off for me as a college initiative to get a neat website with a minimal search engine for the content. Like the conceptualization of the language itself my attempt was dry and without enough support, but eventually gave me an introduction to the software industry as its seen everywhere.

I started wandering on the library in those days to get more info about current trends starting off from JOOPS - Journal of object oriented programming which had developers from all walks of life entering into software like bees and then somehow i made up my mind to be part of this notorious discipline.

In campuses I still feel there is more passion to software development than in real world. Look through the web, its real.

Even my own attempt to write something about my experiences after a career spanning 10 years is a proof to the fact that there is more dry type of software development happening outside really.

But like how it all happened with Java all along if you are speaking about consensus and not writing a book for yourself!!!!
It will converge at some point and add value to people who follow and trying to follow through...

Back to tech..

I never felt something like Spring would ever happen in Java.

I have an authority to say this after spending more than a decade in Java and trying out to compile and make code work from 1.1.3 onwards.
The plethora of time I have spent in identifying application server issues, constructs and workarounds would never allow me to understand that this will change ever.
But it did...

Thats why I still have hope with Java that if you are speaking about consensus, you are speaking about the right language.....