This is basic question comes to Architects many times.
I consider following factors to choose a programming language.
1. Performance (High speed, low memory, low CPU utilization)
2. Maintainability (New team should be able to understand and fix issues)
3. Durability (Project should survive minimum 10 to 20 years. This is for backend projects. Not for UI development.)
4. Should work on Unix / Linux
5. Should have good documentation and support on internet
6. Preferably Open Source or low license fees.
7. Availability and affordability of resources (People, Software, Hardware, IDEs, Books, ..etc).
8. Proven track record or good team behind that language development.
Case Study: Which one I choose for backend development from Clojure, Groovy, JRuby, Java, Jython, Scala, Xtend, Haskell ?
My choices are as follows
Programming: Java.
Text processing: PERL
Database: Oracle
Web services and other framework: Spring
UI: JQuery, JSP, Displaytag
OS: Linux
Today visited “Etowah’s Wattle & Daub House”. It is very impressive. You can see complete information here http://www.gastateparks.org/item/160828 . This is very common practice in India too. My grand parents had this type of houses. What I liked in it is …
1. Easy to construct.
2. All earthly materials.
3. Low Costs.
4. Local Jobs.
5. Own Ideas.
6. They can’t over build, when they dont need it. Because it is their own labor.
7. Easy to incorporate their needs into construction. I remembered attics, hen house, lamp posts, …etc incorporated into house.
8. No landfills after demolition.
9. Reacts nicely to local temperatures.
10. Simplicity
Moral of the story: Incorporate similar principles in Software too.
1. Simplicity
2. Less Costs
3. Dont build for 100 years, when you want to stay for 30 years. This reduces cost.
-o-
Look at this video. How easy / affordable to people to build.
Problem Statement: How to architect for given problem statement?
Each application is developed as combination of multiple components (Across different layers).
For our discussion, assume the following.
Type A
Type B
Type C
Comments
Number of components
1
6
12
Runtime System Qualities
Functionality
no
impact
no
impact
no
impact
Performance
1x
12x
24x
Each
component will take x units of time for checking incoming data and formating
out going data.
Or marshaling and unmarshaling of XML data takes more time.
Security
1x
6x
12x
Each
entry point is valunarable for hacking.
Availability
1x
6x
12x
If
each component is running in different layers,
Posibility of managing them is difficult. Ex. ESB, Service, Client, JMS
Queues, …etc
Usability (of overall application)
no
impact
no
impact
no
impact
Interoperability
low
moderate
high
The
chances are less to use with other projects.
Non-Runtime System Qualities
Modifiability
difficult
moderate
difficult
In
Type C architecture, a small change in code triggers more integration testing
and more changes.
Portability
difficult
moderate
difficult
In
Type C, It will difficult to maintain intigrity down the line
Reusability
difficult
moderate
difficult
In
Type C, It will difficult to maintain intigrity down the line
Integrability
easy
moderate
difficult
In
Type C, It will difficult to maintain intigrity down the line
Testability
1x
6x
12x
x
is number of test cases for one component
Work Distribution
difficult
moderate
easy
Integration Testing
Easy
moderate
Difficult
Troubleshooting in production
Easy
moderate
Difficult
Due
to more entry and exit points, checking each component will be difficult.
Versioning
Easy
moderate
Difficult
If
we started using different versions of components, it will be difficult to
maintain integrity down the line.
Conclusion:
Over simplicity and too much complexity is killer in application architecture / design. Many architects abuse application architecture.
