Every one, Every where, All ways, You too. That's what professional
conferences and scientific education is for. Who do you think you're
talking to, the mailing list archive readers of a social club for
knitting for the elderly? That is correct too. Time will and does
demonstrate it perfectly.
On 9/25/23, Rudolf Leitgeb <Rudolf.Leitgeb@gmx.at> wrote:
> Are you trying to teach the OpenBSD devs how to write good software?
>
> Unix software?
>
> Really?
>
> REALLY ?????
>
> On Mon, 2023-09-25 at 21:11 +0000, Eponymous Pseudonym wrote:
>> Standardisation, specification and documentation as a starting point
>> for software creation is a normal, reliable and mandated (formally)
>> methodology used everywhere from business to scientific, industrial,
>> medical and military applications. It is not only normal but
>> expected
>> and even required that amateur free and open software follow the same
>> processes and procedures as professional modelling and
>> implementation,
>> especially on historically significant long term projects that are
>> also programming languages and interpreters.
>>
>> It's not a surprise to you, everything in UNIX is a compiler
>> construction reuse tooling and a small (and large) domain specific
>> languages. That is the essence of the system. OpenBSD is a
>> descendant of UNIX, not a free walk in the green pastures of
>> experimental shareware. Now, let's get back to more productive time
>> and space utilisation, kids, good ideas.. third party re-imports are
>> waiting their normalisation and stabilisation to robust and reliable
>> distillations of core "base and extended" system modular componentry.
>> Re-read the long version of the previous post after some specialised
>> references again, and you will see and understand what I outlined
>> clearly.
>>
https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text
https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History
https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles
>>
>> Thanks for the discussion and support, I've said my points and think
>> we're in accord and agreement on all details referenced.
>>
>> On 9/25/23, Rudolf Leitgeb <Rudolf.Leitgeb@gmx.at> wrote:
>> > If you document a switch, you are basically required to keep that
>> > functionality around forever. Given that the OpenBSD devs don't
>> > like
>> > these --options all that much, I don't see that happening.
>> > Submitting
>> > a patch won't change that.
>> >
>> > IMHO there's nothing wrong, if software can do more than its
>> > documentation shows. It's not like it breaks documented behavior.
>> >
>> > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote:
>> > > Don't rant that long.
>> > >
>> > > Sometimes, documentation and code get out-of-synch for a lot of
>> > > reasons.
>> > >
>> > > - trying out stuff and documenting later.
>> > > - plain forgetting to update the documentation.
>> > > - having some stuff for a transition period, and then killing it.
>> > >
>> > > Your point that stuff that stays around, should ideally be
>> > > documented,
>> > > is a good point.
>> > >
>> > > Now, you gotta realize that people have limited time to do
>> > > everything.
>> > >
>> > > In general, patches are welcome.
>> > >
>> > > In my long tenure on various tools, I've learnt that documenting
>> > > stuff is always always a good idea: if you get a new feature BUT
>> > > you can't explain it cleanly, then you should go back to the
>> > > drawing-board !
No comments:
Post a Comment