Main | February 2007 »

January 29, 2007

Chapter 4 [Why Java Now Sounds Like] Glass Breaking

Java is now in danger, it's getting too difficult to manage, and both evolutionary and revolutionary steps to remedy the problem are failing us. The basic problems.

4.1. Java's New Job Description


Once Java moved to the server side, it became the core server-side development language. Java carries an increasing load in enterprise development, from object-relational mapping with distributed transactions to messaging with XML binding for service-oriented architectures. So the job that we use Java to do is ever changing. The language is remarkably flexible, so it's lived up to the challenge so far.


But all of the extra power comes with added complexity.

Java is now in danger, it's getting too difficult to manage, and both evolutionary and revolutionary steps to remedy the problem are failing us. The basic problems.

4.1. Java's New Job Description


Once Java moved to the server side, it became the core server-side development language. Java carries an increasing load in enterprise development, from object-relational mapping with distributed transactions to messaging with XML binding for service-oriented architectures. So the job that we use Java to do is ever changing. The language is remarkably flexible, so it's lived up to the challenge so far.


But all of the extra power comes with added complexity.


4.1.1. Typical Requirements


  • Java's become indispensable for writing middleware, the systems software that fits between an application and an operating system.
  • For servlets and web programming in general, Java needs a faster feedback cycle, and needs to get better at managing strings.
  • For XML processing, better alternatives exist. I'd argue that Java's over-reliance on XML is part of the problem, but let me point out that Java is not a particularly good language at handling XML either. XML requires excellent string parsing and manipulation, and Java is just too verbose in this space.
  • For large enterprise projects requiring things like distributed transactions across multiple resources, heavy legacy integration, and code that relies on niche libraries ,


The most common Java job is to take a big, fat relational database and baby-sit it with a web-based user interface.


Java never really has been a general-purpose applications language, though that's the place that most of us use it today.


4.1.2. The Learning Curve


If you're concentrating on putting a web-based frontend on a relational database, Java framework designers have solved this problem repeatedly for eight years. I've got to admit, Java hasn't gotten much better at this job since the invention of JSP.


With the latest release of Tomcat, you can't just write a servlet anymore. You also need to code up a deployment descriptor and package it all up in a standard WAR file. That means you've got to learn more about Tomcat , more about the servlet specification, and more about XML.


4.1.3. Agile Processes


While the requirements for the typical Java application have remained relatively static, radical changes are transforming the typical process that you might use to build it. While not many Java programmers would say they use agile methods like SCRUM or Extreme Programming , more and more of them are using the core techniques from agile processes :


  • Simplicity *Automated unit testing
  • Shortened iterations

4.2. Basic Java Limitations


  • The many frameworks designed to simplify the Java development experience do make experienced Java developers more productive, but make the learning curve too steep for those new to Java.
  • Compile-time checking of exception and types adds safety, but comes at a cost of additional time and syntax.
  • Java's inability to express structured data leads to an over-reliance on XML, with the corresponding additional complexity and bloat.
  • Java's many compromises, like primitives, make Java harder to learn and more complex to write.
  • Java is more dynamic than C++, but is nowhere near as dynamic as languages like Smalltalk and Ruby. Java developers are finding metaprogramming, but they're not able to execute on those ideas fast enough.
  • Java's long compile/deploy cycle is much longer than interpreted, dynamic alternatives.

Taken alone, none of these issues hurts enough to matter. Taken together, Java becomes much less productive for most developers.

4.3. Typing


One of the most fiercely debated topics in programming languages is the benefit of strong, static typing strategies. Java's strategy opts for as much compile-time checking as possible. Let's take a quick overview of programming language design, in layman's terms. Then, you can put Java into context. When building a language, a designer needs to answer two typing questions relatively early in the design process.

  • Strong Versus Weak Typing

    • Static Versus Dynamic Typing
    • Syntax
    • Thought Process
    • Code/Compile Cycle
    • Adaptability
    • Generics
    • Overloading
    • Other Costs

  • The Benefits of Static Typing

    • Static typing reduces certain types of errors
    • provides more information for your IDE and other tools

  • A Safety Net with Holes

    • Primitives

      • Primitives Are Limited
      • Primitives Are Unnaturally Verbose


  • The Big Trade-off


