ການຂຽນໂປຼແກຼມຫຼາຍກວ່າການຂຽນລະຫັດ

ນີ້ແມ່ນບົດຄວາມແປ ການສໍາມະນາ Stanford. ແຕ່ກ່ອນນັ້ນມີການແນະນໍາສັ້ນໆ. zombies ຖືກສ້າງຕັ້ງຂຶ້ນແນວໃດ? ທຸກຄົນໄດ້ພົບເຫັນຕົນເອງຢູ່ໃນສະຖານະການທີ່ເຂົາເຈົ້າຕ້ອງການເອົາຫມູ່ເພື່ອນຫຼືເພື່ອນຮ່ວມງານໃນລະດັບຂອງເຂົາເຈົ້າ, ແຕ່ມັນບໍ່ໄດ້ຜົນ. ຍິ່ງໄປກວ່ານັ້ນ, "ມັນບໍ່ໄດ້ຜົນ" ບໍ່ຫຼາຍສໍາລັບທ່ານ, ແຕ່ສໍາລັບລາວ: ໃນດ້ານຫນຶ່ງຂອງຂະຫນາດມີເງິນເດືອນປົກກະຕິ, ວຽກງານ, ແລະອື່ນໆ, ແລະອີກດ້ານຫນຶ່ງແມ່ນຄວາມຕ້ອງການທີ່ຈະຄິດ. ການ​ຄິດ​ບໍ່​ພໍ​ໃຈ​ແລະ​ເຈັບ​ປວດ. ລາວເຊົາໄວ ແລະສືບຕໍ່ຂຽນລະຫັດໂດຍບໍ່ໃຊ້ສະໝອງເລີຍ. ເຈົ້າຮູ້ວ່າມັນໃຊ້ຄວາມພະຍາຍາມຫຼາຍປານໃດເພື່ອເອົາຊະນະອຸປະສັກຂອງຄວາມສິ້ນຫວັງທີ່ໄດ້ຮຽນຮູ້, ແລະເຈົ້າບໍ່ເຮັດມັນ. ນີ້ແມ່ນວິທີການສ້າງ zombies, ເຊິ່ງເບິ່ງຄືວ່າສາມາດປິ່ນປົວໄດ້, ແຕ່ເບິ່ງຄືວ່າບໍ່ມີໃຜຈະເຮັດແນວນີ້.

ເມື່ອຂ້ອຍເຫັນນັ້ນ Leslie Lamport (ແມ່ນແລ້ວ, ເພື່ອນດຽວກັນນັ້ນຈາກປື້ມແບບຮຽນ) ມາຮອດລັດເຊຍ ແລະບໍ່ໄດ້ໃຫ້ບົດລາຍງານ, ແຕ່ກອງປະຊຸມຄໍາຖາມແລະຄໍາຕອບ, ຂ້າພະເຈົ້າມີຄວາມລະມັດລະວັງເລັກນ້ອຍ. ໃນກໍລະນີໃດກໍ່ຕາມ, Leslie ເປັນນັກວິທະຍາສາດທີ່ມີຊື່ສຽງໃນໂລກ, ຜູ້ຂຽນຂອງ Semalt ເຮັດວຽກໃນຄອມພິວເຕີ້ແຈກຢາຍ, ແລະທ່ານອາດຈະຮູ້ຈັກລາວດ້ວຍຕົວອັກສອນ La ໃນ LaTeX - "Lamport TeX". ປັດໄຈທີ່ເປັນຕາຕົກໃຈອັນທີສອງແມ່ນຄວາມຕ້ອງການຂອງລາວ: ທຸກຄົນທີ່ມາຕ້ອງ (ບໍ່ເສຍຄ່າທັງຫມົດ) ຟັງບົດລາຍງານຂອງລາວສອງສາມຢ່າງລ່ວງຫນ້າ, ມາຮອດຢ່າງຫນ້ອຍຫນຶ່ງຄໍາຖາມກ່ຽວກັບພວກເຂົາ, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນມາ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ເບິ່ງ​ສິ່ງ​ທີ່ Lamport ໄດ້​ອອກ​ອາ​ກາດ​ທີ່​ນັ້ນ - ແລະ​ມັນ​ດີ​ຫຼາຍ​! ນີ້ແມ່ນແທ້ສິ່ງນັ້ນ, ເປັນຢາເຊື່ອມຕໍ່ magic ສໍາລັບການປິ່ນປົວ zombies. ຂ້າພະເຈົ້າເຕືອນທ່ານວ່າ: ຂໍ້ຄວາມອາດຈະເຮັດໃຫ້ຜູ້ທີ່ຮັກວິທີການທີ່ວ່ອງໄວທີ່ສຸດແລະບໍ່ມັກການທົດສອບສິ່ງທີ່ພວກເຂົາຂຽນ.

ຫຼັງຈາກ habrokat, ການແປພາສາຂອງການສໍາມະນາຕົວຈິງໄດ້ເລີ່ມຕົ້ນ. ມ່ວນກັບການອ່ານ!

ບໍ່​ວ່າ​ຈະ​ເຮັດ​ວຽກ​ໃດ​ຫນຶ່ງ​, ທ່ານ​ສະ​ເຫມີ​ໄປ​ຈໍາ​ເປັນ​ຕ້ອງ​ຜ່ານ​ສາມ​ຂັ້ນ​ຕອນ​:

• ຕັດສິນໃຈວ່າທ່ານຕ້ອງການບັນລຸເປົ້າຫມາຍໃດ;
• ຕັດສິນໃຈວ່າເຈົ້າຈະບັນລຸເປົ້າໝາຍຂອງເຈົ້າໄດ້ແນວໃດ;
• ບັນລຸເປົ້າຫມາຍຂອງທ່ານ.

ນີ້ຍັງໃຊ້ກັບການຂຽນໂປລແກລມ. ເມື່ອພວກເຮົາຂຽນລະຫັດ, ພວກເຮົາຕ້ອງການ:

• ຕັດສິນໃຈວ່າໂຄງການຄວນເຮັດແນວໃດ;
• ກໍານົດຢ່າງແນ່ນອນວ່າມັນຄວນຈະປະຕິບັດວຽກງານຂອງຕົນແນວໃດ;
• ຂຽນລະຫັດທີ່ເຫມາະສົມ.

ຂັ້ນຕອນສຸດທ້າຍ, ແນ່ນອນ, ແມ່ນສໍາຄັນຫຼາຍ, ແຕ່ຂ້ອຍຈະບໍ່ເວົ້າກ່ຽວກັບມັນໃນມື້ນີ້. ແທນທີ່ຈະ, ພວກເຮົາຈະປຶກສາຫາລືສອງອັນທໍາອິດ. ຜູ້ຂຽນໂປລແກລມທຸກຄົນປະຕິບັດພວກມັນກ່ອນທີ່ຈະເລີ່ມເຮັດວຽກ. ທ່ານບໍ່ໄດ້ນັ່ງລົງເພື່ອຂຽນເວັ້ນເສຍແຕ່ວ່າທ່ານໄດ້ຕັດສິນໃຈສິ່ງທີ່ທ່ານກໍາລັງຂຽນ: ຕົວທ່ອງເວັບຫຼືຖານຂໍ້ມູນ. ຄວາມຄິດທີ່ແນ່ນອນຂອງເປົ້າຫມາຍຈະຕ້ອງມີຢູ່. ແລະທ່ານຄິດຢ່າງແນ່ນອນກ່ຽວກັບສິ່ງທີ່ໂຄງການຈະເຮັດ, ແລະຢ່າຂຽນມັນຢ່າງຜິດຫວັງໂດຍຫວັງວ່າລະຫັດຕົວມັນເອງຈະປ່ຽນເປັນຕົວທ່ອງເວັບ.

ການຄິດລ່ວງໜ້າຂອງລະຫັດນີ້ເກີດຂຶ້ນແທ້ແນວໃດ? ພວກເຮົາຄວນພະຍາຍາມຫຼາຍປານໃດໃນເລື່ອງນີ້? ມັນທັງຫມົດແມ່ນຂຶ້ນກັບວ່າບັນຫາທີ່ສັບສົນທີ່ພວກເຮົາກໍາລັງແກ້ໄຂ. ໃຫ້ເວົ້າວ່າພວກເຮົາຕ້ອງການຂຽນລະບົບການແຈກຢາຍທີ່ທົນທານຕໍ່ຄວາມຜິດ. ໃນກໍລະນີນີ້, ພວກເຮົາຄວນຄິດຢ່າງລະອຽດກ່ອນທີ່ຈະນັ່ງລົງລະຫັດ. ຈະເປັນແນວໃດຖ້າພວກເຮົາພຽງແຕ່ຕ້ອງການເພີ່ມຕົວແປຈໍານວນເຕັມໂດຍ 1? ຢູ່ glance ທໍາອິດ, ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ເປັນເລື່ອງເລັກໆນ້ອຍໆແລະບໍ່ຈໍາເປັນຕ້ອງມີຄວາມຄິດໃດໆ, ແຕ່ຫຼັງຈາກນັ້ນພວກເຮົາຈື່ຈໍາວ່າການລົ້ນສາມາດເກີດຂື້ນໄດ້. ເພາະສະນັ້ນ, ເຖິງແມ່ນວ່າເພື່ອເຂົ້າໃຈວ່າບັນຫາແມ່ນງ່າຍດາຍຫຼືສັບສົນ, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງຄິດ.

ຖ້າ​ເຈົ້າ​ຄິດ​ຜ່ານ​ທາງ​ແກ້​ໄຂ​ທີ່​ເປັນ​ໄປ​ໄດ້​ໃນ​ການ​ລ່ວງ​ຫນ້າ​, ທ່ານ​ສາ​ມາດ​ຫຼີກ​ເວັ້ນ​ການ​ຜິດ​ພາດ​. ແຕ່ນີ້ຮຽກຮ້ອງໃຫ້ຄວາມຄິດຂອງເຈົ້າຈະແຈ້ງ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງຂຽນຄວາມຄິດຂອງເຈົ້າ. ຂ້ອຍມັກຄໍາເວົ້າຂອງ Dick Guindon: "ເມື່ອທ່ານຂຽນ, ທໍາມະຊາດຈະສະແດງໃຫ້ທ່ານເຫັນວ່າຄວາມຄິດຂອງເຈົ້າຂີ້ຮ້າຍເທົ່າໃດ." ຖ້າທ່ານບໍ່ຂຽນ, ທ່ານພຽງແຕ່ຄິດວ່າທ່ານກໍາລັງຄິດ. ແລະທ່ານຈໍາເປັນຕ້ອງຂຽນຄວາມຄິດຂອງເຈົ້າໃນຮູບແບບສະເພາະ.

