LCDS covered a lot of ground; from reliable realtime to simple declarative ORM based persistence. It combines the two into a single programming model with lots of features you can turn on and off. Some of those really are enterprise features competing with enterprise messaging products out there like lightstreamer, and others in the financial world mostly. For simple persistence there are many alternatives: GraniteDS, Midnightcoders.com, and look at the stuff by Farata systems. Many people just stick with the free simple messaging and remoting in BlazeDS. What makes LCDS 3 special is the combination of a powersoft like toolset and programming model with a well designed, efficient, scalable messaging system. If priced properly, it would have been a win for both developers and the enterprise sales team. Without developers who know how to use all of that stuff and to refine and enhance the tools, solutions built with it will be hard to maintain even for the enterprise customers. Eventually they’ll stop using it and go with the cheaper, more open standards based toolset.

We wholeheartedly adopted your Adobe product in late 2005/early 2006. With passion and exuberance, since then we have based upon it every line of code we’ve written, because it solved so many problems inherent in all other stacks.

It brought us platform independence on both the client and the server, it brought us an efficient communication protocol, and even a delivery method for the client software. It was also extensible, and flexible. An unsupported feature could be built, and added to the mix.

To finish a new project, we only had to supply the business logic, and the arrangement of visual components. We were allowed to focus on what was different about a given project, instead of what stays the same each time. It provided a level of productivity which allowed us to be competitive.

I mention these benefits because they are applicable to your new platform. Reuse of tested components which “learn” from their environment allows the user to function at a high level of abstraction. Meta information, applied to a specific situation is where the component becomes automatically specialized for a given task.

We’ve been hit hard with the new Adobe pricing because we were putting together an affordable enterprise solution, not a pricey one. We have the “make it up in volume” mentality. To make a solution accessible to the masses seems like the correct market strategy for newcomers and old timers alike. Despite the pricing issues, we are motivated to see it through!

Thank you so much for sharing your perspective.

Good question about the C++ family… ultimately I don’t suspect the number of C++ developers to grow and if anything it may shrink. Security and complexity of the language are the two biggest problems. Performance will always be an issue but I think secure/stable computing will be an even more important thing going forward. That said, C++ developers will probably always make more than other developers on average cause it is the hardest and some problems still require big memory, or “as fast as possible” computing. I don’t suspect java or any other runtime except maybe objective C to take over that any time soon, but as component sets that do stuff like that are imported into the JVM you’ll need to use C++ for a smaller percentage of the problems.

I agree with your opinions about the market of software platforms. But, I don’t belive in the next big language; I think there is a look for each category of problems. In the future, I expect better tools, not better languages; for example, in my “dreams”, a scheduler at process level (instructions are total ordered “threads”).

Jeff, do you think C++0x will get back what it lost in the last years?

Nice post about the current situation of some technologies.
I understand you in some sense. Working with CORBA in the beginning of my career ( around 1998) I had that feeling that whatever program/application I would write, it would run and interoperate with other programs. That was a great feeling. You model the main components of your application in IDL then it’s your choice to implement it in whatever language you are more familiar with.

Looking back now, it looks like the DSL is what will evolve, generalistic languages require a huge initial investment. A language that will be easy to learn (high level), run across multiple platforms(linux, windows, mac, iphone, android…) , is suitable for enterprise (clustered) and can be used to helps us create 3D applications, that is something I still look forward to see.

About the best way to market your project, like in any time, a good strategy is that you care, but not too much.