The last thread was getting far too long so I have started another one
as the interest in the future of PowerBASIC design tools seems to be
a considerable one.
The range of suggestions seem to break down into a few different groups,
changes to the compiler, aftermarket programs such as visual design tools
and the suitability of software size and type.
Now in terms of "Bang for your Buck", I suggest that there is general
agreement that Bob Zale's PowerBASIC compilers deliver less code for a
given functionality than probably any other compiler on the market and that
only assemblers can do it better at a higher price in terms of work. This
is not a consideration that should be taken lightly as few others come near
the performance/size ratio.
Some of the suggestions for the compiler are not small asks but very
considerable changes and this needs to be kept in mind when things are
asked for, trivial things that effect the actual performance of the
compiler are a straight waste of time as without the performance advantage
that PowerBASIC programmers have got used to, it could become just another
visual garbage producer.
The general drift towards compilers of the power of Bob Zale's 2 32 bit
versions is based on the difference between visual garbage producers and
the size of true compiled output. What has to be guarded against is making
them like the junk they outperform, a futile exercise.
Visual design tools are a lot less of a problem, they are effectively an
aftermarket program that can use the compiler's low level power without
any need to damage the compiler's performance. It would be imperative that
any visual design tool could at the minimum, produce industry standard
resource scripts as this not only gives access at the inbuilt dialog
engine but it would ensure that the product can be sold on a wider market.
Code size considerations will be with us for a lot longer than many think,
there are literally millions of computers in use that could not be described
as high end hardware and not only in the consumer market but particularly
in the commercial network market. Assuming that every computer has a gig of
ram available is a very good way to ensure that the majority of end users
will not be able to run your software.
The number of 486 machines struggling along with win95 loaded is very large
so the capacity to write small memory footprint programs is a simple market
access consideration, fail to do it and your market shrinks dramatically.
The market for unlimited size balloon ware is already controlled by Visual
Basic so I see little point in emulating a product so bad. The shift from
garbage ware to tidy binary production has been going for a while as many
companies object to the redundancy of computers with such a short life cycle
before they need to be replaced.
[email protected]
as the interest in the future of PowerBASIC design tools seems to be
a considerable one.
The range of suggestions seem to break down into a few different groups,
changes to the compiler, aftermarket programs such as visual design tools
and the suitability of software size and type.
Now in terms of "Bang for your Buck", I suggest that there is general
agreement that Bob Zale's PowerBASIC compilers deliver less code for a
given functionality than probably any other compiler on the market and that
only assemblers can do it better at a higher price in terms of work. This
is not a consideration that should be taken lightly as few others come near
the performance/size ratio.
Some of the suggestions for the compiler are not small asks but very
considerable changes and this needs to be kept in mind when things are
asked for, trivial things that effect the actual performance of the
compiler are a straight waste of time as without the performance advantage
that PowerBASIC programmers have got used to, it could become just another
visual garbage producer.
The general drift towards compilers of the power of Bob Zale's 2 32 bit
versions is based on the difference between visual garbage producers and
the size of true compiled output. What has to be guarded against is making
them like the junk they outperform, a futile exercise.
Visual design tools are a lot less of a problem, they are effectively an
aftermarket program that can use the compiler's low level power without
any need to damage the compiler's performance. It would be imperative that
any visual design tool could at the minimum, produce industry standard
resource scripts as this not only gives access at the inbuilt dialog
engine but it would ensure that the product can be sold on a wider market.
Code size considerations will be with us for a lot longer than many think,
there are literally millions of computers in use that could not be described
as high end hardware and not only in the consumer market but particularly
in the commercial network market. Assuming that every computer has a gig of
ram available is a very good way to ensure that the majority of end users
will not be able to run your software.
The number of 486 machines struggling along with win95 loaded is very large
so the capacity to write small memory footprint programs is a simple market
access consideration, fail to do it and your market shrinks dramatically.
The market for unlimited size balloon ware is already controlled by Visual
Basic so I see little point in emulating a product so bad. The shift from
garbage ware to tidy binary production has been going for a while as many
companies object to the redundancy of computers with such a short life cycle
before they need to be replaced.
[email protected]
Comment