ຂໍ້ມູນຈໍາເພາະຮັບໃຊ້ຫຼາຍຫນ້າທີ່, ໂດຍສະເພາະໃນໂຄງການຂະຫນາດໃຫຍ່. ແຕ່ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບຫນຶ່ງຂອງພວກເຂົາເທົ່ານັ້ນ: ພວກເຂົາຊ່ວຍໃຫ້ພວກເຮົາຄິດຢ່າງຈະແຈ້ງ. ການຄິດຢ່າງຈະແຈ້ງແມ່ນມີຄວາມສໍາຄັນຫຼາຍ ແລະຂ້ອນຂ້າງຍາກ, ດັ່ງນັ້ນພວກເຮົາຕ້ອງການຄວາມຊ່ວຍເຫຼືອໃດໆຢູ່ທີ່ນີ້. ພວກເຮົາຄວນຂຽນສະເພາະໃນພາສາໃດ? ໂດຍທົ່ວໄປ, ນີ້ແມ່ນຄໍາຖາມທໍາອິດສະເຫມີສໍາລັບນັກຂຽນໂປລແກລມ: ພວກເຮົາຈະຂຽນໃນພາສາໃດ? ບໍ່ມີຄໍາຕອບທີ່ຖືກຕ້ອງຫນຶ່ງ: ບັນຫາທີ່ພວກເຮົາແກ້ໄຂແມ່ນມີຄວາມຫຼາກຫຼາຍເກີນໄປ. ສໍາລັບບາງຄົນ, TLA+ ແມ່ນພາສາສະເພາະທີ່ຂ້ອຍພັດທະນາ. ສໍາລັບຄົນອື່ນ, ມັນສະດວກກວ່າທີ່ຈະໃຊ້ພາສາຈີນ. ມັນທັງຫມົດແມ່ນຂຶ້ນກັບສະຖານະການ.

ຄໍາຖາມທີ່ສໍາຄັນກວ່ານັ້ນແມ່ນ: ເຮັດແນວໃດພວກເຮົາສາມາດບັນລຸຄວາມຄິດທີ່ຊັດເຈນກວ່າ? ຄໍາຕອບ: ພວກເຮົາຕ້ອງຄິດຄືກັບນັກວິທະຍາສາດ. ນີ້​ແມ່ນ​ແນວ​ຄິດ​ທີ່​ໄດ້​ຜົນ​ດີ​ໃນ​ໄລຍະ 500 ປີ​ທີ່​ຜ່ານ​ມາ. ໃນວິທະຍາສາດພວກເຮົາສ້າງແບບຈໍາລອງທາງຄະນິດສາດຂອງຄວາມເປັນຈິງ. ດາລາສາດແມ່ນບາງທີວິທະຍາສາດທໍາອິດໃນຄວາມຫມາຍທີ່ເຄັ່ງຄັດຂອງຄໍາສັບ. ໃນຮູບແບບຄະນິດສາດທີ່ໃຊ້ໃນດາລາສາດ, ອົງການຈັດຕັ້ງຊັ້ນສູງປະກົດວ່າເປັນຈຸດທີ່ມີມະຫາຊົນ, ຕໍາແຫນ່ງແລະ momentum, ເຖິງແມ່ນວ່າໃນຄວາມເປັນຈິງແລ້ວພວກມັນເປັນວັດຖຸທີ່ສັບສົນທີ່ສຸດທີ່ມີພູເຂົາແລະມະຫາສະຫມຸດ, ebbs ແລະກະແສ. ຮູບແບບນີ້, ເຊັ່ນດຽວກັນກັບສິ່ງອື່ນໆ, ໄດ້ຖືກສ້າງຂື້ນເພື່ອແກ້ໄຂບັນຫາບາງຢ່າງ. ມັນເປັນການດີສໍາລັບການກໍານົດບ່ອນທີ່ຈະຊີ້ telescope ຖ້າຫາກວ່າທ່ານຕ້ອງການທີ່ຈະຊອກຫາດາວໄດ້. ແຕ່ຖ້າທ່ານຕ້ອງການຄາດຄະເນສະພາບອາກາດເທິງໂລກນີ້, ຮູບແບບນີ້ຈະບໍ່ເຮັດວຽກ.

ຄະນິດສາດອະນຸຍາດໃຫ້ພວກເຮົາກໍານົດຄຸນສົມບັດຂອງຕົວແບບ. ແລະວິທະຍາສາດສະແດງໃຫ້ເຫັນວ່າຄຸນສົມບັດເຫຼົ່ານີ້ກ່ຽວຂ້ອງກັບຄວາມເປັນຈິງແນວໃດ. ໃຫ້ເວົ້າກ່ຽວກັບວິທະຍາສາດຂອງພວກເຮົາ, ວິທະຍາສາດຄອມພິວເຕີ. ຄວາມເປັນຈິງທີ່ພວກເຮົາເຮັດວຽກກັບລະບົບຄອມພິວເຕີຂອງທຸກປະເພດ: ໂປເຊດເຊີ, ເຄື່ອງຫຼີ້ນເກມ, ຄອມພິວເຕີທີ່ດໍາເນີນໂຄງການ, ແລະອື່ນໆ. ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບການປະຕິບັດໂຄງການໃນຄອມພິວເຕີ, ແຕ່, ໂດຍແລະຂະຫນາດໃຫຍ່, ສະຫຼຸບທັງຫມົດເຫຼົ່ານີ້ນໍາໃຊ້ກັບລະບົບຄອມພິວເຕີໃດໆ. ໃນວິທະຍາສາດຂອງພວກເຮົາພວກເຮົາໃຊ້ຕົວແບບທີ່ແຕກຕ່າງກັນຫຼາຍ: ເຄື່ອງ Turing, ບາງສ່ວນທີ່ສັ່ງຊຸດຂອງເຫດການ, ແລະອື່ນໆຈໍານວນຫຼາຍ.

ໂຄງການແມ່ນຫຍັງ? ນີ້ແມ່ນລະຫັດໃດໆທີ່ສາມາດພິຈາລະນາດ້ວຍຕົນເອງ. ໃຫ້ເວົ້າວ່າພວກເຮົາຈໍາເປັນຕ້ອງຂຽນຕົວທ່ອງເວັບ. ພວກເຮົາປະຕິບັດສາມວຽກງານ: ອອກແບບການນໍາສະເຫນີຂອງຜູ້ໃຊ້ຂອງໂຄງການ, ຫຼັງຈາກນັ້ນຂຽນແຜນວາດລະດັບສູງຂອງໂຄງການ, ແລະສຸດທ້າຍຂຽນລະຫັດ. ໃນຂະນະທີ່ພວກເຮົາຂຽນລະຫັດ, ພວກເຮົາຮູ້ວ່າພວກເຮົາຈໍາເປັນຕ້ອງຂຽນຕົວພິມຂໍ້ຄວາມ. ທີ່ນີ້ອີກເທື່ອຫນຶ່ງພວກເຮົາຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາສາມ: ກໍານົດສິ່ງທີ່ຂໍ້ຄວາມເຄື່ອງມືນີ້ຈະກັບຄືນມາ; ເລືອກ algorithm ສໍາລັບການຈັດຮູບແບບ; ຂຽນລະຫັດ. ວຽກງານນີ້ມີໜ້າວຽກຍ່ອຍຂອງຕົນເອງ: ການໃສ່ຂີດໝາຍໃສ່ໃນຄຳສັບຢ່າງຖືກຕ້ອງ. ພວກເຮົາຍັງແກ້ໄຂວຽກງານຍ່ອຍນີ້ໃນສາມຂັ້ນຕອນ - ດັ່ງທີ່ພວກເຮົາເຫັນ, ພວກມັນຖືກຊ້ໍາໃນຫຼາຍລະດັບ.

ຂໍໃຫ້ພິຈາລະນາຂັ້ນຕອນທໍາອິດທີ່ໃກ້ຊິດ: ບັນຫາໃດທີ່ໂຄງການແກ້ໄຂ. ໃນທີ່ນີ້ພວກເຮົາສ່ວນຫຼາຍມັກຈະສ້າງແບບຈໍາລອງໂຄງການເປັນຫນ້າທີ່ເອົາບາງວັດສະດຸປ້ອນແລະໃຫ້ຜົນໄດ້ຮັບບາງຢ່າງ. ໃນຄະນິດສາດ, ຟັງຊັນໜຶ່ງມັກຈະຖືກອະທິບາຍວ່າເປັນຊຸດຄູ່ຕາມລຳດັບ. ຕົວຢ່າງ, ຟັງຊັນການສີ່ຫຼ່ຽມສຳລັບຕົວເລກທຳມະຊາດຖືກອະທິບາຍເປັນຊຸດ {<0,0>, <1,1>, <2,4>, <3,9>, …}. ໂດເມນຂອງຄໍານິຍາມຂອງຫນ້າທີ່ດັ່ງກ່າວແມ່ນຊຸດຂອງອົງປະກອບທໍາອິດຂອງແຕ່ລະຄູ່, ນັ້ນແມ່ນ, ຕົວເລກທໍາມະຊາດ. ເພື່ອກໍານົດຫນ້າທີ່, ພວກເຮົາຈໍາເປັນຕ້ອງລະບຸໂດເມນແລະສູດຂອງມັນ.

