Re: What happended to visual parse++?

I don't know what happened to Sandstone or Visual Parse++, but I have
put an inquiry in with the last person I know who had access to Bill
Donahue and the Visual Parse++ sources. If I can make reasonable
arrangements such that I can sell and support Visual Parse++, I will
post notice here. Unfortunately, I can't promise more than that.
Still in the VP++ situation, I hope I can be of help.


My guess is that as they stopped making money on it--software tools
are very hard to make money on--they simply abandoned the business.


Software tools perenially suffer from a modified form of "the crisis
of the commons". Writing a quick-and-dirty tool is generally not
hard. Therefore, a lot of "free" or near free tools spring up, and
sometimes make a little money for the author. However, the
maintenance cost of continuing to keep the tool working in the face of
changing environments, such as new versions of the compiler and
evolving language dialects (even C isn't the same it was in the 70's,
and many users have migrated to Java or C# or futher away to Python or
Ruby or Haskell) is prohibitive. Moreover, customers are loathe to
pay very much for a tool, when there is a low cost tool which is often
"good enough" available. Very seldom does the customer realize that
by using such a tool, they are likely to end up with no support and no
upgrade path. (I'm not surprised that one person wrote they kept a
legacy machine just running an old copy of Visual Parse++ that they no
longer can buy a replacement for.) Thus, it is cheapest for most
customers in the short run, to take a short sighted view and that view
mitagates against the development of a sustainable software tools
industry, because it makes it difficult for people to maintain
products beyond a fairly low level of quality. It is particularly
unfortunate when this problem hurts people who are willing to invest
in their tools, and hence my goal to "rescue" VP++ although I know it
will be mostly a "labor of love".


Being on the other side of it, it is equally not fun to get calls
where all the original developers have left, and there is some
critical software using an outdated version of my product (on an
outdated platform that is no longer available), and the person wants
free support to get it working on a new platform.


Recently, I added "backwards compatibility" support into Yacc++ to
ameliorate that problem somewhat. With it, the new version can
emulate the old versions, including some (but not all) of the old bugs
that have been repaired. That at least gives one a fighting chance of
getting the old software to work.


The other partial solution to the (outdated software) problem is
offered by "open source".


        Aside: In fact, I am preparing an open source (GPL) version of
        Yacc++ for release in the next couple of weeks. The goal is to
        relase a version that has the functionality of 2.0 or 2.1, but
        with all the latest bug fixes. And, yes, I just fixed a 17 year
        old flaw in the last couple of weeks. Sometimes it takes a while
        to see what exactly is wrong and how it should be fixed
        (especially if the bug is in an obscure corner where most code
        doesn't get affected by it and when one can put patches around to
        make that corner smaller and less accessible, which is how one can
        get by for 17 years without being bothered by it).


With an open source (or source available version), one can get
the sources to a version and hold onto them. That's only a partial
solution, because even with the sources, a client doesn't often have
the expertise to fix things when "something" breaks. To make that a
complete solution, one needs to make certain that someone
knowledgeable stays interested (which probably means funded) in
keeping the project alive.


By the way, one of the problems with some open source projects
(especially small ones) is that there isn't one developer who stays
motivated, and instead one gets a whole series of splintered forks
where someone got interested in solving one problem and worked on it
for a while but abandoned it, and then another got interested in a
different problem and did a separate fork and abandoned that, and so
on. Moreover, you can't really blame the developers for that, they
are doing it to solve their problem, not yours, and it is easiest to
solve a problem if you don't worry about what other things you are
breaking and not worry about keeping something continuously working.


It's only a problem for smaller open source projects, because one
person can't get their mind around all of Linux, Apache, or Emacs,
while one can easily clone LEX to Flex to Flex++ or Yacc to BYacc to
Bison and BTYACC (and MKS Yacc and PCYACC). Moreover, it is easiest
to clone such tools from "first principles" (i.e. by starting from
scratch or near scratch). Thus, it is hard to support the notion of
compatiblity (much less) "bug compatibility" going forward without a
conscious effort on the part of the developers. The easiest course
for a small project developer is exactly the course which breaks
compatibility.


Note, we suffered from the same thing when we did Yacc++, it was
easier to build it from scratch than it would have been to take an
existing version of Yacc or Bison and modify it (and clearly more
legal to do so given how we wanted to sell it). Moreover, when
Terence Parr descided to do PCCTS version 2, it was easier for him to
start from scratch that to reuse his existing 1.x code (and it wasn't
that his 1.x code was at all bad).


To amplify that a bit more, it was easiest to write Yacc++ from
scratch, because one of our initial goals was to have easily
understood (by us) tables. We wanted tables we could "debug". The
compression and overlaying standard yacc did at the time, made the
tables how to decode. Therefore, the easiest solution for us was to
build a much simpler table processor. And, the reason we wanted
tables we could understand is because we were experimenting with ELR
parsing, and knew that the tables would have bugs, so we wanted to be
able to read the tables to track down those bugs. Now, that the
tables are really mature and secure, I suspect some day I will put in
yacc compatible table packing, just because it is easy and safe to do
now.


Just one person's rambling thoughts on the topic,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------


P.S. To John, I apolgize that most of the content of this isn't
compiler related (aside for having started with the sorry state of
most compiler tools). I hope it isn't so far afield that it isn't
worth posting, since this is probably the only way to get to a large
audiance of VP++ (and other tool) clients. So, let me know, if this
is too close to spam.
[This message is entirely about compilers, what's actually involved in
writing and maintaining them. It's fine. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.