To understand what a technology does and why someone might want to use it, I think it’s helpful to compare what life was like before and after using it.

Like when Blackberry came out with their first full PDA version.  My “day in the life” before that was that I had a paper planner that I used to track my contacts, to-dos and notes.  It was bulky and I frequently didn’t have what i needed when I needed it.  If I lost it I was S.O.L.  My “day in the life after” is that I have my personal data with me all the time and it’s always backed up so I don’t have to worry about losing it.

People often ask me what Hydra is, and I say something like “it’s an integrated development and deployment framework for C++ and Java services.”  This is accurate, but doesn’t really give a good picture (and I’m a visual guy, I like pictures).

So here is my “day in the life” from a software engineer or architect’s perspective - before and after Hydra:

Before Hydra:

• I have an application that has been around for a while, written mostly in C++ code.  I prefer the power of the language and I don’t want to rewrite it, but it takes a lot more development time to maintain and enhance this application than if it were written in another language like Java. 

• The development team mostly uses command shell editors and a custom build environment, which is a steep learning curve and productivity sink for the more junior engineers.

• Our deployment environment works, but we have had to cobble together different software, some commercial and some open source, to make it all work.  It’s hard to maintain and upgrade and I’d like to simplify the environment and reduce the number of vendors that I work with.

After Hydra:

• Once the development team starting using the Hydra IDE in Eclipse, they became much more productive both with C++ and Java code and it’s all in one tool.  The automatic code generation saves a lot of the ‘grunt work’ and it’s easier to debug, test and redeploy, shortening our dev cycles - this is huge in supporting our move to Agile Methodology. 

• The Hydra runtime hosts both C++ and Java services in the same process so I don’t have to pay the performance cost of web services when they’re on the same server.  I can use BPEL to orchestrate the services, but I don’t have to.  Plus, I know that the whole thing is deployed to a scalable service grid that I can reconfigure as my requirements change.

• In addition, it’s a single, integrated environment.  I can add other components if I want to, and the architecture is much cleaner and easier to maintain and extend.  It’s based on web services and SOA standards (WSDL, SCA, etc.) so I have some protection from vendor lock-in.  And I’m closer to having “one throat to choke” with my vendor when I need something.

In all, we’ve reduced our development effort, so we can do more with less and get releases out faster.  This has saved the company money and makes our team look better.

I meet with a lot of our users in my role at Rogue Wave, and one of the things that I’ve heard from a few people lately is the term “Java envy”.  When I ask what they mean by that, they’re not referring to the language itself.  C++ developers like the control they have over memory usage and predictable performance.  What they’re talking about are the multitude of developer tools that are available for Java development.

Rogue Wave has always strived to be the leader in providing C++ products and tools to make developers more productive.  One of our products, HydraEnterprise, continues that goal.  HydraEnterprise provides the ability to create, orchestrate and deploy services to a runtime.  It can create web services, as well as native C++ and Java services, BPEL, data access and others.  It also comes with some developer tools that make doing all those tasks much easier.  The tools are Eclipse plug-ins that allow you to create services within an easy to use GUI, taking advantage of the editors within Eclipse.  You can create WSDL files, generate service wrappers, orchestrate the workflow between services and deploy to the runtime very quickly.  If you would like to see this demonstrated, we have an online tutorial series where one of our sales engineers will create and deploy a C++ service in under 30 minutes.  Send an email to tutorial@roguewave.com indicating your desire and you will receive an email with the details for the next demonstration.

C++ developers rejoice, as Rogue Wave is still working to make your lives easier.

We at Rogue Wave are very aware of what we have termed the multi-core dilemma.  The problem is simple:  multi-core chips require software concurrency to take advantage of the full processing power.  The solution can be very challenging, however, requiring developers to introduce threading or multi-process code into their applications.  We have been promoting the ability to achieve parallelism at a service level within our Hydra product line, but within SourcePro we have until now only provided a threading abstraction layer that still requires significant application refactoring if not used initially.