ແຕ່ຟັງຊັນໃນຄະນິດສາດບໍ່ຄືກັບຟັງຊັນໃນພາສາການຂຽນໂປຼແກຼມ. ຄະນິດສາດແມ່ນງ່າຍດາຍຫຼາຍ. ເນື່ອງຈາກຂ້ອຍບໍ່ມີເວລາສໍາລັບຕົວຢ່າງທີ່ສັບສົນ, ໃຫ້ພິຈາລະນາແບບງ່າຍໆ: ຫນ້າທີ່ໃນ C ຫຼືວິທີການຄົງທີ່ໃນ Java ທີ່ສົ່ງຄືນຕົວຫານທົ່ວໄປທີ່ໃຫຍ່ທີ່ສຸດຂອງສອງຈໍານວນເຕັມ. ໃນສະເພາະຂອງວິທີການນີ້ພວກເຮົາຈະຂຽນ: ຄິດໄລ່ GCD(M,N) ສໍາລັບການໂຕ້ຖຽງ M и Nບ່ອນທີ່ GCD(M,N) - ຟັງຊັນທີ່ມີໂດເມນເປັນຊຸດຂອງຄູ່ຂອງຈໍານວນເຕັມ, ແລະຄ່າກັບຄືນແມ່ນຈໍານວນທີ່ໃຫຍ່ທີ່ສຸດທີ່ແບ່ງອອກໂດຍ. M и N. ຄວາມເປັນຈິງປຽບທຽບກັບຮູບແບບນີ້ແນວໃດ? ຮູບແບບດໍາເນີນການດ້ວຍຈໍານວນເຕັມ, ແລະໃນ C ຫຼື Java ພວກເຮົາມີ 32-bit int. ຮູບແບບນີ້ອະນຸຍາດໃຫ້ພວກເຮົາຕັດສິນໃຈວ່າ algorithm ແມ່ນຖືກຕ້ອງ GCD, ແຕ່ມັນຈະບໍ່ປ້ອງກັນຄວາມຜິດພາດ overflow. ນີ້ຈະຮຽກຮ້ອງໃຫ້ມີຮູບແບບທີ່ສັບສົນຫຼາຍ, ເຊິ່ງບໍ່ມີເວລາ.

ໃຫ້ເວົ້າກ່ຽວກັບຂໍ້ຈໍາກັດຂອງຫນ້າທີ່ເປັນຕົວແບບ. ບາງໂຄງການ (ເຊັ່ນ: ລະບົບປະຕິບັດການ) ບໍ່ພຽງແຕ່ສົ່ງຄືນຄ່າສະເພາະສໍາລັບການໂຕ້ຖຽງທີ່ແນ່ນອນ; ພວກເຂົາສາມາດດໍາເນີນການຢ່າງຕໍ່ເນື່ອງ. ນອກຈາກນັ້ນ, ຫນ້າທີ່ເປັນຕົວແບບແມ່ນບໍ່ດີພໍສໍາລັບຂັ້ນຕອນທີສອງ: ການວາງແຜນວິທີການແກ້ໄຂບັນຫາ. Quicksort ແລະ bubble compute ຟັງຊັນດຽວກັນ, ແຕ່ພວກມັນແມ່ນ algorithms ທີ່ແຕກຕ່າງກັນຫມົດ. ດັ່ງນັ້ນ, ເພື່ອອະທິບາຍວິທີການບັນລຸເປົ້າຫມາຍຂອງໂຄງການ, ຂ້ອຍໃຊ້ຕົວແບບອື່ນ, ໃຫ້ເອີ້ນວ່າຮູບແບບພຶດຕິກໍາມາດຕະຖານ. ໂປລແກລມຖືກສະແດງຢູ່ໃນມັນເປັນຊຸດຂອງພຶດຕິກໍາທີ່ຖືກຕ້ອງ, ແຕ່ລະອັນ, ໃນທາງກັບກັນ, ເປັນລໍາດັບຂອງລັດ, ແລະລັດແມ່ນການມອບຫມາຍຄ່າໃຫ້ກັບຕົວແປ.

ຂໍໃຫ້ເບິ່ງວ່າຂັ້ນຕອນທີສອງສໍາລັບສູດການຄິດໄລ່ Euclidean ຈະມີລັກສະນະແນວໃດ. ພວກເຮົາຈໍາເປັນຕ້ອງຄິດໄລ່ GCD(M, N). ພວກເຮົາເລີ່ມຕົ້ນ M ວິທີການ xແລະ N ວິທີການ y, ຫຼັງຈາກນັ້ນຊ້ຳໆຫັກຕົວແປທີ່ນ້ອຍກວ່າຂອງຕົວແປເຫຼົ່ານີ້ອອກຈາກຕົວໃຫຍ່ກວ່າຈົນກວ່າພວກມັນຈະເທົ່າກັນ. ຕົວຢ່າງ, ຖ້າ M = 12ແລະ N = 18, ພວກເຮົາສາມາດອະທິບາຍພຶດຕິກໍາດັ່ງຕໍ່ໄປນີ້:

[x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6]

ແລະຖ້າ M = 0 и N = 0? ສູນແມ່ນແບ່ງອອກດ້ວຍຕົວເລກທັງຫມົດ, ດັ່ງນັ້ນບໍ່ມີຕົວຫານທີ່ໃຫຍ່ທີ່ສຸດໃນກໍລະນີນີ້. ໃນສະຖານະການນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງກັບຄືນໄປຫາຂັ້ນຕອນທໍາອິດແລະຖາມວ່າ: ພວກເຮົາຈໍາເປັນຕ້ອງຄິດໄລ່ GCD ສໍາລັບຕົວເລກທີ່ບໍ່ແມ່ນບວກບໍ? ຖ້າຫາກວ່ານີ້ບໍ່ຈໍາເປັນ, ຫຼັງຈາກນັ້ນທ່ານພຽງແຕ່ຕ້ອງການທີ່ຈະມີການປ່ຽນແປງສະເພາະ.

A digression ສັ້ນກ່ຽວກັບຜົນຜະລິດແມ່ນຢູ່ໃນຄໍາສັ່ງທີ່ນີ້. ມັນມັກຈະຖືກວັດແທກຢູ່ໃນຈໍານວນເສັ້ນຂອງລະຫັດທີ່ຂຽນຕໍ່ມື້. ແຕ່ການເຮັດວຽກຂອງເຈົ້າມີປະໂຫຍດຫຼາຍຖ້າທ່ານກໍາຈັດຈໍານວນເສັ້ນທີ່ແນ່ນອນ, ເພາະວ່າທ່ານມີຫ້ອງຫນ້ອຍສໍາລັບແມງໄມ້. ແລະວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະກໍາຈັດລະຫັດແມ່ນຢູ່ໃນຂັ້ນຕອນທໍາອິດ. ມັນເປັນໄປໄດ້ວ່າທ່ານພຽງແຕ່ບໍ່ຕ້ອງການລະຄັງແລະ whistles ທັງຫມົດທີ່ທ່ານກໍາລັງພະຍາຍາມປະຕິບັດ. ວິທີທີ່ໄວທີ່ສຸດເພື່ອເຮັດໃຫ້ໂຄງການງ່າຍແລະປະຫຍັດເວລາແມ່ນການບໍ່ເຮັດສິ່ງທີ່ບໍ່ຄວນເຮັດ. ຂັ້ນຕອນທີສອງມີທ່າແຮງການປະຫຍັດເວລາສູງສຸດທີສອງ. ຖ້າທ່ານວັດແທກຜົນຜະລິດໃນແງ່ຂອງເສັ້ນທີ່ຂຽນ, ຫຼັງຈາກນັ້ນການຄິດກ່ຽວກັບວິທີການສໍາເລັດວຽກງານຈະເຮັດໃຫ້ເຈົ້າ ຜົນຜະລິດຫນ້ອຍ, ເນື່ອງຈາກວ່າທ່ານສາມາດແກ້ໄຂບັນຫາດຽວກັນກັບລະຫັດຫນ້ອຍ. ຂ້ອຍບໍ່ສາມາດໃຫ້ສະຖິຕິທີ່ແນ່ນອນຢູ່ທີ່ນີ້, ເພາະວ່າຂ້ອຍບໍ່ມີວິທີທີ່ຈະນັບຈໍານວນເສັ້ນທີ່ຂ້ອຍບໍ່ໄດ້ຂຽນເນື່ອງຈາກເວລາທີ່ຂ້ອຍໃຊ້ໃນສະເພາະ, ນັ້ນແມ່ນ, ໃນຂັ້ນຕອນທໍາອິດແລະທີສອງ. ແລະພວກເຮົາບໍ່ສາມາດເຮັດການທົດລອງຢູ່ທີ່ນີ້ໄດ້, ເພາະວ່າໃນການທົດລອງພວກເຮົາບໍ່ມີສິດທີ່ຈະເຮັດສໍາເລັດຂັ້ນຕອນທໍາອິດ; ວຽກງານແມ່ນຖືກກໍານົດລ່ວງຫນ້າ.

ມັນເປັນເລື່ອງງ່າຍທີ່ຈະເບິ່ງຂ້າມຄວາມຫຍຸ້ງຍາກຫຼາຍໃນຂໍ້ກໍານົດທີ່ບໍ່ເປັນທາງການ. ບໍ່ມີຫຍັງຍາກກ່ຽວກັບການຂຽນຂໍ້ກໍານົດທີ່ເຂັ້ມງວດສໍາລັບຫນ້າທີ່; ຂ້າພະເຈົ້າຈະບໍ່ສົນທະນານີ້. ແທນທີ່ຈະ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບການຂຽນສະເພາະທີ່ເຂັ້ມແຂງສໍາລັບພຶດຕິກໍາມາດຕະຖານ. ມີທິດສະດີບົດທີ່ລະບຸວ່າຊຸດຂອງພຶດຕິກໍາສາມາດຖືກອະທິບາຍໂດຍໃຊ້ຊັບສິນຄວາມປອດໄພ (ຄວາມປອດໄພ) ແລະຄຸນສົມບັດການຢູ່ລອດ (ຊີວິດ). ຄວາມປອດໄພຫມາຍຄວາມວ່າບໍ່ມີຫຍັງທີ່ບໍ່ດີຈະເກີດຂຶ້ນ, ໂຄງການຈະບໍ່ໃຫ້ຄໍາຕອບທີ່ຜິດພາດ. ຄວາມຢູ່ລອດຫມາຍຄວາມວ່າໄວຫຼືຫຼັງຈາກນັ້ນບາງສິ່ງບາງຢ່າງທີ່ດີຈະເກີດຂຶ້ນ, i.e. ໂຄງການຈະໄວຫຼືຫຼັງຈາກນັ້ນໃຫ້ຄໍາຕອບທີ່ຖືກຕ້ອງ. ຕາມກົດລະບຽບ, ຄວາມປອດໄພແມ່ນຕົວຊີ້ວັດທີ່ສໍາຄັນກວ່າ; ຄວາມຜິດພາດມັກຈະເກີດຂື້ນຢູ່ທີ່ນີ້. ດັ່ງນັ້ນ, ເພື່ອປະຫຍັດເວລາ, ຂ້າພະເຈົ້າຈະບໍ່ເວົ້າກ່ຽວກັບການຢູ່ລອດ, ເຖິງແມ່ນວ່າມັນ, ແນ່ນອນ, ຍັງມີຄວາມສໍາຄັນ.