4.5. Parting Shots


  • Sun - Sun is not the company that it once was, placing Java's future in doubt. It's being squeezed on the low end by companies like Intel, Dell, and AMD. IBM is squeezing Sun from above.
  • Exceptions - Like static typing, Java's emphasis on checked exceptions seems like it's on unshakable footing.
  • Expressing Data - Programming and data go hand in hand. In most other languages, structured data becomes a natural part of an application. Part of Java's over-reliance on XML comes from its limited ability to express structured data.
  • Strings - Java, ylacks convenient, high-powered text manipulation, when it's a core job that we ask Java to do. Servlets, XML, JSP, HTML, and many other constructs are strings.
  • Simplicity - Java's already a good language for big, hard-core enterprise programming projects. It's getting better at solving that problem. And Java's never been good at tiny applications.
  • Tools - One of the symptoms to this problem is Java's over-reliance on tools. We Java developers love our IDEs. The truth is that we can't live without them. But,You simply need an IDE to do any real degree of refactoring.

Why Not Just Fix Java?


Most experts that I interviewed tend to think Sun is even now moving in the wrong direction. Instead of making Java more nimble and dynamic at the foundation, the changes, for the most part, amount to additional type safety—syntactic sugar hacks built into the syntax rather than the JVM that often lead to inconsistent behavior.
4.6.1. Libraries and Community
It's clear that libraries are problems, too. Sun has launched several belated simplification movements. So, if it's Java's libraries that are broken, and not the language itself, couldn't we just scrap a few libraries and start over on a more simplified foundation? That's the approach we suggested in Better, Faster, Lighter Java. For Java's most important and basic job, a web-based user interface on a relational database, I don't think Java's frameworks are moving in a healthy direction at all.

4.6.2. Alternatives


Five years ago, most developers that I talked to on a regular basis wanted a good way to baby-sit a big, fat relational database with a web-based user interface. Five years later, they want the same thing.


Java is drifting away from its base.

