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 <[email protected]> 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 <[email protected]> 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 !
