Is it time to look for alternatives to Visual Smalltalk Enterprise?

Over on the ESUG mailing list [UPDATE: interestingly, the discussion goes on on the squeak-dev mailing list], somebody complains  about “Cincom killing VSE”, a Smalltalk IDE called Visual Smalltalk Enterprise that has been officially discontinued for a very long time now.

The original poster makes it very clear that he is frustrated about the fact that Cincom is not developing VSE any further and charges “big” for fixes. There are, however, quite a few points to consider about this whole VSE affair:

  • Cincom doesn’t own all the rights on the product, so it is a big risk to invest in any work on it
  • The legal situation is probably complicated enough to make it impossible to open source VSE
  • Cincom now has three Smalltalk products on the market, all of which are somewhat different and need to be maintained. From a business stand point, there might be very strong arguments against maintaining a fourth one

VSE has been in this state for many years now (more than 10, to be exact), and the product is still around. I know a few companies who still use it for production systems that are not particularly small or unimportant. In fact these are systems supporting their core business. There still are teams working on new features for systems that are built in an IDE that has not received any updates for more than a decade.

I’m afraid a discussion about open-sourcing VSE and persuading the owners of the IP to give it away will probably not solve any problems. Even if the IP owners have changed their minds in the last few years, there still would have to be a community to actually take the tool and modernize it. So what would be needed would either be a new vendor who invests money into VSE (if the open source license would allow this) and bring it back in shape or a community of people who work on VSE in their spare time. I personally think that even a community will most likely not be able to achieve more than bug fixes. If you are an open source type of guy and want to work in Smalltalk, you’ll probably be deep into Squeak or Pharo or GNU Smalltalk already.

So how likely is an open source community for VSE?

Well, you never know.

But I guess it is also a good idea for VSE users to think about alternatives. There are Smalltalk IDEs around that offer a lot more functionality and are being maintained, both commercial and open source. Some even offer tools that have their roots in VSE (like WindowBuilder and WidgetKit). This might help in porting quite a lot (Yes, I am thinking about VA Smalltalk here – combined with a WindowBuilder translation kit that Instantiations offers. VA even offers native widgets just like VSE – even if it could admittedly be modernized).

ObjectArts and Lesser seem to be working on a Smalltalk environment that runs VSE code seemlessly. I haven’t seen it, so I cannot really comment on it. I am also very sure that Cincom is more than happy to help you get up and running on VisualWorks or ObjectStudio (which also offers native GUIs, but also for today’s Windows versions).

There even are companies offering porting services from Smalltalk IDEs to other languages or to other Smalltalk IDEs. I have seen a system ported from VSE to VAST this way and would not recommend going that way, because your code ends up being neither fully VSE style, nor really at home in VAST. Such tools add some kind of emulation layer to the new system that pretends to the old code that it’s still running where it came from. It works, but it also causes lots of problems.

If your system needs to be maintained into the future, make it a first class citizen of the new environment, even if it means quite some manual work. It will behave strange in many ways otherwise. With today’s tools like the Refactoring Browser and its Rewrite Engine, you can automate a lot.

You also have to be cautios when rewriting a system: you will never really just do a rewrite. You will always add new or replace existing functionality. So it’s better to learn the new environment and not pretend to still be in the old one, because adding more and more functionality on top of your emulation layer will decouple you from the product. You want to adapt Seaside? You better make sure your emulation layer is not messing things up. You want the full power of modern GUI elements using a new framework? First get rid of your VSE style GUI code. The list goes on. Another example: Does it make sense to port your OR-Mapping Framework over to the new environment, just to save the effort of porting to GLORP, for example? Well, I guess the answer is a clear, sounding NO!

What will surely help in a porting effort is that most VSE projects do have quite a few very experienced Smalltalkers that will be able to work in the new environment pretty fast.

I am curious how the discussion on the ESUG mailing list continues, but I guess it won’t get anywhere.

Coming back to the post on the mailing list, I think it somewhat misses the point: Cincom is not killing VSE slowly. They are not killing anything, especially not slowly. It has been as dead as it is right now for over ten years and it was not Cincom who killed it. It was ObjectShare. Cincom does what it is allowed to, namely support VSE customers in running it, but they never made any promises to develop it further or anything.


