I don't think the next major applications language will initially have to have the full enterprise capabilities of C or Java to succeed. Visual Basic certainly achieved tremendous success without these capabilities by leveraging the services provided by other frameworks written in lower-level languages like C. We've already determined that the next language should interoperate with other Java programs, hopefully within the same virtual machine. It should also interoperate through a coarse-grained service layer. That said, some enterprise capabilities will be very important.
Database Integration
Minimally, a new language should access relational databases in a natural, productive way. I don't think any particular application style is importantyou can see wildly successful environments with different strategies:
-
Microsoft builds a framework that leverages the power of SQL , row sets, and relational databases. The center of the Microsoft universe, from a data perspective, is the relational database. The strategy can scale very well and is surprisingly productive.
-
Java, instead, seems to be moving toward ORM. The center of Java's data universe is an object-oriented, persistent model. Other Java applications leverage JDBC with helper frameworks quite successfully.
-
Ruby on Rails takes an intermediate approach. Rails wraps a database table with objects that discover the structure of the database dynamically.
All strategies have strengths and weaknesses, and each could serve as an effective foundation for a new language. I do think that emerging languages, and the core frameworks they need, should try to follow these rules:
Embrace the relational database-
While a language may integrate with alternatives, the relational database should be a first-class citizen. Too much focus on object-oriented databases proved to be a problem for adoption for some Smalltalk frameworks. Object-oriented databases are an elegant solution that ignores the current political realities.
Don't force structure on the relational database-
At some level, a language must make it easy to use existing relational schemas, as they exist. Forcing a surrogate unique identifier rather than a composite primary key also ignores existing realities.
Perform, and scale-
High database performance is the single most important indicator of good application performance.
Transactions and Security
Enterprise developers need the ability to define a business transaction. It doesn't matter how fast you can build incorrect applications. If Joe Bob loses $50 in an Internet transaction because Sally Sue crashed the server by tripping on a power cord, the framework is not going to make it in the enterprise.
Security is also important, though you could probably argue over how important it could possibly be with the gaping holes in operating system security today. Java has set a bar that's going to be pretty hard to clear in this area. The next big language will need the ability to integrate with existing enterprise security frameworks, at least the Internet-based schemes and standardized ones like LDAP. Table 5-2 summarizes the enterprise features a new language will need.
Table 5-2. Enterprise requirements for a new language
|
Rule |
Description |
|---|---|
|
Database access API |
Provide a clean, productive API for database access. |
|
Relational databases |
Focus on relational databases first. |
|
Database performance |
Database interactions should be very fast. |
|
Transactions |
Enable application transaction demarcation. |
|
Language security |
Provide a clean foundation for language security. |
|
Application security |
Let developers secure their applications. |
|
Security integration |
Let developers integrate enterprise security, especially for Internet applications. |
Like the Java features, having these basic enterprise features does not guarantee success. They just let you play the game.
