Groups | Search | Server Info | Login | Register

Groups > comp.lang.misc > #11387

Re: simplicity / complexity

From antispam@fricas.org (Waldek Hebisch)
Newsgroups comp.lang.misc
Subject Re: simplicity / complexity
Date 2025-10-09 01:39 +0000
Organization To protect and to server
Message-ID <10c73oj$1engi$1@paganini.bofh.team> (permalink)
References (6 earlier) <108m6ft$fkhm$1@dont-email.me> <gl4a18y3Ssi0BNk0@violet.siamics.net> <108vuu7$2sngv$7@dont-email.me> <10c5r04$172ul$1@paganini.bofh.team> <early-20251008154832@ram.dialup.fu-berlin.de>

Show all headers | View raw

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

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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 ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 14:53 +0000
                Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 15:24 +0000
                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 ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 14:48 +0000
                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-10-10 12:09 +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

csiph-web