IBM Business Value Analyst

The IBM Business Value Analyst was developed independently by leading IT research firm IDC and leading ROI tool developer Alinean, Inc. and has been authorized for use by IBM and its business partners.  This analysis tool helps customers examine current opportunities for and quantifies potential benefits from implementing a wide range IBM business and IT solutions.

https://roianalyst.alinean.com/ibm_bva

The speed, size and dependability of programming languages

The Computer Language Benchmarks Game is a collection of 1368 programs, consisting of 19 benchmark reimplemented across 72 programming languages. It is a fantastic resource if you are trying to compare programming languages quantitatively. Which, oddly, very few people seems to be interested in doing.

The Benchmark Game spends a lot of efforts justifying itself against claims that the benchmarks are always flawed and that the whole exercise is pointless. I don’t think it is. In fact, I’ve found that The Game is remarkably effective at predicting which forum hosts programmers annoyed at the slowness of their language, and that’s good enough for me.

I was happy to find that in addition to speed The Game also publishes a source-code-size metric for each benchmark programs in each language. Thanks to this The Game let us at explore a fascinating aspect of programming language design: the tension that exist between expressiveness and performance. It is this tension that gives the expression “higher-level programming language” a pejorative connotation. When you are coding this high, you might be writing beautiful code, but you are so far away from the hardware you can’t possibly get good performance, right?

size-vs-speed-vs-depandability

C# (3, 4) has the same shape as Java (3, 7), merely 1, 2, or three rows down, depending on how you count. The arrival of Scala (6, 7) in the Java world is a mixed blessing. While it fixes the worse convolutions (it has no top-of-the-square points) it also introduces terrible performance hiccups (the points which shoots out to the right.)

Does introducing functional features kill performance?

No, it does not. In the following chart, the ordering is the same as in the large chart. Languages which include functional features such as lambda, map, and tail call optimization are highlighted in green. C compilers, C++ and C-derivatives are in blue. The blues dominate the first column. The greens occupy the main diagonal, from the oddball corner to the “ideal” corner. Ultimately the first factor of performance is the maturity of the implementation.

size-vs-speed-vs-depandability-paradim

Software Open Standards

 

Choice-The choice I make today doesn’t limit the choices I can make in the future.
Flexibility–I can connect to internal departments and external partners that made different technology choices.
Speed–I can build new solutions that involve multiple hardware and software platforms quickly.
Agility–I can adjust to changing business parameters (new opportunities, new partners, new employees) quickly.
Skills–I can find skilled resources that understand these solutions.

Choice-The choice I make today doesn’t limit the choices I can make in the future.

Flexibility–I can connect to internal departments and external partners that made different technology choices.

Speed–I can build new solutions that involve multiple hardware and software platforms quickly.

Agility–I can adjust to changing business parameters (new opportunities, new partners, new employees) quickly.

Skills–I can find skilled resources that understand these solutions.