cm0002@lemmy.world to Programmer Humor@programming.dev · 19 days agoJunior Prompt Engineeringlemmy.mlimagemessage-square46fedilinkarrow-up1221arrow-down11
arrow-up1220arrow-down1imageJunior Prompt Engineeringlemmy.mlcm0002@lemmy.world to Programmer Humor@programming.dev · 19 days agomessage-square46fedilink
minus-squareBjörn Tantau@swg-empire.delinkfedilinkarrow-up41·19 days agoIt would be nice if it was possible to describe perfectly what a program is supposed to do.
minus-squareOrvorn@slrpnk.netlinkfedilinkarrow-up27·19 days agoSomeone should invent some kind of database of syntax, like a… code
minus-squareheavydust@sh.itjust.workslinkfedilinkarrow-up17·19 days agoBut it would need to be reliable with a syntax, like some kind of grammar.
minus-squarepeoplebeproblems@midwest.sociallinkfedilinkEnglisharrow-up13·19 days agoThat’s great, but then how do we know that the grammar matches what we want to do - with some sort of test?
minus-squareNatanael@infosec.publinkfedilinkarrow-up12·19 days agoHow to we know what to test? Maybe with some kind of specification?
minus-squaremaiskanzler@feddit.nllinkfedilinkarrow-up2·edit-218 days agoPeople could give things a name and write down what type of thing it is.
minus-squareKnock_Knock_Lemmy_In@lemmy.worldlinkfedilinkarrow-up3·19 days agoWe don’t want anything amateur. It has to be a professional codegrammar.
minus-squaresnooggums@lemmy.worldlinkfedilinkEnglisharrow-up6·edit-219 days agoWhat, like some kind of design requirements? Heresy!
minus-squareBjörn Tantau@swg-empire.delinkfedilinkarrow-up3·19 days agoDesign requirements are too ambiguous.
minus-squareheavydust@sh.itjust.workslinkfedilinkarrow-up3·19 days agoThat’s why you must negotiate or clarify what is being asked. Once it has been accepted, it is not ambiguous anymore as long as you respect it.
minus-squaresnooggums@lemmy.worldlinkfedilinkEnglisharrow-up3·19 days agoDesign requirements are what it should do, not how it does it.
minus-squarepsud@aussie.zonelinkfedilinkEnglisharrow-up2·18 days agoI’m a systems analyst, or in agile terminology “a designer” as I’m responsible for “design artifacts” Our designs are usually unambiguous
minus-squareVenator@lemmy.nzlinkfedilinkarrow-up3·18 days agoYeah but that’s a lot of writing. Much less effort to get the plagiarism machine to write it instead.
minus-squareDrew Belloc@programming.devlinkfedilinkarrow-up2arrow-down1·19 days agoWhat did you said?
minus-squarepeoplebeproblems@midwest.sociallinkfedilinkEnglisharrow-up0·19 days agoHa None of us would have jobs
minus-squareMentalEdge@sopuli.xyzlinkfedilinkarrow-up2·19 days agoI think the joke is that that is literally what coding, is.
It would be nice if it was possible to describe perfectly what a program is supposed to do.
Someone should invent some kind of database of syntax, like a… code
But it would need to be reliable with a syntax, like some kind of grammar.
That’s great, but then how do we know that the grammar matches what we want to do - with some sort of test?
How to we know what to test? Maybe with some kind of specification?
People could give things a name and write down what type of thing it is.
A codegrammar?
We don’t want anything amateur. It has to be a professional codegrammar.
What, like some kind of design requirements?
Heresy!
Design requirements are too ambiguous.
That’s why you must negotiate or clarify what is being asked. Once it has been accepted, it is not ambiguous anymore as long as you respect it.
Design requirements are what it should do, not how it does it.
I’m a systems analyst, or in agile terminology “a designer” as I’m responsible for “design artifacts”
Our designs are usually unambiguous
Yeah but that’s a lot of writing. Much less effort to get the plagiarism machine to write it instead.
What did you said?
Ha
None of us would have jobs
I think the joke is that that is literally what coding, is.