To help improve the ability for our customers to take advantage of multi-core architectures, we are currently investigating ways to introduce parallelism within some of our current SourcePro classes.  The easiest area to add parallelism “under the hood”, so to speak, is in areas where there is read-only access occuring.  For these cases, we maintain safety in performing parallel operations that hopefully would require no code changes for our customers.

To ensure that introducing parallelism where it previously didn’t exist will not cause issues with existing use of the products, we are looking to make activation of the parallel code occur from a switch type mechanism.  We could provide a new build flag, an environment variable or other options to allow the developer to easily test the new operations, and switch back to the existing implementations if necessary.

Areas we are looking at include search methods on RWCString, methods on collections for sorting and search with iterators, as well as new higher level parallel algorithms that we could add to SourcePro DB.  We are actively soliciting feedback from our customers on which classes and methods are used most frequently, as well as ideas on where parallelism could provide the most benefit.  Please comment with your ideas and interests to help us maximize the benefit from these new enhancements.

Joe Pruit posted a blog responding to some thoughts from Rogue Wave on C++ in 2008. We know that not everybody sees C++ in the same way we do, but we issued the press release was to challenge some of the conventions of how developers and architects perceive C++. Joe’s comments are worth reading, and are also worth responding to.

Enterprise applications do widely use Java and .NET, no question. Managed languages are the right tool for the job for a wide variety of applications. C++ however, (plus C and other native languages) continues a solid, and in many cases, growing presence in several areas:

High performance: for applications that require low latency and/or low memory usage, a large number of architects are choosing C++ in favor of managed languages. These are common in Financial Services, Military and many other applications. An interesting recent example is the team from Carnegie Mellon that won $2mm in the DARPA Urban Challenge for building an intelligent robotic car. According to the project lead, “Everything we did was written in C++.”

Embedded: For embedded and mobile devices, one of the fastest growing areas in computing, C++ is the language of choice over both Java and .NET. Lower memory, tighter power and heat limits and other requirements make C++ a natural choice for optimized application development. According to the Gartner Dataquest report ‘User Survey Analysis: Embedded Software Development Tools and RTOS, North America, 2006′, “For application development, C and C++ are the most popular development languages. Surprisingly, Java usage dropped in 2006.” (Daya Nadamuni, 13 September 2008)

Existing apps: And, of course there are billions of lines of existing mission critical applications built on C++ in enterprises around the world.

These are almost all mission critical, and many are also legacy. In my experience, many if not most mission critical applications are also legacy. My favorite quote on this: years ago, one of my dev managers once quipped that the definition of legacy is “anything that has gone into production…”

As far as the overall viability of the language, there are a few interesting points worth considering:

1. C++ developers are commanding strong salaries, in many cases higher than developers with Java and .NET. I don’t know for sure, but I suspect it’s a combination of C++ resurgence and a smaller number of C++ developers available.

2. Universities are starting to reconsider their move to teaching computer science students in Java. Many universities continue to teach in C++ so that students have a solid foundational understanding of how systems work. Some professors contend that teaching Java has contributed to a decline in computer science skills.

3. The language has a vibrant (and broad) standards community and continues a solid evolution. The C++0X standards effort is creating the next version of the language. The proposed enhancements include modern concepts from Java and elsewhere, but still maintain what makes C++ unique and different.

Although Java and .NET continue to have significant mindshare for mainstream applications, C++ is the language of choice for many architects in new development projects - probably more than most people think.

Two New York University professors, Dr. Robert Dewar and Dr. Edmond Schonberg, have written an article in the Journal of Defense Software Engineering about computer science courses neglecting basic skills, in particular in the areas of programming and formal methods.  The professors’ opinions have attracted discussion in places such as Slashdot and other popular Web sites since they have taken particular exception to the recent emphasis on Java in computer science courses.