8 thoughts on “Is it time to look for alternatives to Visual Smalltalk Enterprise?

  1. Sorry to say this, but from a GUI perspective, ObjectStudio is not even close to what is possible with VSE.
    For VS(E), you can easily wrap any widget you want, be it a common control, or another widget, you just need a DLL which contains the functions to call.
    You can do all of this via Smalltalk code, whereas for ObjectStudio, you seem to need C.

    Add any new DLL doing some math for you? Easy in VSE. Create a class, overwrite three methods, add an ExternalBuffer class or two and add the wrappers for your functions. It really is that easy.

    The extent to which VSE can be extended is incredible, that is the reason why it has survived for so long.

  2. I think it somewhat misses the point: Cincom is not killing VSE slowly. They are not killing anything, especially not slowly

    I realise that the subject should have been “Is Cincom slowly killing Visual Smalltalk Enterprice customers”.

    The people who are still using VSE today are not going to port their applications period, the ones that had the money to porting allready did so years ago. But a number of VSE customers have existing applications developed in VSE and are trying to keep them alive, only to find that Cincom is acting offensive.

    A few VSE customers might actually go out of business due to the increasing mandatory support fees from Cincom….

    I don’t believe that a “new open source killer windows oriented killer smalltalk” is to be build upon the remains of VSE, I “just” want existing VSE customers to survive.

  3. As the author of the original I am sorry see that you have understood my intensions, I do not ask for Cincom to do any further development on VSE.

    I am frustrated by the fact that Cincom is blocking the transfer of IP from Seagull software to a fundation. Cincom is trying to milk more money from their current VSE customers.

    Cincom is raising its mandatory support fees, refusing to sell additional developer licenses, bullying people in the community to stop helping each others – while at the same time doing nothing for the product.

    Everybody agrees that VSE is “dead” and it would suit Cincom to just let the product go.

    1. Torsten,

      I’ve read his comments. My impression is that only talking about the VM is not sufficient. It sure is a good thing to have your software running on a performant and well-maintained VM, with a vendor behind it who maintains it.
      But you also need a development environment on top of that, because you need tools and class libraries to write code. The VM alone would run the VSE environment on a new, probably even 64-bit aware, but it would not provide any new tools like Web Services Integration, Web frameworks, HTTP libraries or such. I am sure there are some of these libraries available for VSE already, since people had to help themselves, but that is not the same as a vendor or community that is strong enough to really support a project.

      Sure, there are claims that there will be some Dolphin Version that will run on the DNG VM, and there are claims that it will be easy to port VSE code to it. Since not many people have seen this beast yet, it is hard to tell if that is a promise that will come true. Having used Dolphin a little bit, I have no doubts that this would be a great IDE on Windows. Dolphin is by far the most visually pleasing Smalltalk IDE and offers a lot of nice features. So there probably soon is a very easy migration path from VSE to Dolphin DNG and people will be very happy with their new environment. It would sure be a good thing if VSE projects could find a new home where they feel happy again and contribute to the Smalltalk community rather than feel left behind.

  4. In general one should consider a switch to a newer Smalltalk IDE, but actually I believe, that these customers are – over the long terms – lost Smalltalk customers. Even though, there might be migration paths, they will have to rewrite lots of their applications – which means, that they will also evaluate other possibilities. The same we have done in our company eight years ago – and we have choosen the mainstream path.

    And even when using other Smalltalks – considering VW might bring additional license problems and VASmalltalk – yes, this might be a solution – when they are willing to use Smalltalk again.

    1. Marten,

      the lost Smalltalkers mostly have made their switch (or at least started it) about 5 years ago. If you’ve continued using any Smalltalk IDE over the last decade, you’ve gone through a lot of pressure from your management and “industry experts”.
      So if you’re still using Smalltalk, you either do it because there is a defined end-of-life date for your project, or because you still happily use one of the most productive and flexible languages around.
      Going “to the mainstream”, which clearly meant java or C# a few years ago but is far less sharply defined today, definitely means retraining a team of experienced Smalltalkers to tools and languages that miss quite some flexibility compared even to VSE. Not that Eclipse or VisualStudio offer bad tools, but in areas like debugging and inspecting they still fall behind.

      I agree that a clean move from one Smalltalk IDE to another will be a rewrite of a system in many ways, especially if your old environment hasn’t seen any updates over ten years and more. If anybody tells you something different, you should be very careful. You will want more than just get the old system up and running in the new environment anyways

      So it is very unlikely that a rewrite is a real rewrite without new features and a lot of cleanup. It still is a good idea to rewrite in a system that is very close to the source. All Smalltalk IDEs have a lot in common, and the language is still the same, even if there might be slight differences.

      There have been quite some Smalltalk-to-Smalltalk ports, and we as a cummunity (as well as we as a consulting company) have collected quite a few best practices and techniques to achieve a rewrite with relatively little effort.

Comments are closed.