Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #11138 > unrolled thread

Algol 68 / Genie - opinions on local procedures?

Back to article view | Back to comp.lang.misc

Contents

  Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 04:52 +0200
    Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-18 16:54 +0100
      Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 18:30 +0200
        Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-19 00:45 +0100
          Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-19 02:44 +0200
            Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 00:47 +0100
              Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-20 00:43 +0000
                Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 23:58 +0100
                  Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-21 02:59 +0000
                    Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-23 00:42 +0100
                      Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 02:29 +0200
                      Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-23 02:36 +0000
                  Economizing resource requirements (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-21 21:02 +0200
                  Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-04 01:11 +0000
                    Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 03:37 +0000
                    Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-07 22:03 +0100
                      Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-07 22:04 +0000
                        Various digressions (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:27 +0200
                        Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-10 01:11 +0100
                          Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-10 01:39 +0000
                            Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-11 12:47 +0100
                      Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-08 17:04 +0000
            simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-26 18:42 +0000
              Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-27 00:28 +0000
                Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:10 +0000
                  Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:43 +0000
                    [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:50 +0000
                      Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-05 00:03 +0000
                        Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 15:55 +0000
                          Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-07 21:17 +0000
                      Re: [OT] NetBSD vs. Linux(-based systems) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-09-05 12:02 +0000
                        Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 16:30 +0000
              Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-27 07:53 +0200
                Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:39 +0000
                  Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:45 +0000
                    Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-31 13:35 +0000
                      Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:40 +0000
                        [OT] free software Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:25 +0000
                    Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-08 14:03 +0000
                      Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:21 +0200
                        Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 08:08 -0700
                          Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:18 +0000
                            Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 14:31 -0700
                              Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 00:09 +0000
                                Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 08:44 -0700
                                  Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 21:52 +0000
                                    Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 15:21 -0700
                        Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 00:34 +0000
                          Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 03:48 +0200
                      Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 01:39 +0000
                        Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 04:00 +0200
                          Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 14:19 +0000
                            Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:09 +0200
                            Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:36 +0200
                  Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:32 +0200
                  Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:34 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#11369 — Re: simplicity / complexity

On Wed, 8 Oct 2025 16:21:50 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> A principal advantage of the "open-source world" (or rather the non-
> commercial world) is that there's neither competition nor need to
> quickly throw things into the market. So this area has at least the
> chance to adapt plans and contents without time pressure.

Yes and no. There's definitely *less* pressure to make a specific
release window and a project won't necessarily die just because there's
no money in it - but large-scale open-source projects do compete for
"mindshare" among open-source developers, who are a large but finite
group with a finite amount of time and energy to sink into them.

[toc] | [prev] | [next] | [standalone]

#11376 — Re: simplicity / complexity

On Wed, 8 Oct 2025 08:08:22 -0700, John Ames wrote:

> ... large-scale open-source projects do compete for
> "mindshare" among open-source developers, who are a large but finite
> group with a finite amount of time and energy to sink into them.

The “mindshare” is among the passive users who take what’s given and 
complain about how it doesn’t fit their needs.

What’s more important is the “contribushare” -- the active community that 
contributes to the project. That matters much more than sheer numbers of 
users.

[toc] | [prev] | [next] | [standalone]

#11378 — Re: simplicity / complexity

On Wed, 8 Oct 2025 21:18:58 -0000 (UTC)
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> > ... large-scale open-source projects do compete for
> > "mindshare" among open-source developers, who are a large but finite
> > group with a finite amount of time and energy to sink into them.  
> 
> The “mindshare” is among the passive users who take what’s given and 
> complain about how it doesn’t fit their needs.
> 
> What’s more important is the “contribushare” -- the active community
> that contributes to the project. That matters much more than sheer
> numbers of users.

If that's the terminology you prefer, sure. The point stands.

[toc] | [prev] | [next] | [standalone]

#11385 — Re: simplicity / complexity

On Wed, 8 Oct 2025 14:31:31 -0700, John Ames wrote:

> On Wed, 8 Oct 2025 21:18:58 -0000 (UTC)
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> 
>>> ... large-scale open-source projects do compete for "mindshare" among
>>> open-source developers, who are a large but finite group with a
>>> finite amount of time and energy to sink into them.
>> 
>> The “mindshare” is among the passive users who take what’s given and
>> complain about how it doesn’t fit their needs.
>> 
>> What’s more important is the “contribushare” -- the active community
>> that contributes to the project. That matters much more than sheer
>> numbers of users.
> 
> If that's the terminology you prefer, sure. The point stands.

You were talking about thinking, not doing. It’s the doing that counts.

[toc] | [prev] | [next] | [standalone]

#11398 — Re: simplicity / complexity

On Thu, 9 Oct 2025 00:09:50 -0000 (UTC)
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> > If that's the terminology you prefer, sure. The point stands.  
> 
> You were talking about thinking, not doing. It’s the doing that
> counts.

I was talking about the doing; you just want to use a different word
for it. That's all fine, but it doesn't change what I was saying.

[toc] | [prev] | [next] | [standalone]

#11401 — Re: simplicity / complexity

On Thu, 9 Oct 2025 08:44:31 -0700, John Ames wrote:

> On Thu, 9 Oct 2025 00:09:50 -0000 (UTC)
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> 
>>> If that's the terminology you prefer, sure. The point stands.
>> 
>> You were talking about thinking, not doing. It’s the doing that counts.
> 
> I was talking about the doing ...

You used the word “mindshare”. Trying to redefine what “mind” means, now?

[toc] | [prev] | [next] | [standalone]

#11402 — Re: simplicity / complexity

On Thu, 9 Oct 2025 21:52:08 -0000 (UTC)
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> >>> If that's the terminology you prefer, sure. The point stands.  
> >> 
> >> You were talking about thinking, not doing. It’s the doing that
> >> counts.  
> > 
> > I was talking about the doing ...  
> 
> You used the word “mindshare”. Trying to redefine what “mind” means,
> now?

No, just using it in the context of developer minds.

[toc] | [prev] | [next] | [standalone]

#11386 — Re: simplicity / complexity

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 08.10.2025 16:03, Waldek Hebisch wrote:
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>> On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:
>>>
>>>> Not to mention that taking too long to 'polish' your product, you
>>>> risk ending up lagging behind your competitors.
>>>
>>> I would say, the open-source world is a counterexample to this. Look at 
>>> how long it took GNU and Linux to end up dominating the entire computing 
>>> landscape -- it didn’t happen overnight.
>> 
>> Actually, open source nicely illustates this.  First advice to
>> open source projects is "release early, release often".  Projects
>> that delay release because they are "not ready" typically loose
>> and eventually die.
>> 
>> Open source projects typically want to offer high quality.  But
>> they have to limit their efforts to meet realease schedules.
>> There are compromises which know bugs get fixed: some are deemed
>> serious enough to block new release, but a lot get shipped.
>> There is internal testing, but significant part of problems
>> get discovered only after release.
>> 
>> One can significantly increase quality by limiting addition of
>> new featurs.  But open source projects that try to do this
>> typically loose.
> 
> We can observe that software grows, and grows rank. My experience
> is that it makes sense to plan and occasionally add refactoring
> cycles in these cases. (There's also software planned accurately
> from the beginning, software that changes less, and is only used
> for its fixed designed purpose. But we're not speaking about that
> here.) A principal advantage of the "open-source world" (or rather
> the non-commercial world) is that there's neither competition nor
> need to quickly throw things into the market. So this area has at
> least the chance to adapt plans and contents without time pressure.

What you wrote corresponds to one-man hobby project.  There is a lot
of such projects.  But more important is software from multiperson
project.  And by now a lot of open source is developed by paid
developers in commerial setting.  Note that GPL requires that
distributor makes code available to recipents of binaries.
So comercial entity improving GPL-ed program has to open-source
the improvements.  Given that they can not keep improvements
secret there is incentive to conribute them back to original
project: if improvements are integrated maintanence on contributor
side gets easier.  But this calculation breaks down if original
source keeps intermediate code secret and rarely is doing
releases.  Even if developement tree is public and contributions
are promptly integrated rare releases means that users wanting
improvement must use potentially unstable developement versions.

Sometimes comercial entities want to ship some product which
makes use of some system tool installed on user system.  They
may need improvement to this tool and for them things get
easier if improved tool quickly enters distribution.

Coming back to hobby case, one reason people contribute is
because thay want some extra feature, they develop it and
wnat it included.

All 3 cases above have common factor: contributor really want
feature included in the program.  If maintainer/lead developer
rejects the code or introduces large delay, then potential
contributors are discouraged, so project may loose developers
(or at least fail to gain new ones).

There is also question of popularity among users.  While by
definition "ordirnary users" do not contribute code, they
report bugs, ask for enhancemts, sometimes help with documentation,
project website or simply spead positive opinion about project.
This is important too: without good documentaion potential
users may consider program to be buggy, without user contributed
bug reports discovering (and hence fixing) bugs may be hard,
without user feedback developers may concentrate on wrong features.

And of course, to join a project developers must first realize
that the project exists and get interested in it.

> Whether it's done is another question (and project specific). It
> should also be mentioned that some projects have e.g. security or
> quality requirements that gets tested and measured and require some
> adaptive process to increase these factors (without adding anything
> new).

Actually, security is another thing which puts pressure to
release quickly: if there is security problem developers want
to distribute fixed version as soon as possible. 

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#11388 — Re: simplicity / complexity

On 09.10.2025 02:34, Waldek Hebisch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
[...]
>> We can observe that software grows, and grows rank. My experience
>> is that it makes sense to plan and occasionally add refactoring
>> cycles in these cases. (There's also software planned accurately
>> from the beginning, software that changes less, and is only used
>> for its fixed designed purpose. But we're not speaking about that
>> here.) A principal advantage of the "open-source world" (or rather
>> the non-commercial world) is that there's neither competition nor
>> need to quickly throw things into the market. So this area has at
>> least the chance to adapt plans and contents without time pressure.
> 
> What you wrote corresponds to one-man hobby project. [...]

No. (I wasn't speaking about "one-man hobby projects"; rather more
the "opposite" project setup.)

> [...] But more important is software from multiperson project. [...]

Yes.

> [ open source and GPL stuff ]

I wasn't specifically speaking about that.

> [ specific sceneries and assumptions ]
>
> [ more open source specific sceneries and assumptions ]
>
> [ open source example sceneries and assumptions about involved people ]

(I wasn't focusing on these things you expanded on. - And I won't
comment on that.)

> 
>> Whether it's done is another question (and project specific). It
>> should also be mentioned that some projects have e.g. security or
>> quality requirements that gets tested and measured and require some
>> adaptive process to increase these factors (without adding anything
>> new).
> 
> Actually, security is another thing which puts pressure to
> release quickly: if there is security problem developers want
> to distribute fixed version as soon as possible. 

Yes, but I wasn't speaking about fixing security holes [quickly].

I was speaking about planning a software in a development process
with requirements including security and principles to guarantee
quality. That doesn't prevent measures to continuously get back
in feedback loops to enhance the structure, plan growth, redesign
and refactor necessary parts, especially when new features are
planned to be added.

And I was speaking about software that obviously doesn't adhere
to such principles, and grow rank.

The point with open source software (where you seem to have a bias
for) is a special set of beasts. But as said; they'd have a chance
(but typically and often don't use it, it seems).

Janis

[toc] | [prev] | [next] | [standalone]

#11387 — Re: simplicity / complexity

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> antispam@fricas.org (Waldek Hebisch) wrote or quoted:
>>Actually, open source nicely illustates this.  First advice to
>>open source projects is "release early, release often". 
> 
>   I had thought about using this for my projects, but I can see
>   the downsides too:
> 
>   If some projects drop too early, they still barely have any
>   capabilities. The first curious potential users check it out and
>   walk away thinking, "a toy product and not the skills that actually
>   matter in practice". That vibe can stick around - "You don't get
>   a second shot at a first impression." - and end up keeping people
>   from giving the later, more capable versions a chance.

You need to manage expectations.  Yours and your users.  You may
think that you have some cool thing, but even if it is working
well in your opinion first potential user to come may trash it
and discourage others.  Or you may hit into something that a lot
of people want, but is not handled by existing software.  Then
even if buggy/imperfect program may easily gain a lot of users.

If you decide to distribute some early not entirely finished version
it makes sense to explicitely say alpha/beta/for developers only
as appropriate.

Unless your program is close to trivial and you spent a lot of
effort to make it correct expect that if you get users they
will discover bugs.

A lot depends how you view your project.  If it is something
that you want to "give" to users and expect good words in
return, you may be disappointed.  AFAICS potential benefits
of distributing code are:
- you get bug reports or enhancement ideas allowing you to
  improve the program
- you get contributions, so part of work is done by others

OTOH:
- contributors may want to take project in quite different
  direction that you want
- you may get spurious bug reports, where program works as
  designed, but user expected soemting else
- you may get harsh critique

If you feel that what you have is too immature, then it makes
sense to keep it private.  Similarly, you want things
designed/impemented in specific way it is best to do it
in private.

But IMO in most cases releasing early makes sense.

>>Projects that delay release because they are "not ready"
>>typically loose and eventually die.
> 
>   Exagerated. 
> 
>   The actual TeX program version is currently at 3.141592653
>   and was last updated in 2021. It is one of the most successful
>   programs ever and the market leader for scientific articles
>   and books that include math formulas.
 
I am well aware of TeX and I would interpret things in rather
different way.  First, main selling point of TeX proper is
backwards compatibility, that is rendering old papers now
in the same way as when they were written and hopefully current
paper in the future will be rendered the same as now.  While
compatibility in general is good, in case of scientific articles
it is especially important.

Second, despite first point there is continuing dissatisfaction
that TeX proper misses various features.  Some things get
added but are not reflected in official version number, there are
mutated versions and attempts to created rather different
thing (like Lyx and Texmacs).  There was a faild attempt
(or possibly multiple attempts) at developing compatible
replacement.

Third, TeX is a macro processor and a lot of formatting functionality
in use is implemented via TeX macros and not in TeX proper.
There is rather fast stream of changes to available macro
packages and a lot of bloat there.  TeX proper is about 24kloc
of source code after macro expansion.  Modern binaries contain
similar (or somewhat larger) amout of "system support", which
orignally was intended to be rather small wrapper around needed
OS functions but now adds extra functionalty (not reflected in
main version number).  If you install supporting macro packages
and extra tools  like Debian 'texlive-full' package they will use
about 9 GB.

So TeX is very special case: there is strong compatibility
requirement and there is a lot of changes outside core part
written by Knuth.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#11389 — Re: simplicity / complexity

On 09.10.2025 03:39, Waldek Hebisch wrote:
> [...]
> 
> But IMO in most cases releasing early makes sense.

LOL, yeah! - Let the users and customers search the bugs for you!

Janis

[toc] | [prev] | [next] | [standalone]

#11394 — Re: simplicity / complexity

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 09.10.2025 03:39, Waldek Hebisch wrote:
>> [...]
>> 
>> But IMO in most cases releasing early makes sense.
> 
> LOL, yeah! - Let the users and customers search the bugs for you!

Maybe you think that you can write perfect software.  There are
widely available statistics which show that software of nontrivial
size have bugs.  Developer may plan things (FYI I spent a lot
of time on planning befor I start coding), test things but after
some time arrives at point of diminishing returns: finding new
bugs takes a lot of effort.  If you have paying customers you should
have money a hire testers.  You should hire multiple developers
and do code reviews.  But within reasonable resource bounds and
using known tecniques you will arrive at point where finding new
bugs takes too much resources.

If your customers need/demand higher quality they should pay
appropriatly to cover needed cost.  But expecting no bugs is
simply unrealistic.  I read about developement of software
controlling Space Shuttle.  Team doing that boasted that
that have sophisticated developement process ensuring high
quality.  They had 400 people working on 400 kloc program.
Given that developement was spread over more than 10 years
that looks as very low "productivity", that pretty high
developement cost.  Yet they where not able to say "no bugs".
IIRC they where not even able to say "no bugs discovered
during actual mission", all that they were able to say
was "no serious trouble due to bugs".  Potential effects
of failure of Space Shuttle software were pretty serious,
so it was fully justified to spent substantial effort on
quality.

What I develop is quite non-critical, I am almost certain
that "no serious trouble due to bugs" will be true even if
my software is full of bugs.  And similar thing applies to
substantial part of open source software.  I wrote above
about hiring testers.  Non commercial open source projects
typically do not have money to pay for testing.  But
there are people who are willing to do testing for free.
More precisely, given not critical nature of software
bugs are just inconvenience and frequently there are
folks who consider inconvenience due to bugs as small
compared to benefits offered by software.

When I wrote about releasing early, I mean releasing when
stream of new bugs goes down, that is attempting to predict
point of diminishing returns.  More conservative approach
would continue testing for longer time in hope of finding
"last bug".  Some people may use formulation like "do
all what it possible to increase quality and after that
release", but there is always something more that could
be done.  So one need to decide when it is enough and release.

I have a problem (and tone of your message suggest that you
may have this problem too), I really would prefer to catch as many
bugs as possible during developement and due to this I
probably release to late.  Note that part of my testing may
be using a program just to do some work.  Now, if program
is doing valuable service to me, there is reasoble chance
that it will do valuable work for some other people.
Pragmatically you can view this a a deal: other people
get value from work done by the program, I in exchange get
defect reports that allow me to improve the program.
I see nothing wrong in such a deal, as long as it is
honest, in particular when provider of the program
realistically states what program can do.

BTW: Some users judge quality of software looking at number of
bugs reports.  More bugs reports is supposed to mean higher
quality.  If that looks wrong to you more detailed reasoning
goes as follows: number of bug reports grows with number of
users.  If there is small number of bug reports it indicates
that there is small number of user and possibly that users
do not bother reporting bugs.  Now, user do not report bugs
when they consider software to be hoplessy bad.  And user
in general prefer higher quality software, so small number
of user suggest low quality.  So, either way, low number
of bug reports really may mean low quality.  This method
may fail if you manage to create perfect software free of
bugs with perfect documentation so that there will be no
spurious bug reports.  But in real life program tend to have
enough bugs that this method has at least some merit.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#11405 — Re: simplicity / complexity

On 09.10.2025 16:19, Waldek Hebisch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 09.10.2025 03:39, Waldek Hebisch wrote:
>>> [...]
>>>
>>> But IMO in most cases releasing early makes sense.
>>
>> LOL, yeah! - Let the users and customers search the bugs for you!
> 
> Maybe you think that you can write perfect software. 

No. (What makes you think that I would think that one could be
sure to write [non-trivial] software error-free and perfect?)

But there are methods to write more reliably reliable software!

Also, that software has more or less bugs doesn't justify, IMO,
"early releases" as principle, and especially not as principle
to obtain software quality; this was the inherent point of the
statements in previous posts.

> [...]  But within reasonable resource bounds and
> using known tecniques you will arrive at point where finding new
> bugs takes too much resources.

And this is also no rationale for "early releases".

> 
> If your customers need/demand higher quality they should pay
> appropriatly to cover needed cost.  But expecting no bugs is
> simply unrealistic. 

This is again the same straw-man; no one said or implied such
a thing.

> I read about developement of software
> controlling Space Shuttle.  Team doing that boasted that
> that have sophisticated developement process ensuring high
> quality.  They had 400 people working on 400 kloc program.
> Given that developement was spread over more than 10 years
> that looks as very low "productivity", that pretty high
> developement cost.  Yet they where not able to say "no bugs".
> IIRC they where not even able to say "no bugs discovered
> during actual mission", all that they were able to say
> was "no serious trouble due to bugs".  Potential effects
> of failure of Space Shuttle software were pretty serious,
> so it was fully justified to spent substantial effort on
> quality.

And sometimes it doesn't help if the methods aren't applied
consequently! (Since you mentioned a space technology example
you may want to read about the Ariane 5 incident; the
post-mortem report is very enlightening concerning errors in
demanding software projects that are basically extremely good
organized!)

> 
> What I develop is quite non-critical, I am almost certain
> that "no serious trouble due to bugs" will be true even if
> my software is full of bugs. [...]

I've no insight in your projects and methods. (That's not my
business.)

From the professional projects I participated in in the past
we could not risk having lots of bugs or severe bugs. So we
either had or installed the necessary methods and provisions
to achieve the high quality we needed; and that worked well.

So probably you have other projects in mind; but even then,
the costs for fixes of problems appearing later are much
higher than detecting them early in the development process.
(In your area maybe "only" loss of reputation, not money, or
lives.)

> 
> When I wrote about releasing early, I mean releasing when
> stream of new bugs goes down, that is attempting to predict
> point of diminishing returns. 

The problem with that is that bugs - assuming we speak about
those reported; mind your "early release" approach! - appear
too late to be fixed cheaply. (And predictions need numbers
and project context information! And experience.)

> More conservative approach
> would continue testing for longer time in hope of finding
> "last bug". [...]

That is not a "conservative approach" but nonsense, and I've
never heard such procedure to be established in professional
contexts; unless you could apply a formal verifier you cannot
say when there's no bugs any more.

No. Conservative, or standard approach, is to apply all the
methods of software development, from formal specification,
tools testing specifications, designs, tests on the various
levels, supporting tools, experts on the respective QA and
project management tasks, and of course trained programmers.

> 
> I have a problem (and tone of your message suggest that you
> may have this problem too), I really would prefer to catch as many
> bugs as possible during developement and due to this I
> probably release to late. [...]

Yes, I try to reduce the cases where bugs may slip in. For my
personal toy-projects that's not critical, but if I want to
(sort of) "publish" anything I spend yet more effort. For the
professional projects I was engaged in it was non-negotiable,
though; the quality measures were a must!

> Note that part of my testing may
> be using a program just to do some work.  Now, if program
> is doing valuable service to me, there is reasoble chance
> that it will do valuable work for some other people.
> Pragmatically you can view this a a deal: other people
> get value from work done by the program, I in exchange get
> defect reports that allow me to improve the program.
> I see nothing wrong in such a deal, as long as it is
> honest, in particular when provider of the program
> realistically states what program can do.

Personally I don't want to publish in a quality that results
in a lot of feedback that requires a lot of time to handle.
And it's not only about coding-bugs but also about software
design. (My rants often have a strong focus on "lousy design"
and on bugs only as a secondary factor; my experience tells
me also that lousy designs are also a significant source of
implemented bugs.)

> 
> BTW: Some users judge quality of software looking at number of
> bugs reports.  More bugs reports is supposed to mean higher
> quality. 

More bug reports primarily suggests that the software is of
inferior quality (presuming all other factors for comparison
are equal or appropriately normalized).

> If that looks wrong to you more detailed reasoning
> goes as follows: number of bug reports grows with number of
> users. 

This is not necessarily the case.

> If there is small number of bug reports it indicates
> that there is small number of user and possibly that users
> do not bother reporting bugs. 

This is not a given consequence.

> Now, user do not report bugs
> when they consider software to be hoplessy bad.  And user
> in general prefer higher quality software, so small number
> of user suggest low quality.  So, either way, low number
> of bug reports really may mean low quality.  This method
> may fail if you manage to create perfect software free of
> bugs with perfect documentation so that there will be no
> spurious bug reports.  But in real life program tend to have
> enough bugs that this method has at least some merit.

It is always sensible going for high quality early in the
development process to create less bugs and less bug reports.
Frankly, to say that a lot of bug reports (thus bugs) is good
or useful in any way is completely erroneous. You can draw
quality conclusions also from no or "too few" bugs and focus
on these.

Mind also that fixing bugs often is also "patching" software;
with many bug reports you have to do a lot of changes, in a
way defined by the time scale as they arrive, not by design.
In well-designed and well-written software that may be a
less critical factor, but to achieve that quality state in
the first place you'd have to install some quality measures.

Lots of bugs and bug-reports is nothing you sensibly want to
achieve to obtain software quality.

Though you should track all numbers you can get from your
development process to be able to draw conclusions and act.

Anecdotally, to give an impression of contexts I worked in...

We had a client server component architecture, each component
with one dedicated person responsible for it. We measured the
errors from tests on various levels (unit, system, integration,
acceptance tests). We also measured check-ins, and number of
changes of the requirements (for example). I installed the QA
measures I found to be necessary, and we had the best outcome;
best outcome means quasi-zero bugs!

In another context I took responsibility for a refactoring of
governmental software, software that evolved over years before
I joined. Here the refactoring not only reduced LOCs but also
restructured the code. The number of bugs reduced linearly with
the reduction of code, and yet more with the better structure.
(But of course that needed the QA infrastructure and processes
we had invented, it's not a given.)

PS: You wrote quite some hypotheses about open source and the
user community there; I'm positive that the principles we got
from the commercial professional software development are also
valid for the area you were focusing on. But YMMV, of course.

Janis

[toc] | [prev] | [next] | [standalone]

#11406 — Re: simplicity / complexity

On 09.10.2025 16:48, Stefan Ram wrote:
>   Recommended reading:
> 
> "They Write the Right Stuff" (1996-12) - Charles Fishman.
> [...]
>   The gist is:
> [...]
>   - About half the staff are testers, but as the programmers
>     do not want them to find errors, the programmers already 
>     do their own testing before they give their code to the 
>     actual testers. So more time is spend on testing than on
>     coding.

(It's dangerous to reply on a quoted text. Anyway. A few comments...)

I cannot tell where that is from, what project context, company, etc.
Just hoping that "the programmers" is not meant as generalization but
that it's meant just for the context/company he writes about.

The author write as if there's just one sort of testing, and this done
by ominous "testers". We had (in the various companies) indeed testers
but they were doing component tests, system tests, integration tests,
another group did the acceptance tests, and the programmers/developers
did unit tests and component tests. Each type of tests has its reason
and is important. All added to high quality software.

The quoted last sentence seems to suggest - but I may misinterpret -
that it's bad to spend a sensible time on "testing". In a way it gives
the impression that many LOCs are the "productive" and more important
part of the job, and sadly I got to know stupid managers that believed
such nonsense.

Janis

PS: Whenever QA effort gets reduced it gets expensive, money and lives.
When was it that Boing reduced QA staff and subsequently a couple 737s
crashed? (You can find similar stories from other companies.)

[toc] | [prev] | [next] | [standalone]

#11192 — Re: simplicity / complexity

On 30.08.2025 21:39, Ivan Shmakov wrote:
>>>>>> On 2025-08-27, Janis Papanagnou wrote:
[...]
> 
>  > But even with Browsers and JS activated with my old Firefox I cannot
>  > use or read many websites nowadays; because they demand newer browser
>  > versions.
> 
> 	"Demand" how?

All sorts of "defunct"; from annoying notes telling me to upgrade
my browser (while still seeing content and operating), then that
message with a complete dis-functionality of dynamic content, and/
or mis-formatted (to the degree of being unusable), or there's no
text information at all displayed. And so on.

If there's an issue with pages/services like reddit or sourceforge
or (in the past; they seem to have fixed something) stackoverflow,
or free services (news, weather, tv-program, etc.) I can just skip
and ignore those services. But there's also commercial pages I've
to use (like banks, tax/gov, or free mail providers, etc.) that I
have (or need) to use then I must switch to another system or I'm
out of luck. (Luckily I have systems available to choose from.)

Janis

[toc] | [prev] | [next] | [standalone]

#11193 — Re: simplicity / complexity

On 30.08.2025 21:39, Ivan Shmakov wrote:
> [...]
> 
> 	Not to mention that taking too long to 'polish' your product,
> 	you risk ending up lagging behind your competitors.

It's not "polishing" that I was speaking about.

Janis

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.misc

csiph-web