The professors provide brief overviews of the educational benefits of various programming languages, including C and C++:

Why C Matters
C is the low-level language that everyone must know. It can be seen as a portable assembly language, and as such it exposes the underlying machine and forces the student to understand clearly the relationship between software and hardware. Performance analysis is more straightforward, because the cost of every software statement is clear. Finally, compilers (GCC for example) make it easy to examine the generated assembly code, which is an excellent tool for understanding machine language and architecture.

Why C++ Matters
C++ brings to C the fundamental concepts of modern software engineering: encapsulation with classes and namespaces, information hiding through protected and private data and operations, programming by extension through virtual methods and derived classes, etc. C++ also pushes storage management as far as it can go without full-blown garbage collection, with constructors and destructors.

What perhaps makes the professors’ opinions more credible is that their concerns are also commercial since they develop software commercially:

As founders of a company that specializes in Ada programming tools for mission-critical systems, we find it harder to recruit qualified applicants who have the right foundational skills. We want to advocate a more rigorous formation, in which formal methods are introduced early on, and programming languages play a central role in CS education

As the head of Rogue Wave Software’s professional services group, I’ve noticed that many of the younger engineers working in some of our customers are less skilled in C++ than their older colleagues.  While we’re happy to help our customers by filling in the skills gap on projects, it’s still a longer term worry because every programming language needs well educated and skilled developers. Teaching C++ in universities is a topic that I’ve been thinking about for some time. I’m particularly interested in what Rogue Wave can do to help with fundamental C++ skills, like promoting the use of the C++ Standard Library in universities and perhaps looking at the practicalities of making Rogue Wave’s products available for use in computer science courses. 

I’m very pleased to announce the General Availability of SourcePro Edition 10, a very special event for Rogue Wave Software.

SourcePro is our flagship product and the main reason why we can claim to be the market leader in enterprise C++. We are launching the tenth version of SourcePro - a significant milestone that very few application development products reach. It’s a testament to the quality of the product and a demonstration of Rogue Wave’s long term commitment to the product, especially given the recent market trends moving in favor of C++  - most notably, new language standards coming in C++0X and giving C++ the same status as Java in new SOA industry standards such as SCA and SDO.

The full GA version of the product is available for customers now and the evaluation version will be available on our Web site in February.

The new SourcePro release scheduled for launch next week includes the Apache C++ Standard Library (stdcxx), which has recently been promoted to Top Level Project status by the Apache Software Foundation after over two years in incubation (you can read the project history here). Rogue Wave Software is the primary sponsor of this project, which is based on our own standard library. There are many companies with products that have been opened, but few ever achieve the status of being an Apache project. It takes a lot of work to get a project out of incubation and to the status of being a full Apache project.

It’s a big achievement and the primary driver from Rogue Wave Software has been Martin Sebor - congratulations, Martin!

Welcome to the Rogue Wave Software blog. We’d like to take the opportunity to let you know how it all started.

Rogue Wave Software was founded in the late 1980s by Dr. Tom Keffer, a faculty member of Woods Hole Oceanographic Institute. He named the company after his sailboat.

The first commercial Rogue Wave product was based on a University of Washington project, the Data Analysis and Interactive Modeling System (DAIMS), which was the first attempt at solving large numerical problems in C++. It was launched under the name Math.h++, which can now be found, still going strong, as part of SourcePro Analysis.

The product was quickly expanded into broader class libraries with the launch of Tools.h++ in 1990 as the answer for a general data structure library for C++. Tools.h++ is also still in widespread use as part of SourcePro.

It was Dr. Keffer’s systematic approach as a scientist that resulted in the now legandary reliability and performance of these first two products. This focus provided the basis for everything that has come later. They effectively decided the product direction and roadmap for over 15 years: high performance enterprise application development in C++.

So as C++ applications continue to evolve over time to be part of Service Oriented Architectures, we will be there supporting our customers by providing the reliability and performance they have come to expect.