The reason I stated that was due to the fact that with the conversion
process from the old legacy coding languages to Python [and such] many
of the bugs are tracked down and removed. Also, that helps remove
coding conflicts that might arise as the new fixes and features are
added to the code base.
Sure, I started out as a mainframe programmer using COBOL, FORTRAN, and
a bunch of others. They were good languages. Then more "modern" ones
were created that had more procedures and function built in, so the
programmer did not have to try and code these "functions"
himself/herself. The Object Oriented Programming came into being and
changed the way programmers needed to think and create their programs
using "objects" of code blocks that were reusable.
Now, the current crop of programmers are taught OOP as the standard and
the programming languages got better and better.
As far as I am concerned, OOP coding is easer to use and debug [most
times] than the way I had to do things back in my early programming work.
As for bug testing and avoiding, yes analysis and practice is a key to
any successful programmer and program package. BUT, the people who test
out LO to find bugs may not find them all. Many of them are detected by
the users with specific needs and specific usage of LO. I know I found
a problem with one model of printer, and other have also with theirs.
The RC bug testers do not have access to all of these different
printers, OS versions, and the specific user setups that found the bug
in the first place.
We all are human and therefor not perfect users and programmers. One
misplaced "nil" character where a "space" should be, or some other thing
that is very hard to find, could really cause problems "down the line"
with bugs that do not seem to be fixable or error messages that do not
make sense. I had a single "nil" character problem that "bugged" me and
my co-workers for weeks in a PASCAL language program.
As for Windows XP being "dumped" by MS when maybe half of the world
still use it and infrastructure is running it and would need a major
overhaul to work with Win7 or 8.x, well people will say why did they not
do it already. Others would reply - it works well so why fool with it.
Then there are the "Windows is the best computer OS out there" statement
when most of the Internet is based on Linux technology computers and
other "devices" since it is the most stable platform for such
"communication" infrastructure. The Os that is overtaking the PC
market, that some people say is killing the PC market, is Android which
is a Linux-based OS.
Then there are all these articles I have seen that tell XP users to
switch to Linux Mint if you do not want to go to Win7 or 8.x, or there
systems "too old and slow" to use those "modern" Windows operating
systems. I have a guy who never heard of Linux ask me to convert his
old HP system to Linux Mint [with MATE] since he read an article
somewhere telling him that was the way to go. I am loaning him an
old/slow system with Mint on it so he can play with it to see if he
would want to really switch or should I add more ram and such to "help"
his system be able to use Win7.
We all have out "pet peeves" about programming languages, bug control,
which OS is the best for who, which software is best for what, etc.,
etc.. I have seen good programs turn towards bad, and bad programs turn
around and be good ones to use. I saw GIMP change its "save" options so
you can no longer "save" formats like JPG and PNG, so not you have to
use a different option to "export to" these standard formats, instead of
saving to their "proprietary formats".
I moved from MS Office to OpenOffice.org, to LibreOffice [spring 2010],
and seen LO become the best FOSS alternatives to MSO, while MSO keeps
messing around with their menu systems and not making their .docx files
backward compatible with their older version of MSO.
On 04/10/2014 11:46 AM, CVAlkan wrote:
So sorry if my comments were misinterpreted - Tom's is one of the few names
that I recognize so I know he's on board.
I am concerned, however, with your suggestion that "modern languages" reduce
bugs. They might make it easier to avoid bugs, or make it easier to spot
bugs, but the only thing that will reduce bugs is analysis, practice,
analysis, practice and more analysis.
Sorry if that seems cynical, but the great Admiral Grace Hopper and her
team, for instance, introduced the idea of subroutines back in the early
1950s in order to help reduce bugs - we later migrated from subroutines to
object libraries and a wide variety of other approaches. The point is not
that these aren't welcome improvements and all, but I think we tend to
depend way too much on the tools/languages/whatever than they deserve
(however good they may be).
The other thing I alluded to was the sheer magnitude of creating any sort of
regression testing suite for something like LO (to say nothing of the space
shuttle or your ATM machines that are mostly running on Windows XP). Having
"users" beat on the product is certainly helpful as well, but certainly not
a comprehensive form of testing or validation.
I certainly wasn't suggesting or implying that Word (for instance) hasn't
addressed some bugs that have been present in their product for over a
decade. One reason I like LO is simply that someone seems to be listening -
a necessary (however insufficient) condition for improving things.
--
View this message in context:
http://nabble.documentfoundation.org/Possible-LibreOffice-Duplex-Printing-Bug-tp4104713p4104812.html
Sent from the Users mailing list archive at Nabble.com.
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.