Modules. What are they!?

[skywalk]

@Fred
~...
I'd rather wait a year or two between releases, and know that the beta release was fairly stable, than see sloppy code released every few months for users to beta test.

Please rethink this statement. Beta is beta for a reason. I prefer to see the releases early and often. This way users help find problems and in some cases shape the development with comments/reactions on new features. After a year there would STILL be bugs to go with the extra documentation.
For production code, use the stable releases. I do.
I know from your posts you have invested heavily in Macros and preprocessors. So have I. At this point, Modules present absolutely no benefit to me and actually require heavy lifting to use them without bugs in both logic and naming.
I've mentioned it before, but my wishes for Modules would have been file based.
Then, IncludeModule "xxx.pb"
Within the Module, NO unnecessary Declares.
All items would default to local or private.
Only those items specified with a Public prefix would be available externally.

[c4s]

[...] helper functions and macros like min(), max(), LOWORD(), HIWORD(), etc. for every module or make at least one copy into a "global module", to use such functions within modules and outside modules as ordinary functions/macros.

Somehow I think accessing the global namespace from within modules could be useful sometimes. Maybe with "Global::", "PB::", or just anonymous "::" prefix.

I have a large archive of include files too, containing general procedures and macros that do not necessarily have to be in modules. Being forced to put them into a module just to be able to use them inside another module isn't very convenient. I vote for a global namespace as well! +1

@Fred
~...
I'd rather wait a year or two between releases, and know that the beta release was fairly stable, than see sloppy code released every few months for users to beta test.

Please rethink this statement. Beta is beta for a reason. I prefer to see the releases early and often. This way users help find problems and in some cases shape the development with comments/reactions on new features. [...]

Yes, I totally agree. Sounds like BorisTheOld either missed that PB5.20 currently is in beta state or misunderstood how beta versions are handled here?!

[Tenaja]

Exactly. The whole definition of "beta" is "Not ready for production", and joining the test group is entirely optional. Boris, if you do not want to be a beta tester, then
do not download the betas!

Definition: http://wordnetweb.princeton.edu/perl/we ... a+software

"beta software is usually available only to particular users who will test it"

I, personally, did not download 5.20 b1...I was too busy to test it, and I saw there were enough changes that I needed to wait for another release or two. Once the bug posts slowed down, I started testing it, but I did not "switch" to 5.2 until b6.

Fred's model makes perfect sense; I'm sure he does not post code with known bugs (at least not bad ones), and he gets the updates out to experience a large testing group. This reveals bugs more quickly than him trying to develop all of the test metrics himself, which in turn allows him to focus on fine tuning the libraries for a quicker release.

edit...

...I'm getting very nervous about PB. This latest release has been very buggy and gives the impression that it was thrown together without being well thought out. I'd rather wait a year or two between releases, and know that the beta release was fairly stable, than see sloppy code released every few months for users to beta test.

And Boris, please remember that adding modules is a whole new scope for PB; it has been quite a while since he made such a monumental change. From what I can tell, most of the changes since 4.0 have been minor compared to 5.2, and primarily new libraries...and adding new libraries does not typically touch older libraries or old parsing tasks, like the new module can.

[Fred]

I'm getting very nervous about PB. This latest release has been very buggy and gives the impression that it was thrown together without being well thought out. I'd rather wait a year or two between releases, and know that the beta release was fairly stable, than see sloppy code released every few months for users to beta test.

Are you talking about 5.11 or 5.20 ? If it's 5.20, it's in beta for a reason: it's still bugged. Large scale testing is required for a product like PB, so everyone who can use the beta and report bugs will help the whole community. It's indeed not mandatory if you don't have the time or are not interested immediately in the new features. Usually, final release are stable enough, and if not they are quickly patched to include prioritary bug fixes, so I don't see why you should get nervous here.

[BorisTheOld]

I'm fully aware of the purpose of beta testing.

It's original purpose was the final field testing of the release version of software. At one time, software developers had entire divisions dedicated to stress testing the final release candidate. A product did not enter the beta test phase until all the documentation and software was complete and conformed to the design specifications. The expectation was always that no problems should be found.

As a software developer, I would be ashamed of putting software into beta testing if I did not believe that it was fully documented and working to the best of my abilities.

I'm disappointed that so many people on these forums seem to have such low expectations. Programming is not rocket science. Even a novice programmer should be able to write bug free code. All it takes is attention to detail and the willingness to do a good job.

[Fred]

Even if it's not "rocket science" (well rockets are now guided by computers so.. ), writing bug free code isn't as easy as you seem to think, especially when the program is complex and has a large audience. And, no I can tell the difference between a novice, an average and good coder. You will have to trust me on that, but I think you already knew as your answer was rather rethorical.

We don't document it for the first beta version because it still can change (and often change). We just don't have the man power to write a doc specifically for the beta, and then rewrite it for the final. We write small examples which often are enough to get a grip on the new features (and you are free to ask if not enough).

[User_Russian]

BorisTheOld, you are not forced to participate in the beta-testing.
Do not download beta-version. Wait for the release and download the stable version of PB with updated documentation.
And do not offer release PB once a year, or even less often!

[BorisTheOld]

.... writing bug free code isn't as easy as you seem to think, especially when the program is complex and has a large audience........We don't document it for the first beta version because it still can change (and often change). We just don't have the man power to write a doc specifically for the beta, and then rewrite it for the final....

That's my point. Complex bug-free code requires time to plan and implement, and shouldn't be released to Beta testers until everything is finalized. I understand the manpower situation, but it seems to me that if things are still changing then the software is in Alpha test and shouldn't be released for Beta testing.

BorisTheOld, you are not forced to participate in the beta-testing.

I choose to participate so that I can offer my sage advice and help with PB's development. However, I reserve the right to be critical. It's no favour to Fred if we all blindly accept what he gives us, instead of offering our thoughts on how things might be improved.

[skywalk]

Boris, I appreciate everyone's insight, but the difference between Alpha and Beta is all relative.
And is it constructive criticism to simply ask someone to do better?
Like, "don't release Alpha code until it's Beta worthy".

[TI-994A]

Hello BorisTheOld. I'm sure that your input is valued and appreciated by the team. By the same virtue, I also think that they deserve our respect and appreciation as well. Like you said, people have their own ways of doing things, and in the end, the Fantaisie team always delivers.