It is a rather wasteful use of time to recreate the same applications in a different language each time a new language arrives on the scene. In the past 20 years that I have been in the world of computer science, I have seen many different languages come and a few go. Many seemed to be created with the initial task of trying to solve either administrative problems or provide a new capabilty, through language constructs, for solving a particular class of problems. Few have actually added substantially to the ease of programming in general, and the stability of applications specifically. Java is the exception that I have recognized and grown to use exclusively.
General purpose programming has been slowly (smalltalk came on the scene some 20 years ago) moving toward object oriented programming. Smalltalk set the stage, with C++, Perl, Java (and the plethora of modified Javas), Python and others to follow. The computer science community has learned some things that are important about procedural programming. Languages such as Algol created some stirring new concepts. Many concepts that date from that far back have reappeared in some related form in newer languages.
There is of course languages of other natures that have been gathering significant followings. Some are related to artificial intelligence. There is the whole class of languages that deal with very abstract levels of expression. The runtime overhead of some of these is so large that they really can only be used for small problems as an example of the power of these languages.
What I perceive for most of the procedural languages that are 20 years old or less, is that each has been created to solve a class of problem that was difficult (but not impossible) to solve using an existing language. The phrase "Application Oriented Language" generally applies to this type of language. Perl was created for text processing. The awk and sed applications in UN*X make it possible to do most of the things that the original version of Perl did. It was perhaps easier to create Perl for a particular class of complex document parsing, than to write all of the combined awk and sed code wrapped in a shell script.
Languages such as Python don't really seem to help solve OO programming problems dramatically easier. The dynamic nature of typing in Python does make a certain class of programming problems seem easier. But, for general OO programming, Python is not really a dramatic, simplifying technology.
Of course, there are people who are going to argue with these assertions. I am sure that there are many that use Python as their primary programming language. There are certainly many that refer to the Perl/Python programmers as the "script-kiddies" because many of the most prevalent uses of these languages is for simple scripting problems in web server CGI services, PHP, JSP and related uses. It is clear that for many people who are not software engineers, that there has been some element of power and simplicity realized in the use of these languages.
The original class of problems that most of these languages were targeted at solving still remain the place where they are most actively used (and effective), and thus they are Application Oriented Languages.
Java is Very Different
The Java programming language was originally targeted at the Web for use in applets. The applet programming model, while powerful, initially had problems related to the UI component portability as well as the Microsoft Java license violations, and some of the restrictions of the initial security model in the JDK1.x specification. Many types of applets were created that were effective however. People found the lowest common denominators that worked, and used then. However, the first target arena for Java moved directly to the server side with the advent of Java Server Pages and the Servlet programming APIs provided in the Java Web Server and later in the Apache web server. These technologies greatly improved server side programming technologies from the use of shell scripts or programs using the CGI interfaces. Python and Perl were soon on the web server bandwagon too.
What is the Target Application?
Many of the Java technologies, when released by Sun, and other Java vendors have ended up being used for completely different solution spaces than they were originally targeted for. This is what makes it clear that Java is a much more general purpose language. People see the technologies in Java, and find them to be general purpose enough to be used in a wide range of places. People have really complained about Java not having certain things like regular expressions (it does now). There are many other basic things that people have complained about Java not having. I believe that Sun and the rest of the JCP have tried to keep from mandating things in the language that were not generally useful. This allows 3rd parties to provide these technologies as additional packages to be used when needed.
More recently, the JCP has started to add convenience classes, APIs and features. This will enlarge the requirements for other implementations. But, they say that it will make it possible for the less trained programmers to get more out of using Java.
Other topics to discuss...
There has been some evolution in the requirements of programmers.
There has been some evolution in the size of the hardware that the programmer could use.
There were some language performance problems, and program maintainability was problematic.
C and C++ really provide no support to the user for true memory management, out of the box. Everyone has had to develop toolsets, idioms and mantras for how to make sure you don't end up writting or reading through an invalid pointer.
This has gone on for way too long, and it just seems like everyone that is still doing new applications in C or C++ on platforms where Java is available, are just too proud, or profoundly uninformed.
Smalltalk and many other OO languages truely provided a new paradigm in programming. The power of Objects is compelling. What's next? More Objects, no Objects, or...
One language feature that is overdue for popularization in mainstream languages is type inference. People in universities have been using languages like ML and Haskell for years but none of these Hindley-Milner based languages have made the leap.
I'm thinking about trying out this one, mainly because the syntax is familiar enough to go back to intermittently:
The Java programming language was originally targeted at the Web for use in applets.
That's nonsense. Java (nee Oak) was originally targeted at embedded and small devices. And it shows. That it found a niche just as the Web was coming of age is merely fortuitous. (Well, luck and Sun marketing, really.)
Languages such as Python don't really seem to help solve OO programming problems dramatically easier. The dynamic nature of typing in Python does make a certain class of programming problems seem easier. But, for general OO programming, Python is not really a dramatic, simplifying technology.
That may be because the OO in Python is a less-than-ideal implementation in an otherwise procedural language. In general, strong dynamic typing makes OO simpler, and a deeply OO language such as, say, Ruby shows this. But it's ironic to use Java as a point of comparsion for OO developlement, given that it is mostly, but not strongly, OO. Give me a language where *everything* is an object, and where every object can be subclassed.
Many of the Java technologies, when released by Sun, and other Java vendors have ended up being used for completely different solution spaces than they were originally targeted for. This is what makes it clear that Java is a much more general purpose language.
No, this only shows that, once a large corporation can convince enough companies that their tool is the Golden Hammer, developers are compelled to use it regardles of how inappropriate.
> The Java programming language was originally targeted > at the Web for use in applets. > > That's nonsense. Java (nee Oak) was originally targeted at > embedded and small devices. And it shows. That it found > a niche just as the Web was coming of age is merely > fortuitous. (Well, luck and Sun marketing, really.)
Sun released java in concert with the HotJava browser which ran Applets. A short time later they worked hand in hand with Netscape to integrate applet support into Netscape. I was in NYC the day that was shown to the world. I said Java, and not OAK on purpose. Oak's application was small visually oriented applications that need to work reliably. It was later moved to the applet world, and that was a reasonable match given the relative immaturity of the language. Applets on web pages were very similar to control screens on the kinds of devices that Oak was shown on (remote controls).
> That may be because the OO in Python is a less-than-ideal > implementation in an otherwise procedural language. In > general, strong dynamic typing makes OO simpler, and a > deeply OO language such as, say, Ruby shows this. But > it's ironic to use Java as a point of comparsion for OO > developlement, given that it is mostly, but not strongly, > OO. Give me a language where *everything* is an object, > and where every object can be subclassed.
There are reasons why you can't subclass every single object. There are reasons why everything is not an object. Sometimes, I don't like those reasons. However, I have never really had to compromise the design of an application because of that. I just had to put some wrappers in place which made real objects of out primatives.
> No, this only shows that, once a large corporation can > convince enough companies that their tool is the Golden > Hammer, developers are compelled to use it regardles of > how inappropriate.
Sun is not the convincing party. Sun is not a good marketeer. I think that developers use what works for them. Java is working for me. I see that others have had similar experiences.
It's not all a majestic painting. Java has had growing pains related to Sun's attempts to target the language at various markets which weren't prepared to use Java because of hardware or market issues.
Jini provides such a provocative set of solutions to distributed computing that it alone is a good reason to invest it the Java platform...
>> It is clear that for many people who are not software engineers, that there has been some element of power and simplicity realized in the use of these languages. <<
It's true for many who are extremely talented software engineers, as well. Eric S. Raymond is one of the more famous Python advocates. Dave Thomas and Andy Hunt (the Pragmatic Programmers) are two of the driving forces in the Ruby community.
I think Java programmers who categorically look down on scripting languages are of the same mindset as C/C++ programmers who categorically look down on Java. It doesn't take a genius to realize that each category of languages strikes a very different balance between ease of development, ease of maintenance, performance, scalability, control, and compatibility; and as such, there are generally going to be scenarios where any given language is going to be better than another.
As far as what's next... Personally I am curious whether a language that is designed from the ground up for AOP would be useful. Also I am curious to see how higher-order functions in C# turn out (good thing they're trying it, Sun never would).
> >> It is clear that for many people who are not software > engineers, that there has been some element of power and > simplicity realized in the use of these languages. << > > I think Java programmers who categorically look down on > scripting languages are of the same mindset as C/C++ > programmers who categorically look down on Java. It > doesn't take a genius to realize that each category of > languages strikes a very different balance between ease of > development, ease of maintenance, performance, > scalability, control, and compatibility; and as such, > there are generally going to be scenarios where any given > language is going to be better than another.
I don't disagree with this statement. However, I do feel pretty strongly that applying scripting languages to the task of full blown applications is a problem. What I am specifically at odds with is whether it makes since to take application logic, that is often new, and interesting to a wide audience, and write that application in a random language, which makes reuse inside of other applications problematic.
This is where we get the scenarios that I discussed originally. People run around recreating something that they like, or need strickly because their is not a common platform that allows reuse of programmed logic. Simple scripting chores are one thing. But more complex text processing task, or more complex data manipulation written in a scripting language that doesn't integrate well with enterprise applications is my biggest issue.
So, I guess my theme of one platform is really about how do we conciously make a decision about a platform to develop on that makes the software community at large more productive, and makes it possible for people to not have to spend time reinventing the wheel so much just because they don't have algorithm X in the language that their application is written in.
> As far as what's next... Personally I am curious whether a > language that is designed from the ground up for AOP would > be useful.
There is discussion about this in many different forums. I've got my ear to the ground on this one.
> Also I am curious to see how higher-order > functions in C# turn out (good thing they're trying it, > Sun never would).
I think that its unfair, at this point, to say that "Sun won't" or "Sun Doesn't" for things related to the Java technologies. While Sun still plays a sizeable role, you can become a part of the JCP for free, and work up a JSR for just about anything you can imagine. If the community thinks that it's a useful addition to the platform, it will fly. If it is controversial, or there are other issues related to politics, there might be more things to deal with.
What I see happening is people unwilling to participate in the community to make things happen, and instead running over in a corner to play by themselves so that they can do whatever they want. The problem is that they spend all their time trying to get their favorite idea implemented in isolation, and most just turn into experiments where all the good stuff that was learned is buried in an obscure web page (if we're lucky).
Python, Perl, Ruby etc. do have places, and very practicle uses. And many like to write big applications with them it seems. But how many different GUI implementations and toolkits, security infrastructures and bugfree runtimes do we really need to create to be productive. If I spend 5 man months to develop a new simple scripting language so that I would not have had to spend a week writing a library to support the same task on a particular programming platform, what have I really accomplised?
I think it would be much more prudent to pay a lot of attention to what we've learned over the past 20 years of the life of the usenet and other software communities. Everyone can create software, no doubt. The latest numbers from sourceforge.net are amazing. But how many can help an existing piece of software become even more usable without completely replacing it? We have to learn to work together and live together both...
The Java platform has capabilities that provide a wide range of capabilities for a wide range of applications. I think its a great choice for many different sized applications. If you don't think so, you are entitled to your opinion. I would just encourage you to look around and see what others are doing and try and support a sound programming platform that provides everyone a chance at software reuse on all scales.
> What I see happening is people unwilling to participate in > the community to make things happen, and instead running > over in a corner to play by themselves so that they can do > whatever they want. The problem is that they spend all > their time trying to get their favorite idea implemented > in isolation, and most just turn into experiments where > all the good stuff that was learned is buried in an > obscure web page (if we're lucky).
Perhaps its because the community is clique-ish. That was certainly true of the C++ committee. Nearly every decision made was the worst of all worlds because everybody was happy if everybody was equally unhappy.
Also, some of us find the language to be unredeemably broken already.
> I think it would be much more prudent to pay a lot of > attention to what we've learned over the past 20 years of > the life of the usenet and other software communities. > Everyone can create software, no doubt. The latest > numbers from sourceforge.net are amazing. But how many > can help an existing piece of software become even more > usable without completely replacing it? We have to learn > to work together and live together both...
You have to start with a good foundation.
> The Java platform has capabilities that provide a wide > range of capabilities for a wide range of applications.
Unless you're trying to do a traditional GUI - then it falls flat on its face.
> I think its a great choice for many different sized > applications. If you don't think so, you are entitled to > your opinion. I would just encourage you to look around > and see what others are doing and try and support a sound > programming platform that provides everyone a chance at > software reuse on all scales.
I do - its called Smalltalk - I find it annoying that the new developers of languages have yet to equal the Smalltalk language and runtime environment for elegance and productivity. I also find it annoying that there hasn't been much in true originality in language design in the last 10 years or so except in the scripting language arena.
> > The Java platform has capabilities that provide a wide > > range of capabilities for a wide range of applications.
So it's nice to be able to use the platform as a library, and program in some more expressive language.
>I do - its called Smalltalk - I find it annoying that the >new developers of languages have yet to equal the >Smalltalk language and runtime environment for elegance >and productivity.
Older Smalltalks had problems with modularity and open-standards, I'm pleased to see that these have been addressed in modern commercial Smalltalk implementations.
>I also find it annoying that there >hasn't been much in true originality in language design in >the last 10 years or so except in the scripting language >arena.
There have been remarkable advances in the understanding and implementations of functional programming languages. Those influences have been felt in scripting languages and may be seen in coming versions of C# (and languages like Nice which target the JVM).
I had jotted down several specific comments on this, but I think I'll defer them in favor of this brief article on the The psychology of Learning which, I think, offers some very relevant insight:
However, as we confront increasingly complex problems, we will find that Lisp, or indeed any fixed programming language, is not sufficient for our needs. We must constantly turn to new languages in order to express our ideas more effectively. Establishing new languages is a powerful strategy for controlling complexity in engineering design; we can often enhance our ability to deal with a complex problem by adopting a new language that enables us to describe (and hence to think about) the problem in a different way, using primitives, means of combination, and means of abstraction that are particularly well suited to the problem at hand.
Many of the general purpose languages evolved from a desire to express new programming styles concisely (pascal from Wirth's stepwise refinement, smalltalk for objects, eiffel for DBC, etc). Looking about the landscape, AOP and test-driven development are styles which don't have a language to call their own. I'd suspect they're where the next languages will come from.
Previous Topic
