Hello Marcel,
On 09-Jun-99 00:13:59, you wrote:
>> >And yes, if you implement such checks yourself, your code can run
>> >quicker than when you use a more generic implementation if you're an
>> >expert in this field (I agree that this example is rather trivial, so
>> >most of the time you can do it more efficiently yourself). On the other
>> >hand, if you have to do it yourself, you will have to write more code,
>> >meaning you're less productive. In a commercial environment, there will
>> >be a real chance that you'll simply skip the checks because of time
>> >constraints...
>> In a commercial environment you will use debug libraries and stress tools.
>> They don't catch all the possible bugs, but they will help you to find most
>> of them.
>Not in our experience, if you have hundreds of customers that use your
>product every day, they tend to do things that your own testing-department
>doesn't find. This has lots of reasons. Of course we also use debug, test and
>stress tools, but I'm not that confident that we find all or most bugs with
>them.
It's not the use of Java that improves that. The fact is that the use of
Java does not guarantee that you'll ship bug free programs. Let's say for
instance that a program has a bug that leads to division by zero fault.
With or without Java, you can handle the exception in pretty much the same
way. The only difference is that in Java you can't get rid of the range
validation overhead.
>> A real example of my personal experience: BGUI. Last year I inherited the
>> development of BGUI. I didn't want to but it would have been a waste to
>> not carry on the development of one of the last absolutely free GUI
>> toolkits that is reasonably complete.
>This is a pretty nice description. You are taking this very seriously. Having
Maybe even more seriously than you are thinking. There is an interesting
text about BGUI evolution at http://www.bgui.e-na.net/manifest.html . It
talks about many of the advances of BGUI as a BOOPSI based GUI toolkit.
Reading it you will be aware of the level of matutity that BGUI reached.
>written a (rather small and fairly unknown) layout engine for the Amiga
>(EAGUI) I know some of the issues involved.
Really? I would like to invite you are anybody else with GUI development
experience to join the BGUI developers team. We need people that still
care about the Amiga to bring up this fine and FREE GUI toolkit.
>It is however not a commercial product.
For the matter, it is irrelevant. I was talking about my personal
experience.
>> All this to say what? You'll have an hard time to catch your bugs if you
>> don't provide means to detect them before you ship your programs. But you
>> must not neglect that shipping your programs with debug code that affects
>> significantly its performance is not a good idea.
>I totally disagree with you on that point, at least for our applications.
>Stability and the ability to detect and recover from error conditions is more
>important to us. Especially in products we ship. Remember that the Windows
>platform has many (and I mean many) different configurations and that each of
>them might cause weird problems which we simply cannot test ourselves (yeah,
>we actually could, if we would multiply our prices by 10 or so, but that
>would not work well).
I don't follow you. Why would Java programs provide better stability and
ability to detect them before you ship them?
>> If you don't realize that soon enough, you users might just drop your
>> programs before they bother to tell you that your programs are too slow to
>> be usable.
>They might. Perhaps we're fortunate, because we only get more users at the
>moment and they're pretty happy with our products. Probably our products are
That's what I am telling you. You are probably not getting complaints from
users that think your programs are slow because they give up on them and don't
bother telling you.
>not "too slow to use", probably they also "could be faster", but there is a
>point at which performance does not matter that much... and with Pentium
>chips running at 400MHz with 128MB internal memory, there is a lot of
>performance to waste.
That's Microsoft way of think: "Why saving on resources when there are
alread 400MHz Pentiums?" Because not everybody has them. This is a stupid
and coercive way of leading the market. No wonder why a lot of people hate
them and don't bother to tell them.
>> It just doesn't seem you have a way to have your Java programs run without
>> these things that more or less affect your programs performance. I don't
>> think it is wise to take that as a minor problem.
>I think that depends on what you're using Java for. There are a lot of areas
>where the main concern is not "performance" but rather "time to market",
>"price", "maintainability" and things like that. I don't disagree with your
>observations, I simply think you're putting too much focus on performance (at
>least from my point of view).
I just think that it seems you are probably too much Java biased and
therefore are neglecting that Java execution overhead is a problem, not to
speak of Java loading overhead.
Regards,
Manuel Lemos
Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
--
E-mail: [EMAIL PROTECTED]
URL: http://www.mlemos.e-na.net/
PGP key: finger:[EMAIL PROTECTED]
--
--
To unsubscribe send "unsubscribe daytona-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