ພວກເຮົາບັນລຸຄວາມປອດໄພໂດຍການລະບຸຊຸດຂອງສະຖານະເບື້ອງຕົ້ນທີ່ເປັນໄປໄດ້. ແລະອັນທີສອງ, ການພົວພັນກັບລັດຕໍ່ໄປທີ່ເປັນໄປໄດ້ທັງຫມົດສໍາລັບແຕ່ລະລັດ. ໃຫ້ປະພຶດຕົວຄືກັບນັກວິທະຍາສາດ ແລະກຳນົດລັດທາງຄະນິດສາດ. ຊຸດຂອງລັດເບື້ອງຕົ້ນແມ່ນອະທິບາຍໂດຍສູດ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນກໍລະນີຂອງ Euclidean algorithm: (x = M) ∧ (y = N). ສໍາລັບຄ່າທີ່ແນ່ນອນ M и N ມີພຽງແຕ່ຫນຶ່ງສະຖານະເບື້ອງຕົ້ນ. ຄວາມສຳພັນກັບລັດຕໍ່ໄປແມ່ນອະທິບາຍໂດຍສູດທີ່ຕົວແປຂອງສະຖານະຕໍ່ໄປຖືກຂຽນດ້ວຍ prime, ແລະຕົວແປຂອງສະຖານະປັດຈຸບັນແມ່ນຂຽນໂດຍບໍ່ມີ prime. ໃນກໍລະນີຂອງສູດການຄິດໄລ່ Euclidean, ພວກເຮົາຈະຈັດການກັບຄວາມແຕກຕ່າງຂອງສອງສູດ, ໃນຫນຶ່ງໃນນັ້ນ. x ເປັນມູນຄ່າທີ່ໃຫຍ່ທີ່ສຸດ, ແລະໃນທີສອງ - y:

ໃນກໍລະນີທໍາອິດ, ຄ່າໃຫມ່ຂອງ y ແມ່ນເທົ່າກັບຄ່າທີ່ຜ່ານມາຂອງ y, ແລະພວກເຮົາໄດ້ຮັບຄ່າໃຫມ່ຂອງ x ໂດຍການຫັກລົບຕົວແປທີ່ນ້ອຍລົງຈາກຕົວແປທີ່ໃຫຍ່ກວ່າ. ໃນກໍລະນີທີສອງ, ພວກເຮົາເຮັດກົງກັນຂ້າມ.

ໃຫ້ກັບຄືນໄປຫາ algorithm Euclidean. ສົມມຸດວ່າອີກເທື່ອຫນຶ່ງ M = 12, N = 18. ນີ້ກໍານົດສະຖານະເບື້ອງຕົ້ນອັນດຽວ, (x = 12) ∧ (y = 18). ຫຼັງຈາກນັ້ນ, ພວກເຮົາສຽບຄ່າເຫຼົ່ານີ້ເຂົ້າໄປໃນສູດຂ້າງເທິງແລະໄດ້ຮັບ:

ນີ້ແມ່ນການແກ້ໄຂທີ່ເປັນໄປໄດ້ພຽງແຕ່: x' = 18 - 12 ∧ y' = 12, ແລະພວກເຮົາໄດ້ຮັບພຶດຕິກໍາ: [x = 12, y = 18]. ໃນທາງດຽວກັນ, ພວກເຮົາສາມາດອະທິບາຍທຸກລັດໃນພຶດຕິກໍາຂອງພວກເຮົາ: [x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6].

ໃນ​ລັດ​ທີ່​ສຸດ​ [x = 6, y = 6] ທັງສອງພາກສ່ວນຂອງການສະແດງອອກຈະບໍ່ຖືກຕ້ອງ, ສະນັ້ນມັນບໍ່ມີສະຖານະຕໍ່ໄປ. ດັ່ງນັ້ນ, ພວກເຮົາມີຂໍ້ກໍານົດຄົບຖ້ວນສົມບູນຂອງຂັ້ນຕອນທີສອງ - ດັ່ງທີ່ພວກເຮົາເຫັນ, ນີ້ແມ່ນຄະນິດສາດທໍາມະດາ, ຄືກັບວິສະວະກອນແລະນັກວິທະຍາສາດ, ແລະບໍ່ແປກ, ຄືກັບວິທະຍາສາດຄອມພິວເຕີ.

ສອງສູດນີ້ສາມາດຖືກລວມເຂົ້າກັນເປັນສູດໜຶ່ງຂອງເຫດຜົນທາງໂລກ. ມັນມີຄວາມສະຫງ່າງາມແລະງ່າຍຕໍ່ການອະທິບາຍ, ແຕ່ບໍ່ມີເວລາສໍາລັບມັນໃນປັດຈຸບັນ. ພວກເຮົາອາດຈະຕ້ອງການເຫດຜົນຊົ່ວຄາວເທົ່ານັ້ນສໍາລັບຊັບສິນຂອງຊີວິດຊີວາ; ສໍາລັບຄວາມປອດໄພມັນບໍ່ຈໍາເປັນ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ມັກ​ເຫດ​ຜົນ​ຊົ່ວ​ຄາວ​ເຊັ່ນ​ນັ້ນ​, ມັນ​ບໍ່​ແມ່ນ​ຄະ​ນິດ​ສາດ​ທໍາ​ມະ​ດາ​, ແຕ່​ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ການ​ດໍາ​ລົງ​ຊີ​ວິດ​ມັນ​ເປັນ​ຄວາມ​ຊົ່ວ​ຮ້າຍ​ທີ່​ຈໍາ​ເປັນ​.

ໃນສູດການຄິດໄລ່ Euclidean ສໍາລັບແຕ່ລະຄ່າ x и y ມີຄຸນຄ່າທີ່ເປັນເອກະລັກ x' и y', ເຊິ່ງເຮັດໃຫ້ຄວາມສໍາພັນກັບລັດຕໍ່ໄປເປັນຄວາມຈິງ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ສູດການຄິດໄລ່ Euclidean ແມ່ນກໍານົດ. ເພື່ອສ້າງແບບຈໍາລອງສູດການຄິດໄລ່ທີ່ບໍ່ແມ່ນຕົວກໍານົດ, ສະຖານະປະຈຸບັນຕ້ອງມີຫຼາຍສະຖານະໃນອະນາຄົດທີ່ເປັນໄປໄດ້, ແລະແຕ່ລະຄ່າຂອງຕົວແປທີ່ບໍ່ມີຕົວແປຈະຕ້ອງມີຫຼາຍຄ່າຂອງຕົວແປ primed ເຊັ່ນວ່າຄວາມສໍາພັນກັບລັດຕໍ່ໄປແມ່ນຄວາມຈິງ. ນີ້ບໍ່ແມ່ນການຍາກທີ່ຈະເຮັດ, ແຕ່ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ຍົກຕົວຢ່າງໃນປັດຈຸບັນ.

ເພື່ອເຮັດໃຫ້ເຄື່ອງມືເຮັດວຽກ, ທ່ານຕ້ອງການຄະນິດສາດຢ່າງເປັນທາງການ. ເຮັດແນວໃດເພື່ອໃຫ້ຂໍ້ກໍາຫນົດຢ່າງເປັນທາງການ? ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈະຕ້ອງການພາສາທີ່ເປັນທາງການ, e.g. TLA+. ຂໍ້ກໍານົດຂອງສູດການຄິດໄລ່ Euclidean ໃນພາສານີ້ຈະມີລັກສະນະນີ້:

ສັນ​ຍາ​ລັກ​ທີ່​ເທົ່າ​ທຽມ​ກັນ​ກັບ​ສາມ​ຫຼ່ຽມ​ຫມາຍ​ຄວາມ​ວ່າ​ຄ່າ​ທາງ​ຊ້າຍ​ຂອງ​ເຄື່ອງ​ຫມາຍ​ໄດ້​ຖືກ​ກໍາ​ນົດ​ໃຫ້​ເທົ່າ​ທຽມ​ກັບ​ຄ່າ​ຢູ່​ທາງ​ຂວາ​ຂອງ​ສັນ​ຍາ​. ໂດຍເນື້ອແທ້ແລ້ວ, ຂໍ້ກໍານົດແມ່ນຄໍານິຍາມ, ໃນກໍລະນີຂອງພວກເຮົາສອງຄໍານິຍາມ. ຕໍ່ກັບຂໍ້ມູນສະເພາະໃນ TLA+ ທ່ານຈໍາເປັນຕ້ອງເພີ່ມການປະກາດ ແລະ syntax ບາງອັນ, ຄືກັບໃນສະໄລ້ຂ້າງເທິງ. ໃນ ASCII ມັນຈະເບິ່ງຄືວ່ານີ້:

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ບໍ່ມີຫຍັງສັບສົນ. ຂໍ້ກໍານົດກ່ຽວກັບ TLA+ ສາມາດຖືກທົດສອບ, i.e., ພຶດຕິກໍາທີ່ເປັນໄປໄດ້ທັງຫມົດສາມາດໄດ້ຮັບການປະເມີນໃນຮູບແບບຂະຫນາດນ້ອຍ. ໃນກໍລະນີຂອງພວກເຮົາ, ຮູບແບບນີ້ຈະເປັນມູນຄ່າທີ່ແນ່ນອນ M и N. ນີ້​ແມ່ນ​ວິ​ທີ​ການ​ກວດ​ສອບ​ປະ​ສິດ​ທິ​ຜົນ​ຫຼາຍ​ແລະ​ງ່າຍ​ດາຍ​ທີ່​ເປັນ​ອັດ​ຕະ​ໂນ​ມັດ​ຫມົດ​. ນອກຈາກນັ້ນ, ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນຫຼັກຖານສະແດງຄວາມຈິງຢ່າງເປັນທາງການແລະກວດເບິ່ງພວກມັນດ້ວຍກົນຈັກ, ແຕ່ມັນໃຊ້ເວລາຫຼາຍ, ດັ່ງນັ້ນເກືອບບໍ່ມີໃຜເຮັດສິ່ງນີ້.