Chapter 3 [Java's Technological] Crown Jewels


If you're to understand what might possibly come after Java, you need to ask questions about Java's continued success:


  • What makes Java hip, and draw such a wide variety of people?
  • How has the open source community thrived, in times, despite Sun and the power vendors?
  • What are the indispensable technical underpinnings that make Java successful?
  • What makes Java so adaptable that programmers can build everything from web sites to databases?


If you're to understand what might possibly come after Java, you need to ask questions about Java's continued success:


  • What makes Java hip, and draw such a wide variety of people?
  • How has the open source community thrived, in times, despite Sun and the power vendors?
  • What are the indispensable technical underpinnings that make Java successful?
  • What makes Java so adaptable that programmers can build everything from web sites to databases?


Reasons for Java's success according to top Java consultants


  • James Duncan Davidson - server-side programming efficiences; server-side programming in before Java was hard.
  • Jason Hunter- Applets
  • Dennis Sosnoski - Java has a well-designed language and runtime environment.
  • Stuart Halloway - It was better than C++.
  • Richard Monson-Haefel - Java is a great static object-oriented programming language. It's portable and has loads of APIs, products, and open source projects. It is a well-designed language and virtual machine. Initially, it was a very progressive and well-timed language design.
  • Ramnivas Laddad - garbage collection and reflection.


3.1. Language and JVM Design


In 1996, the JVM represented a significant departure from traditional thinking.

3.1.1. Portability


Java's virtual machine simply redefines the machine, providing a lower-level, firmer foundation for portability. Java designers bet that they could overcome performance concerns. When all is said and done, popularizing the idea of the VM may be the most important technical contribution of Java.

3.1.2. Security


  • Changing threats - Microsoft Windows has been besieged with security problems.
  • Remedies in Java

The virtual machine gave Java designers the sandbox, and there's no pointer arithmetic, and because Java has strong runtime typing.

3.1.3. Moving Forward


The idea of the virtual machine is here to stay. The intermediate virtual machine transforms the basic problems of portability, security, and deployment from nearly unsolvable to routine. If the virtual machine adapts to accept dynamic languages, the JVM will probably be the deployment platform of choice for the foreseeable future.

3.2. The Internet


  • Java included convenience features to make applications programming easier. Java added garbage collection and memory management.
  • Java's vision for enterprise computing was centered on the Internet.
  • Java's fathers keenly moved to improve simplicity, at the price of low-level flexibility.
  • Very early, Java was targeted at mobile applications, extending the primary focus of Java into the Internet.

When Sun embedded Java into the first version of Netscape Navigator, this vision looked quite possible.

3.2.1. A Consistent Evolving Vision


Later, applets fell out of favor. Different views of why they failed:

  • Deployment was hard.
  • Programming was hard.
  • The Netscape JVM was buggy.

For whatever reason, applets faded into the background. But Java is a surprisingly nimble beast, at times. In the halls of Netscape, server-side Java emerged. Servlets (a term originally coined by O'Reilly) made server-driven Internet applications available to application developers.


Java's emphasis quickly moved wholly to the server side, where it remains today. Java Server Pages (JSP) continued the evolution.

3.2.2. Moving Forward


The vision of Internet applications is not yet complete. Google is now experimenting with Ajax , which seeks to provide a better experience to users with generated JavaScript? and XML that communicates with the server.

3.3. Enterprise Integration


Java's partnership with IBM, Oracle, BEA, Borland, and others paid huge dividends. They enabled Java connectivity to databases, transaction engines, messaging systems, and any other enterprise system that required a Java connection.


Java remains a good language for enterprise integration projects, because of the high number of frameworks that solve so many of the critical problems.

3.3.1. Moving Forward


Today, Java can talk to just about any enterprise system that's important to you. Beyond integration, Java now provides excellent facilities for mapping object-oriented models to relational databases. You can do distributed coordination of transactions, and manage massive messaging systems with first-class rules engines and workflow.


In the end, Java is sacrificing its primary base, exchanging what was productive and hip for something that is tedious and slow, but powerful.


I'd guess that as many as half of all commercial applications involve a web frontend that baby-sits a plain old relational database. A challenger in that space need only provide a much more productive solution to a niche problem than Java.



3.4. Community


The most critical crown jewel for Java is the community. Said another way, Java's market share makes it the 500-lb. gorilla who can sleep anywhere he chooses. Java's community is as massive as it is diverse.

3.4.1. The Importance of Open Source


In the beginning, open source software powered the servlet revolution through Tomcat. Then, we learned to build with [Eclipse and] Ant , and test with JUnit , and continuously integrate with products like Cruise Control. Later, Struts software changed the way that we organize web-based user interfaces, and Hibernate led a resurgence in transparent persistence. You could easily argue that the most compelling innovations are happening in open source projects

3.4.2. Moving Forward


If there is to be an ultimate challenger for Java, the next successful language will need to achieve a critical mass quickly. That suggests to me that there will need to be some sort of catalyst, like applets in Netscape. The next successful language will probably also need to nurture a massive open source programming community, if it is to enjoy the variety and longevity of Java.

3.5. Breaking the Myths


  • Myth 1: Java's Leadership Is Unassailable
  • Myth 2: Java Is a Great Applications Language
  • Myth 3: Java Is the Most Productive Language

    • Corollary 3a: All languages are about the same

  • Myth 4: Commercial Interests Drive Most Java Innovation
  • Myth 5: Big Things Usually Come from Likely Sources

January 27, 2007

Architectural Improvement by use of Strategic Level Domain-Driven Design

Basically Domain-Driven design can be divided into three areas:


  • Basic building blocks – Addresses how the domain is separated from technology by use of a layered architecture, combined with practical object oriented design patterns.
  • Sophisticated models – Addresses how the software is aligned with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight.
  • Strategic design – Addresses model integrity and management of complexity in large systems. Strategic design provides three core building blocks:

    • Context mapping
    • Distillation
    • Large scale structures


Article


1. Introduction


Company that is the focus of the paper has embraced Enterprise Architecture as one of its means to better align development of corporate IT systems with business priorities and strategies.


Found that our Enterprise Architecture did not provide the tools needed to address key concerns when
designing and integrating large scale software intensive systems. While enterprise architects focus on business processes, functions and information concepts, software architects have to focus on boundaries and interfaces. As the work with our Enterprise Architecture correlated in time with our adoption of Domain-Driven design [3], we discovered that the strategic part of Domain-Driven design provided the needed mechanisms.


Enterprise Architecture (EA) identifies the main components of the organization, its information systems and the ways in which these components work together in order to achieve defined business objectives. The components include staff, business processes, technology, information, financial and other resources required by the business to achieve its objectives Enterprise Architecture is based on a holistic view rather than an application-by-application view. Most enterprises choose to do
their Enterprise Architecture work according to the practices defined by available frameworks tailored to reflect the architectural principles, standards and reference models defined by the individual enterprise. The frameworks typically provide an architectural lifecycle process and a set of views supporting the different stakeholder interests: business process, information, functions and technical infrastructure.


1.2 Domain-Driven Design



Domain-Driven design is a philosophy whose focus is the intricacies of the domain and where the objective is to make these
intricacies explicit in the domain model and its implementation in code. Domain-Driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. The primary source for these principles is Eric Evans book.


Basically Domain-Driven design can be divided into three areas:


  • Basic building blocks – Addresses how the domain is separated from technology by use of a layered architecture, combined with practical object oriented design patterns.
  • Sophisticated models – Addresses how the software is aligned with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight.
  • Strategic design – Addresses model integrity and management of complexity in large systems. Strategic design provides three core building blocks:

    • Context mapping
    • Distillation
    • Large scale structures



2. Context Mapping


A context map is a drawing that documents modelling contexts and their relationships. Large systems contains multiple modelling contexts, therefore we have depicted the modelling context of interests, not the applications or information systems that implement the different contexts.


3. Distillation


Distillation is about separating the important from the less important. Ideally it should be possible to identify the problem
area that motivates development of this actual software. That part of the domain is called the core domain. To be able to keep the core as small as possible, some domain related functionality should be moved out of the core, allowing us to let our most
skilled people focus on the core.


moved out functionality


  • Supporting Domains
  • Generic Sub-Domains

4. Large Scale Structures


Context map itself become complex and unmanageable. There are two elements from the large-scale structures that have proven valuable:

  • the principle of evolving order
  • the use of responsibility layers

Spring Framework Reference - Chapters 1 and 2

Spring provides a light-weight solution for building enterprise-ready applications, while still supporting the possibility of using declarative transaction management, remote access to your logic using RMI or web services, and various options for persisting your data to a database. Spring provides a full-featured MVC framework, and transparent ways of integrating AOP into your software.


Spring provides a light-weight solution for building enterprise-ready applications, while still supporting the possibility of using declarative transaction management, remote access to your logic using RMI or web services, and various options for persisting your data to a database. Spring provides a full-featured MVC framework, and transparent ways of integrating AOP into your software.


Spring could potentially be a one-stop-shop for all your enterprise applications; however, Spring is modular,
allowing you to use just those parts of it that you need, without having to bring in the rest. You can use the Inversion of Control (IoC) container, with Struts on top, but you could also choose to use just the Hibernate integration code or the JDBC
abstraction layer. Spring has been (and continues to be) designed to be non-intrusive, meaning dependencies on
the framework itself are generally none (or absolutely minimal, depending on the area of use).


The IoC component of the Spring Framework addresses the enterprise concern of taking the classes, objects, and services that are to compose an application, by providing a formalized means of composing these various
disparate components into a fully working application ready for use.


Overview


  • The Core package - the most fundamental part of the framework and provides the IoC and Dependency Injection features. The basic concept allows you to decouple the configuration and specification of dependencies from your actual program logic.
  • On top of the Core package sits the Context package - provides a way to access objects in a framework-style manner
  • The DAO package - provides a JDBC-abstraction layer and a way to do programmatic as well as declarative transaction management.
  • The ORM package - provides integration layers for popular object-relational mapping APIs
  • Spring's AOP package - provides an aspect-oriented programming implementation allowing you to cleanly decouple code implementing functionality that should logically speaking be separated.
  • Spring's Web package - provides basic web-oriented integration features
  • Spring's MVC package - provides a Model-View-Controller (MVC) implementation for web-applications,it provides a clean separation between domain model code and web forms.

Human-Computer Interaction - Chapter 1 The Human

Focus on cognative psychology of the human. Model Human Processor basically looking at the human as yet another storage system and processing unit, albeit a small and slow one.


Human-Computer Interaction (by Alan Dix, Janet Finlay, Gregory Abowd, Russell Beale, Prentice Hall)


Notes and [thoughts] as I read this book. Mostly I'll paraphrase the author. I'll usually note something if it is my thoughts or insight by [enclosing it in brackets].
Common topics include: Interfaces, design, paradigms, interactivity, evaluation techniques, cognitive models, collaboration models, task analysis, system models, dialog design.



Chapter 1 The Human


Focus on cognative psychology of the human. Model Human Processor basically looking at the human as yet another storage system and processing unit, albeit a small and slow one.

Humans limited in capacity to process information impacts how we design.



Human input and output channels


  • visual channel - primary source of information for the average person. Mix of perceptive receptivity of light, color. Focus effects perceptions of size and depth. Visual angle and the law of size constancy are factors that effect what we perceive. Motion tracking and visual compensation are a higher level of visual processing. These however are bound by the low-level processing and therefor can be manipulated, causing what appear to be ambiguous perceptions or optical illusions.
  • auditory channel - tends to be under estimated. Perceive what and where. Characteristics like pitch. loudness, timber, all convey various meaning to the human processor. Hearing is tuned individually.
  • haptic channel - touch conveys presence, kinesthesis, texture, temperature. Often neglected, this is becoming a focus for providing additional information about an environment.
  • movement - speed of transmission and response; motor skills (accuracy)



Human information storage


Moving information along the memory structures involved first "attention" then "rehearsal"

  • sensory memory - exists for each sensory channel an are constantly overwritten. We choose which sensory channel to attend to, which is governed by our extent of arousal (level of interest or need)
  • short-term memory - small buffer, used to store informaiton that is needed but only for short durations.
  • long-term memory - main storage resource, stores factual Main.(info), experiential knowledge and procedurak rukes of behavior. Information is stored in episodic and semantic memory, allowing us to reconstruct and relate relationships between information.

The process of forgetting is either decay and or interference.


Information is process and applied


Humans use the memory structures to reason and solve problems, even with only partial information. They are concious and self-aware.

  • reasoning

    • inductive - generalization from imperical experience (never prove it true)
    • dedecutive - reasoning derives logical conclusion
    • abductive - reasoning from fact to action or state of causation

  • problem solving - Humans are adaptive, previous experience to present problem solving and preform well at analogical mapping.
  • skill acquisition - the problems we face genarally aren't completely new. Working in a domain you develop expertise. We perform proceeduralization to tune and speed performance.
  • error - sometimes are paterns of performance hurt us when the things change. False mental models leads to errors.


Emotion influences human capabilities


Human experience is complex. Emotional response effects performance, sometimes possitively sometimes negatively.

Users share common capabilities but are individuals


Although the above statements hold true generally you must take into account your specific audience and work to create accesability to them all.

January 24, 2007

Experimenting with a Blog!

I've used both for well over a year now (I know sometime in the future that will sound funny to me, and does now to some) and I don't really like what I see in blogs.

Both of these technologies offer things like RSS, easy linking, wysiwyg and so on. So that doesn't seem to be a differentiator for me.

Things I care to right about are things I care to remember, journal style - reverse chronological order doesn't seem to fill the bill. But ...

A blog are essentially a user-generated website where entries are made in journal style and displayed in a reverse chronological order. Basically, commentary or news on a particular subject, and more often just a online diary. It would seem the main difference, and it is an important one it they have the ability for readers to leave comments.

I prefer however to use wiki a to publish information about subject that I think bears remembering. Page can and are intended to be reviewed, refactor and updated as needed.

A wiki is a website that allows the authors themselves to easily add, remove, and otherwise edit and change available content, very quickly creating a hierarchy of topics. This ease of interaction and operation makes a wiki an effective tool for mass collaborative authoring. In effect, a wiki is actually a very simple, easy-to-use user-maintained database for searching or even creating information. I've once heard a wiki as defined as the world simplest database.

Both of these technologies offer things like RSS, easy linking, wysiwyg and so on. So that doesn't seem to be a differentiator for me.

Things I care to right about are things I care to remember, journal style - reverse chronological order doesn't seem to fill the bill. But for now I'll give it a try and see if the one aspect that is missing from a wiki - commenting, is anything I care about.

Beyond Java (by Bruce A Tate, O'Reilly)

Notes and [thoughts] as I read this book. Mostly I'll paraphrase the author. I'll note something if it is my thoughts or insight by [enclosing it in brackets].

Common topics include: Java development, frameworks, Spring, Struts, Hibernate, Ruby on Rails, developer productivity, etc.

Here is Chapter 1 "Owls and Ostriches" and Chapter 2 "The Perfect Storm"


Notes and [thoughts] as I read this book. Mostly I'll paraphrase the author. I'll note something if it is my thoughts or insight by [enclosing it in brackets]. Common topics include: Java development, frameworks, Spring, Struts, Hibernate, Ruby on Rails, developer productivity, etc.



Chapter 1 Owls and Ostriches


Subject of the Book

I'll often ignore risks involving minor consequences or low frequencies because dealing with the risk is not wise. Managing the risks properly may take too much effort, money, or time, opening me up to additional risk... [occasionally you make mistakes]...even if I've decided to ignore certain kinds of risks in... [certain environments] and conditions, I've sometimes got to step back and reassess the risk."


Ignorance as a Virtue


Ostrich

I can be surprisingly productive by simply ignoring most problems. With a little luck, the problems often just go away. [But] Such an attitude can work for you or against you.


Owl

If you look closely, you can find some selective, wise application of ignorance...


Tate believes in the dangers of premature optimization, and echo the popular agile principle of YAGNI : "You ain't gonna need it."


When a dominant language or technology is in its prime, there's a blissful ignorance stage, when ignoring alternatives works in your favor. ... Suddenly, your competition has the jump on you, with much better productivity leading to better quality, improved productivity, and more customers. When you enter the transition time, you'd better start paying attention.


Shaken to the Core (by Ruby on Rails, efficiency and productivity gains)


  • Lightweight frameworks
  • Less code is more
  • Customers don't usually care about cool code or mature technology.
  • Keep scouting for rapid changes

Boiling Frogs


Are the waters around us warming? They may not recognize it, but motivations don't matter one little bit. If the water starts to boil, they'll die.

  • You've got to watch for "Danger Signs"

    • He's watching "Java Servlet Programming" the work of Jason Hunter

      • Java is not on top any more
      • The "top" [web technology stack "top"] is where it is at now
      • Watch the "alpha geeks" Querying, Subversion, automation [workflows]


  • It's getting more complex [technology starts simple, solves new problems but then grows and matures and gets complex at some point java becomes the next COBOL.] Rising complexity led to high-level languages, structured programming, and object-oriented programming. My contention is that this higher river of complexity will flood, forcing new abstractions...
  • Rapid Revolution - Most innovation is driven by need. Revolution increases dramatically when complexity hits a certain threshold. ...The implications of the churn are staggering.
  • Unnatural stretching - [We] stretch technologies beyond its intended directions [as complexity and need demand] This is only good to a point and begins the barrier to entry for the new guys. New languages wont come with these overhead.
  • Language evolution - extensions cause the increase in complexity and obscurity
  • What's Good Is GOOD [just because we are talking about new stuff doesn't make the mature stuff "Bad"]

New Horizons


Keep surveying the interesting innovations around new programming languages.

  • Dynamic Languages - [These hold potential because of the productivity and simplification they offer over existing languages. but they must be evaluated on productivity and quality.]
  • Metaprogramming - programming styles that are more transparent, reflective, and dynamic. Think of metaprogramming as building a high-level builder. ... for enterprise application development , the overriding characteristic of a language or environment is productivity . ...each line of code to work harder, and ... to translate into productivity. ... measuring productivity after deployment. If your tiny application is impossible to maintain, you'll lose everything you've gained.
  • Continuation Servers - continuations maintain state

The Premise


... the premise of this book should be taking shape:

  • As languages move away from their base. As harder problems may be easier to solve, but [newly realized] simple [emergent] problems are getting harder to solve. And...
  • A language showing signs of wear, and interesting innovations are beginning to appear outside....
  • It's time to start paying attention again.


Chapter 2 The Perfect Storm


Storm Warning


Frustrations, driven by economics but stemming from inadequacies in programming languages and programming models, rippled through the community in another kind of gathering storm.

  • Economics of Client-Server Computing [Let's just say "doom to fail" - not simple, not scalable - even with cheap PCs]
  • Microsoft - one platform to develop against that was everywhere
  • The Internet - Old languages adapted to this new lightweight network and clients. But quickly fail.
  • Object Orientation - [real abstractions emerge]: encapsulation, inheritance, and polymorphism. ...but it takes some time to build the expertise to recognize patterns and to layer OO software in a way that makes sense. Now we are working on lightweight OOP language features and productivity frameworks.

The C++ Experience


Developers found performance, but discovered another challenge [productivity and approachability].
Thinks that killed it where Pointers, Nested Includes, limited support for managing strings [not enough abstraction], DLL hell, CORBA complexity, multiple inheritance complexity problems, consistency, portability...

Clouds Open


The items above lead to the rise of Java, it solved the problems of the time.

  • New Economics - The Java developed [during the evolution of the Internet and thus] built the API set that would allow developers to code for the Internet...
  • C++ on Prozac - it built on the old technology stack - simplification, abstraction
  • Architecture - improved packaging, portability, extensibility, and deployment

Fury Unleashed


James Duncan Davidson : Why Java Won (inventor of Apache Ant and Tomcat)

Mostly, for what Java was designed for, they got it right. Of course, it's a strongly typed language, which for some purposes is great, and other purposes not. ... Java without the server side wasn't that interesting. It still isn't.


I don't like the massive monolithic approach to "Editions." Most people don't need J2EE. They need a web container. End of story. ... I also don't like the incredible jump to complexity that Java seems to engender in people. No other platform has grown as fast and as elephantine as Java. [He takes the Frederick P. Brooks approach]... I wish that more tools would just remember the lessons of Unix: small pieces loosely joined. There is no one ├╝bersolution, and at the end of the day, if you can take two tools and pipe stuff between them, you have a more powerful and flexible solution than any monolithic beast.


  • Servlets - Servlets gave Java developers a way to write applications that would run in the browser. An application would get a request over HTTP, and build a plain web page, with no Java, that would return to the client. Since the web pages were built server side, they could take dynamic content, like the results of database queries, back down to the client.
  • J2EE - emerged to add a rich set of tools that would let you program distributed, transactional, secure, and persistent applications, without coding those services yourself.
  • Industry Standards - Software is more prone to monopolies than most other industries because software moves fast and obsolescence can devastate a company. For this reason, market share tends to favor the market leader heavily. So it stands to reason that market leaders love to be proprietary. [However] If you can't build dominant share, you can lend your customer safety by creating partnerships and embracing a common standard. In this way, your customers are not nearly as afraid of obsolescence.
  • Open Source - Innovation in the open source community keeps tremendous pressure on software companies to keep up. That's healthy. ... . Open source software raises the bar of what you've got to do to make money. You could even argue that open source software is driving the most important innovation...

Aftermath


[The above pressures are] redefined the way we package and deliver software. To achieve similar success, a new language will need to be portable and encourage a vibrant open source community. It will need broad appeal, across low-level programmers and architects. It will need to embrace compelling standards. Business reasons must drive this move.

Moving Ahead


  • [The factors of the "next thing" will always change]

Weak versus strong languages, who wins the fight?

Static vs. Dynamic

Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong).

Static vs. Dynamic

Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong).


Typing Dimesions

There are at least two dimensions for typing, reference typing and data structure typing. In programming languages both references and data structures can be typed.


Scripting Languages

Sometimes people use the terms dynamic and static, but mean scripting and compiled. Traditionally scripting languages were interpreted languages. No compilation is needed and after changing. This way turn around times are minimized and development is speed up. Scripting languages get virtual machines and are compiled to byte code for better performance.


Functional Style

Functional style development can easier to write, understand and maintain. Especially in applications which have to deal with lots of lists functional programming makes code considerably shorter. Web applications often use lists and so profit from languages which support functional style programming.


Thoughts


First thing that can to mind while reading this article/post was that I have been fortunate to work with a Bertrand Meyer / Eiffel admirer and have found that incorporating in his priciples of "Design by Contract" has improved the quality of the software my team can produce. Like Test Driven Development the preconditions help me focus on understanding the software I'm developing as I create it. Like all successfull languages if a dynamic language grows and thrives and its use becomes widespread and varied. Certain circumstances and business contracts will come to bare on the software, regaurdless of langauge. The implementation will likely differ but the concept will still need to be dealt with.


Can I develop software without using "Design by Contract" concepts? "yes", can I build software with out unit tests? "yes". Will I ever, now that I know the benefits of doing so? "not likely"




"Design by Contract" Wikipedia:Design_by_contract

Programming by contract is a methodology for designing computer software. It prescribes that software designers should define precise checkable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract.


The Problem of Invariants

Most of the issues that arrise are about object invariance, which is an object-oriented programming construct consisting of a set of invariant properties that remain uncompromised regardless of the state of the object. This ensures that the object will always meet predefined conditions, and that methods may, therefore, always reference the object without the risk of making inaccurate presumptions.


Spec #

If anything in the effort to produce better quality software and retain the reflexsive nature of a language like Java or C# the researches over at microsoft are looking at fortifying the area of the C# langauge. In Spec# which integrates into the Microsoft Visual Studio development environment for the .NET platform, the compiler statically enforces non-null types, emits run-time checks for method contracts and invariants, and records the contracts as metadata for consumption by downstream tools. I don't expect Spec# to take off as a language, but rather to have the concepts they are working on be folded into C# over time. .Net 3 might even already have some of these features.


Lists, Collections and Containers

Looking at these "dynamic" languages, I find myself thinking of them more as tools than as languages. Like the new Excel or Powerpoint. These really feel like the are at a different level of abstraction. When I look at Ruby on Rails, I see "you just have to keep the naming right" coupled with a baked in Model View Controller pattern. It makes me marvel at the power of a well implemented design pattern rather than thinking I have to toss out what I've been doing in Java or C#. In a very odd way I see Ruby on Rails, replacing the need for things like Sharepoint Services from Microsoft, which is largely just a list/collection tool all dressed up, with a CAML back end. This is the exact opposite direction of Ruby on Rails however. There is nothing lightwieght or simple about CAML, man Microsoft can truely get the right idea wrong in grand fashion on regular basis. Now I don't see your typical office worker jumping into Ruby, and whoops, there's an app! But I think a whole host of developers who have grown up on ColdFusion, Classic ASP, PHP will be really excited to see the great productivity and simple database accessability that these dynamic languages and lightwieght frameworks provide.