Author |
Topic: A History Lesson (Read 685 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: A History Lesson
« Reply #15 on: Nov 15th, 2013, 5:32pm » |
|
on Nov 15th, 2013, 1:17pm, ady wrote:| It's not always a case of being anti-anything, it can be a case of being pro-something else. |
|
All very philosophical, but what does it mean?! As I've stated that I want to avoid supporting both v5.95a and v6.00a, I can't really see how being 'pro v5.95a' is different from being 'anti v6.00a' as far as my options are concerned. Perhaps you can elucidate.
Richard.
|
|
 Logged
|
|
|
|
Malvern
Guest
|
|
Re: A History Lesson
« Reply #16 on: Nov 15th, 2013, 5:39pm » |
|
You only want to support one version.
Version 6 is part of LBB which I assume is supported.
So the aim of only supporting one version can only be satisfied by issuing BB4W in a V6 flavour, n'est pas?
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender: 
Posts: 210
|
|
Re: A History Lesson
« Reply #17 on: Nov 15th, 2013, 7:54pm » |
|
on Nov 15th, 2013, 08:52am, Richard Russell wrote:| Can you try to explain what it is about v6 that might make it "not what you want"? |
|
Not really, except that through the various messages here, it does sound as though it might include various upgrades that mean editing an old version of code might require more work than with v5x. - 'A proportion (hopefully a very small one) of existing programs would require modification, and those that don't *might* run slightly more slowly...'
Quote:| I tried to explain why I am not prepared to support two versions in parallel. In any case I don't really understand what you mean by "not with software upgrade support" |
|
What I mean is not producing v5.95 alongside v6, but continuing with 'message' help for any concerns peculiar to v5x.
Quote:| ...are you suggesting that I break my promise that a purchase of BB4W is 'for life'? |
|
I would suggest no such thing! I'm not sure where that suggestion came from.
Quote:| I'm pleased that one of the 'anti v6' people has spoken up, because I was beginning to wonder where they had gone! |
|
I agree with Ady on this one. I'm certainly not against v6, but if it's changed too much (and I certainly don't know that it will be) I might decide to stick with v5.94. But then again, I might conclude that v6 is far better for me.
My main point was really that I prefer upgrades to be backward compatible. But if that's not practical, I'm not going to throw my dummy out of my pram  .
You didn't answer my question about running both versions in parallel.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #18 on: Nov 15th, 2013, 7:59pm » |
|
on Nov 15th, 2013, 5:39pm, Malvern wrote:You only want to support one version.
Version 6 is part of LBB which I assume is supported.
So the aim of only supporting one version can only be satisfied by issuing BB4W in a V6 flavour, n'est pas? |
|
Interesting theory! But it doesn't really hold up because LBB doesn't use the BB4W v6 IDE or compiler, so those don't need any support. Also, LBB uses only a small subset of the features of BBC BASIC so the support needed for the run-time engine is limited as well. In any case LBB is freeware so the support provided is rather more informal.
All things considered I don't think LBB really impacts on the decision.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #19 on: Nov 15th, 2013, 8:21pm » |
|
on Nov 15th, 2013, 7:54pm, Matt wrote:| Not really, except that through the various messages here, it does sound as though it might include various upgrades that mean editing an old version of code might require more work than with v5x. |
|
But exactly the same applies to those who are enthusiastically encouraging me to dump v5 and release v6. What it comes down to, I suppose, is whether you are a 'glass half empty' or 'glass half full' person.
Quote:| if it's changed too much (and I certainly don't know that it will be) I might decide to stick with v5.94. |
|
Why don't you know? I've explained what's been added, I've explained what's been removed, and I've explained what program features might result in an incompatibility. I've also made the BB4W v6 run-time engine available to anybody who wants to try it, via the LBB 'hack'. Doesn't that allow you to decide now whether or not you'll want to stick with v5?
Quote:| You didn't answer my question about running both versions in parallel. |
|
It's been discussed before. The main issue is that both versions will be sharing the same registry keys. So for example the InstallPath key will point to whichever was installed last. Configuration settings will be shared, so for example you can't set v5 to have 1 Mbyte of memory and v6 to have 2 Mbytes of memory (which are the default settings).
So it's certainly possible to have both versions installed, but they won't be entirely independent and you need to keep your wits about you to avoid potential conflicts and confusion.
Richard.
|
| « Last Edit: Nov 15th, 2013, 8:26pm by admin » |
Logged
|
|
|
|
dje4816
New Member
member is offline
Posts: 11
|
|
Re: A History Lesson
« Reply #20 on: Nov 16th, 2013, 08:33am » |
|
Richard,
I also vote for v6. I want those bigger floats, but I also believe you have to move forward. A language will eventually atrophy and die if it doesn't evolve.
Best regards,
Dave.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #21 on: Nov 16th, 2013, 1:43pm » |
|
on Nov 16th, 2013, 08:33am, dje4816 wrote:| A language will eventually atrophy and die if it doesn't evolve. |
|
I couldn't disagree more! One of the great strengths of the original BBC Micro BASIC was that it was programmed into a masked ROM, and was therefore 'frozen'. A stable, bug-free, language is in my opinion far superior to a language which keeps "evolving" - i.e. acquiring more and more spurious features that hardly anybody needs, and at the same time more and more bugs!
As I've said countless times before, BBC BASIC is a traditional interpreted language; every 'compiled' executable has to contain a full copy of the interpreter. Adding new features to the 'core language' means that everybody's executables get bigger, and slower (because of less efficient cache usage), even if they don't make any use of the new features.
The way to enhance the capabilities of BB4W is not to add to the interpreter, but instead to write new libraries. There's a real demand for them (for example the recently-discussed GUILIB), but can I persuade the user community to help with that task - no!
BB4W v6 is an aberration forced on me by the need to achieve better compatibility with Liberty BASIC. It hasn't altered my opinion on the merits of stability versus 'progress'.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: A History Lesson
« Reply #22 on: Nov 17th, 2013, 06:27am » |
|
on Nov 16th, 2013, 1:43pm, Richard Russell wrote:| I couldn't disagree more! One of the great strengths of the original BBC Micro BASIC was that it was programmed into a masked ROM, and was therefore 'frozen'. A stable, bug-free, language is in my opinion far superior to a language which keeps "evolving" - i.e. acquiring more and more spurious features that hardly anybody needs, and at the same time more and more bugs! |
|
And yet your BBCBasic (for Windows) has 'evolved' by adding various extra key words, etc. The basic 'principal' that you always seem to aspire to might be the same, but, in it's entirety, it has definitely 'evolved', (so far, for the better, in my opinion).
Matt
|
|
Logged
|
|
|
|
Edja
Developer
member is offline
Posts: 60
|
|
Re: A History Lesson
« Reply #23 on: Nov 17th, 2013, 10:10am » |
|
"The way to enhance the capabilities of BB4W is not to add to the interpreter, but instead to write new libraries."
I think the main point was clear : further enhancements to BB4W should come from libraries.
If I had the skills ...
Eddy
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #24 on: Nov 17th, 2013, 10:34am » |
|
on Nov 17th, 2013, 06:27am, Matt wrote:| And yet your BBCBasic (for Windows) has 'evolved' by adding various extra key words, etc. The basic 'principal' that you always seem to aspire to might be the same, but, in it's entirety, it has definitely 'evolved', (so far, for the better, in my opinion). |
|
I must say I'm quite confused. On the one hand you say "My vote would usually be for a backwards compatible version" yet on the other you say "it has definitely 'evolved', (so far, for the better, in my opinion)".
The trouble is that 'evolution' often involves a degree of incompatibility. It's almost impossible to add a new feature without the potential for some existing programs to be affected. Adding a new keyword may break programs that happened to use it as a variable name, or adding a new data type can break existing syntax (e.g. prior to 'byte variables' being added PRINT A&F meant 'print the value of A followed by 15, whereas now it means 'print the value of A& followed by the value of F').
Some of the major upgrades of BB4W that took place in the past, which you describe as "evolution for the better", involved incompatibilities comparable with those that v6 would cause. For example the addition of 64-bit floats in v2.00a was much the same as the introduction of 80-bit floats in v6. Or the change of maximum string length from 255 bytes to 65535 bytes in version 3.00a might have had a similar impact to the change to 'unlimited' length strings in v6.
It's true that version 6 breaks new ground in removing an existing feature: the support for legacy 40-bit float variables. However they were provided only to allow BB4W to run on a PC without a Floating Point Coprocessor - and even Windows 98 requires an FPU anyway. It's also the first time an upgrade has unavoidably increased the memory usage of programs, which is why I'm increasing the default setting of HIMEM (the trial version of v6 has 32K of memory available).
So I don't think you can have it both ways. If you favour backwards compatibility your vote should be for v5.95a, if you favour evolution it should be for v6.00a.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #25 on: Nov 20th, 2013, 10:43am » |
|
I think I've come up with a workable, if somewhat off-the-wall, solution to the version 5/6 dilemma. My proposal is that I should release both v5.95a and v6.00a, but consecutively (with a gap of perhaps a month or two).
That way I will never need to support two versions in parallel, because when v6.00a is released it will replace v5.95a as the 'current' version. But it will provide a 'window of opportunity' for those (hopefully few) people who prefer to stick with v5 to do so. When v6.00a is released they can simply choose not to upgrade.
That does of course mean that once v6.00a is released they will strictly be using an unsupported version, but in practice I don't see that as a major issue, especially given that the v5.95a interpreter is virtually unchanged from v5.94a.
If anybody thinks this is a bad idea I can virtually guarantee that I will choose the do-nothing option (stick with v5.94a indefinitely).
Richard.
|
|
Logged
|
|
|
|
Edja
Developer
member is offline
Posts: 60
|
|
Re: A History Lesson
« Reply #26 on: Nov 20th, 2013, 3:01pm » |
|
on Nov 20th, 2013, 10:43am, Richard Russell wrote:| My proposal is that I should release both v5.95a and v6.00a, but consecutively (with a gap of perhaps a month or two). |
|
Alea iacta est.
Excellent proposal.
Eddy
|
|
Logged
|
|
|
|
Richey
New Member
member is offline
Gender:
Posts: 35
|
|
Re: A History Lesson
« Reply #27 on: Nov 20th, 2013, 9:23pm » |
|
I think this is a good idea and should meet everyone's needs and wants...
|
|
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: A History Lesson
« Reply #28 on: Nov 21st, 2013, 06:41am » |
|
Can you tell us which operations will be slower, please? Also, you mention that upgrading programs may be required. What will be necessary for this upgrading? An extra line or two of code or a complete rewrite or what?
Thanks
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #29 on: Nov 21st, 2013, 08:34am » |
|
on Nov 21st, 2013, 06:41am, KenDown wrote:| Can you tell us which operations will be slower, please? |
|
Not really, I've not attempted to find out. To put it into perspective, I would expect the speed of floating-point arithmetic operations to be somewhere between what it is currently in *FLOAT40 mode and *FLOAT64 mode.
Running this trivial program:
Code: TIME = 0 : FOR C% =1 TO 10000000 : A = PI*PI : NEXT : PRINT TIME
gave the following results:
v5.94a (FLOAT40): 131 cs
v6.00a: 147 cs
v5.94a (FLOAT64): 160 cs
If you are particularly interested in how the speed of your own programs will be affected, try them yourself (using BB4W_v6.bas).
Quote:| Also, you mention that upgrading programs may be required. What will be necessary for this upgrading? |
|
I discussed that in this post. The most common cause of incompatibility, I would guess, will be programs that assume that a suffixless variant, in a program running in *FLOAT64 mode, is a 64-bit double (e.g. passing it as such to an API function). In v6 you would need to add an explicit hash (#) suffix to every occurrence of that variable in the program.
A simpler answer to your question is probably: 'if you need to ask, it's unlikely that any of your programs will be affected'!
Richard.
|
|
Logged
|
|
|
|
|