ຂໍ້ເສຍຫຼັກຂອງ TLA+ ແມ່ນວ່າມັນເປັນຄະນິດສາດ, ແລະນັກຂຽນໂປລແກລມແລະນັກວິທະຍາສາດຄອມພິວເຕີກໍ່ຢ້ານຄະນິດສາດ. ຢູ່ glance ທໍາອິດນີ້ຟັງຄືເລື່ອງຕະຫລົກ, ແຕ່ຫນ້າເສຍດາຍ, ຂ້າພະເຈົ້າເວົ້າເລື່ອງນີ້ຢ່າງຈິງຈັງ. ເພື່ອນຮ່ວມງານຂອງຂ້ອຍພຽງແຕ່ບອກຂ້ອຍວ່າລາວພະຍາຍາມອະທິບາຍ TLA+ ກັບນັກພັດທະນາຫຼາຍໆຄົນແນວໃດ. ທັນທີທີ່ສູດປາກົດຢູ່ໃນຫນ້າຈໍ, ຕາຂອງພວກເຂົາກາຍເປັນແກ້ວທັນທີ. ດັ່ງນັ້ນຖ້າ TLA+ ເປັນຕາຢ້ານ, ທ່ານສາມາດນໍາໃຊ້ PlusCal, ແມ່ນປະເພດຂອງພາສາການຂຽນໂປລແກລມຂອງຫຼິ້ນ. ການສະແດງອອກໃນ PlusCal ສາມາດເປັນ TLA + ໃດໆ, ນັ້ນແມ່ນ, ໂດຍພື້ນຖານແລ້ວການສະແດງອອກທາງຄະນິດສາດ. ນອກຈາກນັ້ນ, PlusCal ມີ syntax ສໍາລັບ algorithms ທີ່ບໍ່ກໍານົດ. ເນື່ອງຈາກວ່າ PlusCal ສາມາດຂຽນ TLA + ໃດໆ, ມັນສະແດງອອກຫຼາຍກ່ວາພາສາການຂຽນໂປຼແກຼມທີ່ແທ້ຈິງໃດໆ. ຕໍ່ໄປ, PlusCal ໄດ້ຖືກລວບລວມເຂົ້າໄປໃນຂໍ້ກໍານົດ TLA+ ທີ່ອ່ານງ່າຍ. ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າ, ແນ່ນອນ, ທີ່ສະລັບສັບຊ້ອນ PlusCal ຈະກາຍເປັນຫນຶ່ງທີ່ງ່າຍດາຍໃນ TLA + - ພຽງແຕ່ວ່າການຕິດຕໍ່ພົວພັນລະຫວ່າງເຂົາເຈົ້າຈະແຈ້ງ, ບໍ່ມີຄວາມສັບສົນເພີ່ມເຕີມຈະປາກົດ. ສຸດທ້າຍ, ຂໍ້ມູນສະເພາະນີ້ສາມາດກວດສອບໄດ້ໂດຍໃຊ້ເຄື່ອງມື TLA+. ໂດຍທົ່ວໄປແລ້ວ, PlusCal ສາມາດຊ່ວຍເອົາຊະນະ phobia ຂອງຄະນິດສາດ; ມັນງ່າຍທີ່ຈະເຂົ້າໃຈເຖິງແມ່ນວ່າສໍາລັບນັກຂຽນໂປລແກລມແລະນັກວິທະຍາສາດຄອມພິວເຕີ. ຂ້າພະເຈົ້າໄດ້ເຜີຍແຜ່ algorithms ໃນບາງເວລາ (ປະມານ 10 ປີ) ໃນອະດີດ.

ບາງທີບາງຄົນຈະຄັດຄ້ານວ່າ TLA+ ແລະ PlusCal ແມ່ນຄະນິດສາດ, ແລະຄະນິດສາດໃຊ້ໄດ້ກັບຕົວຢ່າງທີ່ສ້າງຂຶ້ນເທົ່ານັ້ນ. ໃນການປະຕິບັດ, ທ່ານຕ້ອງການພາສາທີ່ແທ້ຈິງທີ່ມີປະເພດ, ຂັ້ນຕອນ, ວັດຖຸ, ແລະອື່ນໆ. ອັນນີ້ຜິດ. ນີ້ແມ່ນສິ່ງທີ່ Chris Newcomb, ຜູ້ທີ່ເຮັດວຽກຢູ່ Amazon, ຂຽນວ່າ: "ພວກເຮົາໄດ້ນໍາໃຊ້ TLA + ໃນສິບໂຄງການຂະຫນາດໃຫຍ່, ແລະໃນທຸກໆກໍລະນີການນໍາໃຊ້ຂອງມັນເຮັດໃຫ້ມີຄວາມແຕກຕ່າງຢ່າງຫຼວງຫຼາຍຕໍ່ການພັດທະນາເພາະວ່າພວກເຮົາສາມາດຈັບແມງໄມ້ທີ່ເປັນອັນຕະລາຍກ່ອນທີ່ມັນຈະເຂົ້າສູ່ການຜະລິດ, ແລະຍ້ອນວ່າມັນເຮັດໃຫ້ພວກເຮົາມີຄວາມເຂົ້າໃຈແລະຄວາມຫມັ້ນໃຈທີ່ພວກເຮົາຕ້ອງການເພື່ອເຮັດໃຫ້ການຮຸກຮານ. ການເພີ່ມປະສິດທິພາບທີ່ບໍ່ມີອິດທິພົນຕໍ່ຄວາມຈິງຂອງໂຄງການ". ເຈົ້າສາມາດໄດ້ຍິນເລື້ອຍໆວ່າເມື່ອໃຊ້ວິທີການຢ່າງເປັນທາງການພວກເຮົາໄດ້ຮັບລະຫັດທີ່ບໍ່ມີປະສິດທິພາບ - ໃນການປະຕິບັດ, ທຸກສິ່ງທຸກຢ່າງແມ່ນກົງກັນຂ້າມ. ນອກຈາກນັ້ນ, ມີຄວາມຮັບຮູ້ວ່າຜູ້ຈັດການບໍ່ສາມາດເຊື່ອຫມັ້ນໃນຄວາມຕ້ອງການສໍາລັບວິທີການທີ່ເປັນທາງການ, ເຖິງແມ່ນວ່ານັກຂຽນໂປລແກລມຈະຫມັ້ນໃຈໃນຜົນປະໂຫຍດຂອງມັນ. ແລະ Newcomb ຂຽນວ່າ: "ຕອນນີ້ຜູ້ຈັດການກໍາລັງຊຸກຍູ້ໃນທຸກໆວິທີທີ່ເປັນໄປໄດ້ເພື່ອຂຽນສະເພາະໃນ TLA+, ແລະໂດຍສະເພາະການຈັດສັນເວລາສໍາລັບເລື່ອງນີ້". ດັ່ງນັ້ນເມື່ອຜູ້ຈັດການເຫັນວ່າ TLA+ ເຮັດວຽກ, ພວກເຂົາຍອມຮັບມັນ. Chris Newcomb ຂຽນເລື່ອງນີ້ປະມານຫົກເດືອນກ່ອນຫນ້ານີ້ (ເດືອນຕຸລາ 2014), ແຕ່ໃນປັດຈຸບັນ, ເທົ່າທີ່ຂ້າພະເຈົ້າຮູ້, TLA+ ຖືກນໍາໃຊ້ໃນ 14 ໂຄງການ, ບໍ່ແມ່ນ 10. ຕົວຢ່າງອື່ນກ່ຽວຂ້ອງກັບການອອກແບບຂອງ XBox 360. ນັກຮຽນຝຶກຫັດໄດ້ມາຫາ Charles Thacker ແລະ ຂຽນສະເພາະສໍາລັບລະບົບຄວາມຊົງຈໍາ. ຂໍ​ຂອບ​ໃຈ​ກັບ​ສະ​ເພາະ​ນີ້, bug ໄດ້​ຖືກ​ພົບ​ເຫັນ​ທີ່​ບໍ່​ດັ່ງ​ນັ້ນ​ຈະ​ບໍ່​ໄດ້​ຮັບ​ການ​ກວດ​ພົບ​ແລະ​ຈະ​ເຮັດ​ໃຫ້​ທຸກ XBox 360 crash ຫຼັງ​ຈາກ​ສີ່​ຊົ່ວ​ໂມງ​ຂອງ​ການ​ນໍາ​ໃຊ້. ວິສະວະກອນຈາກ IBM ຢືນຢັນວ່າການທົດສອບຂອງພວກເຂົາຈະບໍ່ກວດພົບແມງໄມ້ນີ້.

ທ່ານ​ສາ​ມາດ​ອ່ານ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ TLA+ ໃນ​ອິນ​ເຕີ​ເນັດ​, ແຕ່​ວ່າ​ໃນ​ປັດ​ຈຸ​ບັນ​ໃຫ້​ເວົ້າ​ກ່ຽວ​ກັບ​ການ​ສະ​ເພາະ​ບໍ່​ເປັນ​ທາງ​ການ​. ພວກເຮົາບໍ່ຄ່ອຍມີການຂຽນໂປຼແກຼມທີ່ຄິດໄລ່ຕົວຫານທົ່ວໄປຫນ້ອຍທີ່ສຸດແລະຄ້າຍຄືກັນ. ເລື້ອຍໆພວກເຮົາຂຽນໂປຼແກຼມເຊັ່ນເຄື່ອງມືເຄື່ອງພິມທີ່ສວຍງາມທີ່ຂ້ອຍຂຽນສໍາລັບ TLA+. ຫຼັງຈາກການປຸງແຕ່ງທີ່ງ່າຍດາຍທີ່ສຸດ, ລະຫັດ TLA+ ຈະມີລັກສະນະນີ້:

ແຕ່ໃນຕົວຢ່າງຂ້າງເທິງ, ຜູ້ໃຊ້ສ່ວນໃຫຍ່ຕ້ອງການການສົມທົບແລະເຄື່ອງຫມາຍເທົ່າທຽມກັນເພື່ອສອດຄ່ອງ. ດັ່ງນັ້ນການຈັດຮູບແບບທີ່ຖືກຕ້ອງຈະມີລັກສະນະຫຼາຍກວ່ານີ້:

ພິຈາລະນາຕົວຢ່າງອື່ນ:

ໃນທີ່ນີ້, ໃນທາງກົງກັນຂ້າມ, ການສອດຄ່ອງຂອງສັນຍານເທົ່າທຽມກັນ, ການເພີ່ມແລະການຄູນໃນແຫຼ່ງແມ່ນແບບສຸ່ມ, ດັ່ງນັ້ນການປຸງແຕ່ງທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນຂ້ອນຂ້າງພຽງພໍ. ໂດຍທົ່ວໄປ, ບໍ່ມີຄໍານິຍາມທາງຄະນິດສາດທີ່ແນ່ນອນຂອງຮູບແບບທີ່ຖືກຕ້ອງ, ເພາະວ່າ "ຖືກຕ້ອງ" ໃນກໍລະນີນີ້ຫມາຍຄວາມວ່າ "ສິ່ງທີ່ຜູ້ໃຊ້ຕ້ອງການ," ແລະນີ້ບໍ່ສາມາດກໍານົດທາງຄະນິດສາດໄດ້.

ມັນເບິ່ງຄືວ່າຖ້າພວກເຮົາບໍ່ມີຄໍານິຍາມຂອງຄວາມຈິງ, ຂໍ້ມູນສະເພາະແມ່ນບໍ່ມີປະໂຫຍດ. ແຕ່ນັ້ນບໍ່ແມ່ນຄວາມຈິງ. ພຽງແຕ່ຍ້ອນວ່າພວກເຮົາບໍ່ຮູ້ວ່າໂຄງການໃດຄວນເຮັດບໍ່ໄດ້ຫມາຍຄວາມວ່າພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງຄິດກ່ຽວກັບວິທີທີ່ມັນຄວນຈະເຮັດວຽກ - ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາຄວນໃຊ້ຄວາມພະຍາຍາມຫຼາຍກວ່າເກົ່າ. ຂໍ້ມູນສະເພາະແມ່ນມີຄວາມສໍາຄັນໂດຍສະເພາະຢູ່ທີ່ນີ້. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກໍານົດໂຄງການທີ່ດີທີ່ສຸດສໍາລັບການພິມທີ່ມີໂຄງສ້າງ, ແຕ່ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າພວກເຮົາບໍ່ຄວນປະຕິບັດມັນທັງຫມົດ, ແລະການຂຽນລະຫັດເປັນກະແສຂອງສະຕິບໍ່ແມ່ນກໍລະນີ. ຂ້າພະເຈົ້າໄດ້ສິ້ນສຸດການຂຽນຂໍ້ກໍານົດຂອງຫົກກົດລະບຽບທີ່ມີຄໍານິຍາມ ໃນຮູບແບບຂອງຄໍາເຫັນ ໃນໄຟລ໌ Java. ນີ້ແມ່ນຕົວຢ່າງຂອງກົດລະບຽບຫນຶ່ງ: a left-comment token is LeftComment aligned with its covering token. ກົດ​ລະ​ບຽບ​ນີ້​ແມ່ນ​ລາຍ​ລັກ​ອັກ​ສອນ​ໃນ​, ໃຫ້​ເວົ້າ​ວ່າ​, ພາ​ສາ​ອັງ​ກິດ​ທາງ​ຄະ​ນິດ​ສາດ​: LeftComment aligned, left-comment и covering token — ຂໍ້​ກໍາ​ນົດ​ທີ່​ມີ​ຄໍາ​ນິ​ຍາມ​. ນີ້ແມ່ນວິທີທີ່ນັກຄະນິດສາດອະທິບາຍຄະນິດສາດ: ພວກເຂົາຂຽນຄໍານິຍາມຂອງຄໍາສັບຕ່າງໆແລະ, ອີງໃສ່ພວກມັນ, ສ້າງກົດລະບຽບ. ຜົນປະໂຫຍດຂອງຂໍ້ກໍານົດນີ້ແມ່ນວ່າກົດລະບຽບຫົກແມ່ນເຂົ້າໃຈງ່າຍກວ່າແລະດີບັກຫຼາຍກວ່າລະຫັດ 850 ເສັ້ນ. ຂ້ອຍຕ້ອງເວົ້າວ່າການຂຽນກົດລະບຽບເຫຼົ່ານີ້ບໍ່ແມ່ນເລື່ອງງ່າຍ; ມັນໃຊ້ເວລາຫຼາຍເພື່ອແກ້ໄຂພວກມັນ. ຂ້ອຍຂຽນລະຫັດສະເພາະເພື່ອຈຸດປະສົງນີ້ທີ່ບອກຂ້ອຍວ່າກົດລະບຽບໃດຖືກໃຊ້. ເນື່ອງຈາກວ່າຂ້າພະເຈົ້າໄດ້ທົດສອບຫົກກົດລະບຽບເຫຼົ່ານີ້ດ້ວຍຕົວຢ່າງບໍ່ຫຼາຍປານໃດ, ຂ້າພະເຈົ້າບໍ່ຈໍາເປັນຕ້ອງ debug 850 ເສັ້ນຂອງລະຫັດ, ແລະແມງໄມ້ແມ່ນຂ້ອນຂ້າງງ່າຍທີ່ຈະຊອກຫາ. Java ມີເຄື່ອງມືທີ່ດີສໍາລັບການນີ້. ຖ້າຂ້ອຍພຽງແຕ່ຂຽນລະຫັດ, ມັນຈະໃຊ້ເວລາດົນກວ່ານີ້ແລະການຈັດຮູບແບບຈະມີຄຸນນະພາບທີ່ບໍ່ດີກວ່າ.

ເປັນ​ຫຍັງ​ຈຶ່ງ​ບໍ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ສະ​ເພາະ​ເປັນ​ທາງ​ການ​? ໃນອີກດ້ານຫນຶ່ງ, ການປະຕິບັດທີ່ຖືກຕ້ອງແມ່ນບໍ່ສໍາຄັນເກີນໄປຢູ່ທີ່ນີ້. ການພິມທີ່ມີໂຄງສ້າງແມ່ນຜູກມັດກັບບາງຄົນທີ່ບໍ່ພໍໃຈ, ດັ່ງນັ້ນຂ້ອຍຈຶ່ງບໍ່ຈໍາເປັນຕ້ອງເຮັດໃຫ້ມັນເຮັດວຽກຢ່າງຖືກຕ້ອງໃນທຸກສະຖານະການທີ່ຜິດປົກກະຕິ. ສິ່ງທີ່ສໍາຄັນກວ່ານັ້ນແມ່ນຄວາມຈິງທີ່ວ່າຂ້ອຍບໍ່ມີເຄື່ອງມືທີ່ພຽງພໍ. ຕົວກວດສອບແບບ TLA+ ແມ່ນບໍ່ມີປະໂຫຍດຢູ່ທີ່ນີ້, ສະນັ້ນຂ້ອຍຈະຕ້ອງຂຽນຕົວຢ່າງດ້ວຍມື.

ສະເປັກທີ່ໃຫ້ມາມີລັກສະນະທົ່ວໄປກັບທຸກຂໍ້ມູນສະເພາະ. ມັນເປັນລະດັບທີ່ສູງກວ່າລະຫັດ. ມັນສາມາດຖືກປະຕິບັດໃນພາສາໃດກໍ່ຕາມ. ບໍ່ມີເຄື່ອງມືຫຼືວິທີການສໍາລັບການຂຽນມັນ. ບໍ່ມີຫຼັກສູດການຂຽນໂປລແກລມຈະຊ່ວຍໃຫ້ທ່ານຂຽນສະເພາະນີ້. ແລະບໍ່ມີເຄື່ອງມືທີ່ສາມາດເຮັດໃຫ້ຂໍ້ມູນສະເພາະນີ້ບໍ່ຈໍາເປັນ, ເວັ້ນເສຍແຕ່ແນ່ນອນທ່ານກໍາລັງຂຽນພາສາໂດຍສະເພາະສໍາລັບການຂຽນໂປຼແກຼມພິມທີ່ມີໂຄງສ້າງໃນ TLA+. ສຸດທ້າຍ, ຂໍ້ມູນສະເພາະນີ້ບໍ່ໄດ້ເວົ້າຫຍັງກ່ຽວກັບວິທີທີ່ພວກເຮົາຈະຂຽນລະຫັດຢ່າງແທ້ຈິງ, ມັນພຽງແຕ່ບອກວ່າລະຫັດເຮັດ. ພວກເຮົາຂຽນສະເພາະເພື່ອຊ່ວຍພວກເຮົາຄິດຜ່ານບັນຫາກ່ອນທີ່ພວກເຮົາຈະເລີ່ມຄິດກ່ຽວກັບລະຫັດ.

ແຕ່​ສະ​ເພາະ​ນີ້​ຍັງ​ມີ​ລັກ​ສະ​ນະ​ທີ່​ແຕກ​ຕ່າງ​ຈາກ​ສະ​ເພາະ​ອື່ນໆ​. 95% ຂອງຂໍ້ມູນສະເພາະອື່ນໆແມ່ນສັ້ນກວ່າ ແລະງ່າຍດາຍກວ່າ:

ນອກຈາກນັ້ນ, ຂໍ້ກໍານົດນີ້ແມ່ນກົດລະບຽບທີ່ກໍານົດໄວ້. ນີ້ປົກກະຕິແລ້ວເປັນສັນຍານຂອງຂໍ້ກໍານົດທີ່ບໍ່ດີ. ການເຂົ້າໃຈຜົນສະທ້ອນຂອງກົດລະບຽບທີ່ກໍານົດໄວ້ແມ່ນຂ້ອນຂ້າງຍາກ, ນັ້ນແມ່ນເຫດຜົນທີ່ຂ້ອຍຕ້ອງໃຊ້ເວລາຫຼາຍໃນການແກ້ບັນຫາ. ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີນີ້ຂ້ອຍບໍ່ສາມາດຊອກຫາວິທີທີ່ດີກວ່າ.

ມັນເປັນມູນຄ່າທີ່ຈະເວົ້າສອງສາມຄໍາກ່ຽວກັບໂຄງການທີ່ດໍາເນີນການຢ່າງຕໍ່ເນື່ອງ. ໂດຍປົກກະຕິພວກເຂົາດໍາເນີນການຂະຫນານ, ເຊັ່ນ: ລະບົບປະຕິບັດການຫຼືລະບົບແຈກຢາຍ. ມີໜ້ອຍຄົນທີ່ສາມາດເຂົ້າໃຈພວກມັນຢູ່ໃນໃຈຂອງເຂົາເຈົ້າ ຫຼືຢູ່ໃນເຈ້ຍ, ແລະຂ້ອຍບໍ່ແມ່ນໜຶ່ງໃນນັ້ນ, ເຖິງແມ່ນວ່າຄັ້ງໜຶ່ງຂ້ອຍສາມາດເຮັດມັນໄດ້. ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງການເຄື່ອງມືທີ່ຈະກວດສອບການເຮັດວຽກຂອງພວກເຮົາ - ຕົວຢ່າງ, TLA+ ຫຼື PlusCal.

ເປັນຫຍັງຂ້ອຍຈໍາເປັນຕ້ອງຂຽນສະເພາະຖ້າຂ້ອຍຮູ້ແລ້ວວ່າລະຫັດຄວນເຮັດແນວໃດ? ໃນຄວາມເປັນຈິງ, ຂ້າພະເຈົ້າພຽງແຕ່ຄິດວ່າຂ້າພະເຈົ້າຮູ້ມັນ. ນອກຈາກນັ້ນ, ດ້ວຍຂໍ້ກໍາຫນົດຢູ່ໃນສະຖານທີ່, ຄົນພາຍນອກບໍ່ຈໍາເປັນຕ້ອງເບິ່ງລະຫັດເພື່ອເຂົ້າໃຈສິ່ງທີ່ມັນເຮັດ. ຂ້ອຍມີກົດລະບຽບ: ບໍ່ຄວນມີກົດລະບຽບທົ່ວໄປ. ມີຂໍ້ຍົກເວັ້ນຕໍ່ກົດລະບຽບນີ້ແນ່ນອນ, ນີ້ແມ່ນກົດລະບຽບທົ່ວໄປດຽວທີ່ຂ້ອຍປະຕິບັດຕາມ: ຂໍ້ກໍານົດຂອງສິ່ງທີ່ລະຫັດຄວນບອກຄົນທຸກສິ່ງທີ່ພວກເຂົາຕ້ອງການຮູ້ເມື່ອໃຊ້ລະຫັດນັ້ນ.

ດັ່ງນັ້ນສິ່ງທີ່ນັກຂຽນໂປລແກລມຕ້ອງການຮູ້ແທ້ໆກ່ຽວກັບການຄິດ? ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ຄືກັນກັບທຸກຄົນ: ຖ້າທ່ານບໍ່ຂຽນ, ມັນພຽງແຕ່ເບິ່ງຄືວ່າທ່ານກໍາລັງຄິດ. ນອກຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຄິດກ່ອນທີ່ຈະຂຽນລະຫັດ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງຂຽນກ່ອນທີ່ຈະຂຽນລະຫັດ. ຂໍ້ມູນສະເພາະແມ່ນສິ່ງທີ່ພວກເຮົາຂຽນກ່ອນທີ່ພວກເຮົາຈະເລີ່ມຕົ້ນການຂຽນລະຫັດ. ຕ້ອງມີຂໍ້ກໍານົດສະເພາະສໍາລັບລະຫັດໃດໆທີ່ສາມາດຖືກນໍາໃຊ້ຫຼືປ່ຽນແປງໂດຍໃຜ. ແລະ "ບາງຄົນ" ນີ້ອາດຈະກາຍເປັນຜູ້ຂຽນລະຫັດຫນຶ່ງເດືອນຫຼັງຈາກມັນຖືກຂຽນ. ຂໍ້ມູນຈໍາເພາະແມ່ນຈໍາເປັນສໍາລັບໂຄງການແລະລະບົບຂະຫນາດໃຫຍ່, ສໍາລັບຫ້ອງຮຽນ, ສໍາລັບວິທີການ, ແລະບາງຄັ້ງເຖິງແມ່ນວ່າສໍາລັບພາກສ່ວນສະລັບສັບຊ້ອນຂອງວິທີການດຽວ. ເຈົ້າຄວນຂຽນລະຫັດຫຍັງແນ່? ທ່ານຈໍາເປັນຕ້ອງອະທິບາຍສິ່ງທີ່ມັນເຮັດ, ນັ້ນແມ່ນ, ບາງສິ່ງບາງຢ່າງທີ່ສາມາດເປັນປະໂຫຍດສໍາລັບທຸກຄົນທີ່ໃຊ້ລະຫັດນີ້. ບາງຄັ້ງມັນອາດຈະມີຄວາມຈໍາເປັນທີ່ຈະລະບຸວ່າລະຫັດບັນລຸເປົ້າຫມາຍຂອງມັນໄດ້ແນວໃດ. ຖ້າພວກເຮົາຜ່ານວິທີການນີ້ໃນຫຼັກສູດ algorithms, ຫຼັງຈາກນັ້ນພວກເຮົາເອີ້ນວ່າ algorithm. ຖ້າມັນເປັນສິ່ງທີ່ພິເສດແລະໃຫມ່ກວ່າ, ພວກເຮົາເອີ້ນວ່າການອອກແບບລະດັບສູງ. ບໍ່ມີຄວາມແຕກຕ່າງຢ່າງເປັນທາງການຢູ່ທີ່ນີ້: ທັງສອງແມ່ນຕົວແບບທີ່ບໍ່ມີຕົວຕົນຂອງໂຄງການ.

ເຈົ້າຄວນຂຽນລະຫັດສະເພາະແນວໃດ? ສິ່ງທີ່ສໍາຄັນ: ມັນຄວນຈະເປັນລະດັບຫນຶ່ງສູງກວ່າລະຫັດຕົວມັນເອງ. ມັນຕ້ອງອະທິບາຍລັດແລະພຶດຕິກໍາ. ມັນຄວນຈະເຂັ້ມງວດຕາມທີ່ວຽກງານຕ້ອງການ. ຖ້າທ່ານກໍາລັງຂຽນສະເພາະຂອງວິທີການປະຕິບັດວຽກງານ, ຫຼັງຈາກນັ້ນມັນສາມາດຂຽນເປັນ pseudocode ຫຼືໃຊ້ PlusCal. ທ່ານຈໍາເປັນຕ້ອງຮຽນຮູ້ທີ່ຈະຂຽນສະເພາະໂດຍນໍາໃຊ້ຂໍ້ກໍານົດຢ່າງເປັນທາງການ. ອັນນີ້ຈະເຮັດໃຫ້ເຈົ້າມີທັກສະທີ່ຈຳເປັນເຊິ່ງຈະຊ່ວຍໃນເລື່ອງທີ່ບໍ່ເປັນທາງການ. ເຈົ້າສາມາດຮຽນຮູ້ການຂຽນສະເພາະຢ່າງເປັນທາງການໄດ້ແນວໃດ? ເມື່ອພວກເຮົາຮຽນຮູ້ການຂຽນໂປຼແກຼມ, ພວກເຮົາຂຽນໂປລແກລມແລະຫຼັງຈາກນັ້ນ debug ພວກມັນ. ສິ່ງດຽວກັນຢູ່ທີ່ນີ້: ທ່ານຈໍາເປັນຕ້ອງຂຽນຂໍ້ກໍານົດ, ກວດເບິ່ງມັນດ້ວຍຕົວກວດສອບແບບຈໍາລອງ, ແລະແກ້ໄຂຂໍ້ຜິດພາດ. TLA+ ອາດຈະບໍ່ແມ່ນພາສາທີ່ດີທີ່ສຸດສໍາລັບຂໍ້ກໍານົດທີ່ເປັນທາງການ, ແລະພາສາອື່ນອາດຈະເຫມາະສົມກັບຄວາມຕ້ອງການສະເພາະຂອງທ່ານ. ສິ່ງທີ່ດີກ່ຽວກັບ TLA+ ແມ່ນວ່າມັນເຮັດວຽກທີ່ດີໃນການສອນຄະນິດສາດ.

ວິທີການເຊື່ອມຕໍ່ສະເພາະແລະລະຫັດ? ການນໍາໃຊ້ຄໍາຄິດຄໍາເຫັນທີ່ເຊື່ອມຕໍ່ແນວຄວາມຄິດທາງຄະນິດສາດແລະການປະຕິບັດຂອງພວກເຂົາ. ຖ້າທ່ານເຮັດວຽກກັບກາຟ, ຫຼັງຈາກນັ້ນໃນລະດັບໂຄງການທ່ານຈະມີ array ຂອງ nodes ແລະ array ຂອງການເຊື່ອມຕໍ່. ດັ່ງນັ້ນທ່ານຈໍາເປັນຕ້ອງຂຽນວ່າກາຟຖືກປະຕິບັດໂດຍໂຄງສ້າງການຂຽນໂປຼແກຼມເຫຼົ່ານີ້ແນວໃດ.

ມັນຄວນຈະສັງເກດວ່າບໍ່ມີອັນໃດຂ້າງເທິງນີ້ໃຊ້ກັບຂະບວນການຂຽນລະຫັດຕົວມັນເອງ. ເມື່ອທ່ານຂຽນລະຫັດ, ນັ້ນແມ່ນ, ປະຕິບັດຂັ້ນຕອນທີສາມ, ທ່ານກໍ່ຈໍາເປັນຕ້ອງຄິດແລະຄິດໂດຍຜ່ານໂຄງການ. ຖ້າວຽກຍ່ອຍກາຍເປັນວຽກທີ່ສັບສົນຫຼືບໍ່ຈະແຈ້ງ, ທ່ານຈໍາເປັນຕ້ອງຂຽນສະເພາະສໍາລັບມັນ. ແຕ່ຂ້ອຍບໍ່ໄດ້ເວົ້າກ່ຽວກັບລະຫັດຕົວມັນເອງຢູ່ທີ່ນີ້. ທ່ານສາມາດນໍາໃຊ້ພາສາການຂຽນໂປຼແກຼມໃດກໍ່ຕາມ, ວິທີການໃດກໍ່ຕາມ, ນີ້ບໍ່ແມ່ນກ່ຽວກັບພວກມັນ. ນອກຈາກນີ້, ບໍ່ມີອັນໃດຂ້າງເທິງນີ້ກໍາຈັດຄວາມຈໍາເປັນໃນການທົດສອບ ແລະດີບັກລະຫັດຂອງເຈົ້າ. ເຖິງແມ່ນວ່າຕົວແບບທີ່ບໍ່ມີຕົວຕົນຖືກຂຽນຢ່າງຖືກຕ້ອງ, ອາດຈະມີຂໍ້ບົກພ່ອງໃນການປະຕິບັດຂອງມັນ.

ການຂຽນສະເພາະແມ່ນຂັ້ນຕອນເພີ່ມເຕີມໃນຂະບວນການຂຽນລະຫັດ. ຂໍຂອບໃຈກັບມັນ, ຄວາມຜິດພາດຈໍານວນຫຼາຍສາມາດຖືກຈັບໄດ້ດ້ວຍຄວາມພະຍາຍາມຫນ້ອຍ - ພວກເຮົາຮູ້ເລື່ອງນີ້ຈາກປະສົບການຂອງນັກຂຽນໂປລແກລມຈາກ Amazon. ດ້ວຍຄຸນລັກສະນະສະເພາະ, ຄຸນນະພາບຂອງບັນດາໂຄງການຈະສູງຂຶ້ນ. ແລ້ວເປັນຫຍັງພວກເຮົາມັກຈະໄປໂດຍບໍ່ມີພວກມັນ? ເນື່ອງຈາກວ່າການຂຽນແມ່ນຍາກ. ແຕ່ການຂຽນແມ່ນຍາກ, ເພາະວ່າສໍາລັບການນີ້ທ່ານຈໍາເປັນຕ້ອງຄິດ, ແລະການຄິດກໍ່ເປັນເລື່ອງຍາກ. ມັນງ່າຍສະເໝີທີ່ຈະທຳທ່າວ່າເຈົ້າກຳລັງຄິດ. ໃນທີ່ນີ້ທ່ານສາມາດແຕ້ມການປຽບທຽບກັບການແລ່ນ - ການແລ່ນຫນ້ອຍ, ທ່ານແລ່ນຊ້າລົງ. ທ່ານຈໍາເປັນຕ້ອງຝຶກກ້າມຊີ້ນຂອງທ່ານແລະຝຶກການຂຽນ. ມັນໃຊ້ເວລາປະຕິບັດ.

ຂໍ້ມູນຈໍາເພາະອາດຈະບໍ່ຖືກຕ້ອງ. ເຈົ້າອາດຈະເຮັດຜິດພາດຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ, ຫຼືຄວາມຕ້ອງການອາດຈະມີການປ່ຽນແປງ, ຫຼືອາດຈະຕ້ອງປັບປຸງ. ລະຫັດໃດໆກໍຕາມທີ່ໃຜໃຊ້ຕ້ອງມີການປ່ຽນແປງ, ດັ່ງນັ້ນບໍ່ດົນ ຫຼືຫຼັງຈາກນັ້ນ ຂໍ້ມູນສະເພາະຈະບໍ່ກົງກັບໂປຣແກຣມອີກຕໍ່ໄປ. ໂດຍຫລັກການແລ້ວ, ໃນກໍລະນີນີ້, ທ່ານຈໍາເປັນຕ້ອງຂຽນຂໍ້ກໍານົດໃຫມ່ແລະຂຽນລະຫັດໃຫມ່ຢ່າງສົມບູນ. ພວກເຮົາຮູ້ດີວ່າບໍ່ມີໃຜເຮັດສິ່ງນີ້. ໃນການປະຕິບັດ, ພວກເຮົາ patch ລະຫັດແລະບາງທີອາດມີການປັບປຸງສະເພາະ. ຖ້າສິ່ງນີ້ຖືກຜູກມັດທີ່ຈະເກີດຂຶ້ນໄວຫຼືຫຼັງຈາກນັ້ນ, ແລ້ວເປັນຫຍັງຂຽນສະເພາະທັງຫມົດ? ກ່ອນອື່ນ ໝົດ, ສຳ ລັບຜູ້ທີ່ຈະແກ້ໄຂລະຫັດຂອງທ່ານ, ທຸກໆ ຄຳ ເພີ່ມເຕີມໃນສະເປັກຈະມີມູນຄ່າໃນ ຄຳ, ແລະຄົນນີ້ອາດຈະເປັນເຈົ້າ. ຂ້ອຍມັກຈະເຕະຕົວເອງຍ້ອນບໍ່ສະເພາະພໍເມື່ອຂ້ອຍແກ້ໄຂລະຫັດຂອງຂ້ອຍ. ແລະຂ້ອຍຂຽນສະເພາະຫຼາຍກ່ວາລະຫັດ. ດັ່ງນັ້ນ, ເມື່ອທ່ານແກ້ໄຂລະຫັດ, ຂໍ້ກໍານົດສະເພາະສະເຫມີຕ້ອງໄດ້ຮັບການປັບປຸງ. ອັນທີສອງ, ແຕ່ລະການແກ້ໄຂລະຫັດຈະຮ້າຍແຮງຂຶ້ນ, ມັນຈະກາຍເປັນຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະອ່ານແລະຮັກສາ. ນີ້ແມ່ນການເພີ່ມຂຶ້ນຂອງ entropy. ແຕ່ຖ້າທ່ານບໍ່ເລີ່ມຕົ້ນດ້ວຍຂໍ້ກໍາຫນົດ, ທຸກໆເສັ້ນທີ່ທ່ານຂຽນຈະເປັນການແກ້ໄຂ, ແລະລະຫັດຈະໃຫຍ່ແລະຍາກທີ່ຈະອ່ານຕັ້ງແຕ່ເລີ່ມຕົ້ນ.

ດັ່ງທີ່ໄດ້ກ່າວ Eisenhower, ບໍ່​ມີ​ການ​ສູ້​ຮົບ​ໃດ​ໄດ້​ຮັບ​ໄຊ​ຊະ​ນະ​ຕາມ​ແຜນ​ການ, ແລະ​ບໍ່​ມີ​ການ​ສູ້​ຮົບ​ໄດ້​ຮັບ​ການ​ຊະ​ນະ​ໂດຍ​ບໍ່​ມີ​ແຜນ​ການ. ແລະລາວຮູ້ບາງສິ່ງບາງຢ່າງກ່ຽວກັບການສູ້ຮົບ. ມີຄວາມຄິດເຫັນວ່າການຂຽນສະເພາະແມ່ນເສຍເວລາ. ບາງຄັ້ງນີ້ແມ່ນຄວາມຈິງ, ແລະວຽກງານແມ່ນງ່າຍດາຍດັ່ງນັ້ນບໍ່ມີຈຸດທີ່ຈະຄິດມັນຜ່ານ. ແຕ່ທ່ານຄວນຈື່ໄວ້ສະເຫມີວ່າເມື່ອທ່ານຖືກແນະນໍາໃຫ້ບໍ່ຂຽນສະເພາະ, ມັນຫມາຍຄວາມວ່າທ່ານຖືກແນະນໍາໃຫ້ບໍ່ຄິດ. ແລະທ່ານຄວນຄິດກ່ຽວກັບເລື່ອງນີ້ທຸກໆຄັ້ງ. ການຄິດຜ່ານວຽກງານບໍ່ໄດ້ຮັບປະກັນວ່າທ່ານຈະບໍ່ເຮັດຜິດ. ດັ່ງທີ່ພວກເຮົາຮູ້, ບໍ່ມີໃຜ invented ເປັນ wand magic, ແລະການຂຽນໂປລແກລມເປັນວຽກງານທີ່ມີຄວາມຫຍຸ້ງຍາກ. ແຕ່ຖ້າທ່ານບໍ່ຄິດຜ່ານວຽກງານ, ທ່ານຮັບປະກັນວ່າເຮັດຜິດພາດ.

ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບ TLA+ ແລະ PlusCal ຢູ່ໃນເວັບໄຊທ໌ພິເສດ, ທ່ານສາມາດໄປທີ່ນັ້ນຈາກຫນ້າທໍາອິດຂອງຂ້ອຍ ການເຊື່ອມຕໍ່. ນັ້ນແມ່ນທັງໝົດສຳລັບຂ້ອຍ, ຂອບໃຈສຳລັບຄວາມສົນໃຈຂອງເຈົ້າ.

ກະລຸນາຈື່ໄວ້ວ່ານີ້ແມ່ນການແປ. ເມື່ອທ່ານຂຽນຄໍາເຫັນ, ຈື່ໄວ້ວ່າຜູ້ຂຽນຈະບໍ່ອ່ານມັນ. ຖ້າທ່ານຕ້ອງການສົນທະນາກັບຜູ້ຂຽນແທ້ໆ, ລາວຈະຢູ່ໃນກອງປະຊຸມ Hydra 2019, ເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 11-12 ກໍລະກົດ 2019 ທີ່ St. ປີ້ສາມາດຊື້ໄດ້ ຢູ່ໃນເວັບໄຊທ໌ທາງການ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com