ข้อบกพร่องด้านการออกแบบที่ยิ่งใหญ่ที่สุดที่คุณประสบในภาษาการเขียนโปรแกรมคืออะไร? [ปิด]

ภาษาการเขียนโปรแกรมทั้งหมดมีข้อบกพร่องด้านการออกแบบเพียงเพราะภาษาเดียวไม่สามารถสมบูรณ์แบบเช่นเดียวกับสิ่งอื่น ๆ ส่วนใหญ่ (ทั้งหมด?) นอกเหนือจากนั้นความผิดพลาดด้านการออกแบบในภาษาการเขียนโปรแกรมทำให้คุณรำคาญใจที่สุดในฐานะโปรแกรมเมอร์?

โปรดทราบว่าหากภาษา "ไม่ดี" เพียงเพราะมันไม่ได้ออกแบบมาสำหรับสิ่งที่เฉพาะเจาะจงไม่ใช่ข้อบกพร่องด้านการออกแบบ แต่เป็นคุณสมบัติของการออกแบบดังนั้นอย่าเขียนรายการภาษาที่น่ารำคาญ หากภาษานั้นได้รับการ illsuited สำหรับสิ่งที่มันถูกออกแบบมาสำหรับนั่นเป็นข้อบกพร่องในการออกแบบ การดำเนินการสิ่งที่เฉพาะเจาะจงและภายใต้ประทุนสิ่งที่ไม่นับรวม

หนึ่ง annoyances ใหญ่ของฉันเป็นวิธีswitchกรณีในภาษา C breakที่ได้มาจากการเริ่มต้นที่จะลดลงไปจนถึงกรณีต่อไปถ้าคุณลืมที่จะใช้ ฉันเข้าใจว่าสิ่งนี้มีประโยชน์ในรหัสระดับต่ำมาก (เช่นอุปกรณ์ของดัฟฟ์ ) แต่มักจะไม่เหมาะสมสำหรับรหัสระดับแอปพลิเคชันและเป็นแหล่งที่มาของข้อผิดพลาดในการเขียนโค้ดทั่วไป

ฉันจำได้เมื่อประมาณปี 1995 เมื่อฉันอ่านรายละเอียดของ Java เป็นครั้งแรกเมื่อฉันไปถึงส่วนที่เกี่ยวกับswitchข้อความที่ฉันรู้สึกผิดหวังมากที่พวกเขายังคงรักษาพฤติกรรมการตกผ่านที่เป็นค่าเริ่มต้น นี่ทำให้switchเป็นที่สรรเสริญgotoด้วยชื่ออื่น

ฉันไม่เคยชอบการใช้=งานที่ได้รับมอบหมายและ==สำหรับการทดสอบความเท่าเทียมกันในภาษาที่ได้รับจาก C โอกาสที่จะเกิดความสับสนและข้อผิดพลาดนั้นสูงเกินไป และอย่าทำให้ฉันเริ่มต้นด้วย===Javascript

จะดีกว่า:=สำหรับการมอบหมายและ=การทดสอบความเท่าเทียมกัน ความหมายอาจเหมือนกันทุกวันนี้โดยที่การมอบหมายนั้นเป็นนิพจน์ที่ให้คุณค่า

ตัวเลือก+ใน Javascript สำหรับการเพิ่มและการต่อสตริงเป็นข้อผิดพลาดที่น่ากลัว เนื่องจากไม่มีการพิมพ์ค่าสิ่งนี้จะนำไปสู่กฎไบเซนไทน์ที่กำหนดว่า+จะเพิ่มหรือต่อกันขึ้นอยู่กับเนื้อหาที่แน่นอนของแต่ละตัวถูกดำเนินการ

มันจะเป็นเรื่องง่ายในการเริ่มต้นที่จะแนะนำผู้ประกอบการรายใหม่อย่างสมบูรณ์เช่นการ$ต่อสตริง

ฉันพบว่า Javascript เป็นค่าเริ่มต้นสำหรับทั่วโลกสำหรับปัญหาสำคัญและมักจะเป็นแหล่งของข้อบกพร่องหากคุณไม่ใช้ JSLint หรือสิ่งที่คล้ายกัน

ตัวประมวลผลล่วงหน้าใน C และ C ++ เป็น kludge ขนาดใหญ่สร้าง abstractions ที่รั่วไหลเหมือน sieves กระตุ้นสปาเก็ตตี้โค้ดผ่านทาง#ifdefคำแถลงของหนูและต้องการALL_CAPSชื่อที่อ่านไม่ได้อย่างน่ากลัวเพื่อแก้ไขข้อ จำกัด ของมัน รากของปัญหาเหล่านี้คือมันทำงานในระดับข้อความมากกว่าระดับไวยากรณ์หรือความหมาย มันควรจะถูกแทนที่ด้วยคุณสมบัติภาษาจริงสำหรับกรณีการใช้งานที่หลากหลาย ต่อไปนี้เป็นตัวอย่างบางส่วนแม้ว่าบางส่วนจะได้รับการแก้ไขใน C ++, C99 หรือไม่เป็นทางการ แต่เป็นส่วนขยายมาตรฐานแบบพฤตินัย :

• #include ควรถูกแทนที่ด้วยระบบโมดูลจริง

• ฟังก์ชั่นแบบอินไลน์และแม่แบบ / ข้อมูลทั่วไปสามารถแทนที่กรณีการเรียกใช้ฟังก์ชันส่วนใหญ่

• คุณลักษณะค่าคงที่เวลาแสดง / คอมไพล์บางชนิดสามารถใช้สำหรับการประกาศค่าคงที่ดังกล่าว ส่วนขยาย D ของ enumทำงานได้ดีที่นี่

• มาโครระดับแผนผังไวยากรณ์ที่แท้จริงสามารถแก้ปัญหากรณีใช้เบ็ดเตล็ดได้มากมาย

• String mixinsสามารถใช้สำหรับกรณีการใช้การฉีดโค้ด

• static ifหรือversionงบสามารถใช้สำหรับการรวบรวมเงื่อนไข

อาจมีรายการข้อผิดพลาดหลายร้อยรายการในหลายร้อยภาษา แต่ IMO ไม่ใช่แบบฝึกหัดที่มีประโยชน์จากมุมมองการออกแบบภาษา

ทำไม?

เพราะสิ่งที่จะเป็นความผิดพลาดในภาษาหนึ่งจะไม่เป็นความผิดพลาดในภาษาอื่น ตัวอย่างเช่น

• การทำให้ C เป็นภาษาที่ได้รับการจัดการ (เช่นเก็บรวบรวมขยะ) หรือการ จำกัด ประเภทดั้งเดิมจะ จำกัด ประโยชน์ของมันเป็นภาษาระดับต่ำกึ่งพกพา
• การเพิ่มการจัดการหน่วยความจำแบบ C ไปยัง Java (ตัวอย่างเช่นเพื่อจัดการกับข้อกังวลด้านประสิทธิภาพ) จะทำให้เกิดปัญหา

มีเป็นบทเรียนที่จะเรียนรู้ แต่บทเรียนที่ตัดไม่ค่อยชัดเจนและเข้าใจพวกเขาคุณต้องเข้าใจทางเทคนิคไม่ชอบการค้า ... และบริบททางประวัติศาสตร์ (ตัวอย่างเช่นการใช้งานจาวาแบบทั่วไปที่ยุ่งยากนั้นเป็นผลมาจากข้อกำหนดทางธุรกิจที่สำคัญเพื่อรักษาความเข้ากันได้ย้อนหลัง)

IMO ถ้าคุณจริงจังกับการออกแบบภาษาใหม่คุณจำเป็นต้องใช้ภาษาที่มีอยู่หลากหลาย (และเรียนภาษาประวัติศาสตร์) และทำให้คุณนึกถึงสิ่งที่ผิดพลาด และคุณต้องจำไว้ว่าภาษาเหล่านี้แต่ละภาษาได้รับการออกแบบในบริบททางประวัติศาสตร์ที่เฉพาะเจาะจงเพื่อเติมเต็มความต้องการเฉพาะ

หากมีบทเรียนทั่วไปที่ต้องเรียนรู้พวกเขาจะอยู่ในระดับ "เมตา":

• คุณไม่สามารถออกแบบภาษาการเขียนโปรแกรมที่เหมาะสำหรับวัตถุประสงค์ทั้งหมด
• คุณไม่สามารถหลีกเลี่ยงการทำผิดพลาดได้ ... โดยเฉพาะเมื่อมองจากด้านหลัง
• ข้อผิดพลาดหลายอย่างเจ็บปวดที่จะแก้ไข ... สำหรับผู้ใช้ภาษาของคุณ
• คุณต้องคำนึงถึงภูมิหลังและทักษะของกลุ่มเป้าหมายของคุณ เช่นโปรแกรมเมอร์ที่มีอยู่
• คุณไม่สามารถทำให้ทุกคนพอใจ

CและC ++ : จำนวนเต็มทั้งหมดนั้นไม่ได้มีความหมายอะไรเลย

charโดยเฉพาะอย่างยิ่ง มันเป็นข้อความหรือเป็นจำนวนเต็มเล็กน้อย หากเป็นข้อความแสดงว่าเป็นอักขระ "ANSI" หรือหน่วยรหัส UTF-8 หรือไม่ หากเป็นจำนวนเต็มจะมีการลงชื่อหรือไม่ได้ลงชื่อหรือไม่?

int มีวัตถุประสงค์เพื่อเป็นจำนวนเต็มขนาดดั้งเดิม "แต่ในระบบ 64 บิตไม่ใช่

longintอาจหรือไม่อาจมีขนาดใหญ่กว่า มันอาจจะใช่หรือไม่ใช่ขนาดของพอยน์เตอร์ มันเป็นการตัดสินใจตามอำเภอใจในส่วนของผู้เขียนคอมไพเลอร์ไม่ว่าจะเป็นแบบ 32 บิตหรือ 64 บิต

ภาษาของปี 1970 แน่นอน ก่อน Unicode ก่อนคอมพิวเตอร์ 64 บิต

null.

ประดิษฐ์โทนี่โฮร์เรียกมันว่า "ความผิดพลาดพันล้านดอลล่า"

มันได้รับการแนะนำใน ALGOL ในยุค 60 และมีอยู่ในภาษาโปรแกรมส่วนใหญ่ที่ใช้กันทั่วไปในปัจจุบัน

ทางเลือกที่ดีกว่าที่ใช้ในภาษาเช่น OCaml และ Haskell เป็นบางที แนวคิดทั่วไปคือการอ้างอิงวัตถุไม่สามารถเป็นโมฆะ / ว่างเปล่า / ไม่มีอยู่เว้นแต่ว่ามีข้อบ่งชี้ชัดเจนว่าอาจเป็นเช่นนั้น

(แม้ว่าโทนี่จะเก่งในเรื่องความสุภาพของเขา แต่ฉันคิดว่าเกือบทุกคนจะทำผิดพลาดเหมือนกันและเขาเพิ่งจะเป็นคนแรก)

ฉันรู้สึกว่าคนที่ออกแบบ PHP ไม่ได้ใช้แป้นพิมพ์ปกติพวกเขาไม่ได้ใช้คีย์บอร์ด colemak เพราะพวกเขาควรจะรู้ว่าพวกเขากำลังทำอะไรอยู่

ฉันเป็นนักพัฒนา PHP PHP ไม่สนุกที่จะพิมพ์

Who::in::their::right::mind::would::do::this()? ::ผู้ประกอบการต้องมีการเปลี่ยนแปลงการถือครองและจากนั้นกดปุ่มสอง สิ่งสิ้นเปลืองพลังงาน

Although-> this-> ล์> not-> much-> ดีกว่า ซึ่งยังต้องใช้การกดปุ่มสามครั้งโดยมีการเลื่อนอยู่ระหว่างสัญลักษณ์ทั้งสอง

$last = $we.$have.$the.$dumb.'$'.$character. เครื่องหมายดอลลาร์นั้นถูกใช้เป็นจำนวนมากและต้องได้รับรางวัลซึ่งทอดยาวไปถึงส่วนบนสุดของแป้นพิมพ์รวมถึงการกดปุ่ม Shift

ทำไมพวกเขาถึงออกแบบ PHP ไม่ให้ใช้คีย์ที่พิมพ์เร็วกว่ากัน? เหตุใดwe.do.this()vars จึงไม่สามารถเริ่มต้นด้วยคีย์ที่ต้องใช้การกดเพียงปุ่มเดียว - หรือไม่ใช่เลย (JavaScript) และเพียงแค่กำหนด vars ทั้งหมดล่วงหน้า (เหมือนที่ฉันต้องทำเพื่อ E_STRICT)!

ฉันไม่ใช่คนพิมพ์ดีดช้า - แต่นี่เป็นเพียงตัวเลือกการออกแบบที่อ่อนแอ

การใช้งานของสก์ท็อปแรงบันดาลใจในรูปแบบภายในasp.net

มันมักจะรู้สึกเหลวไหลและไปในทางหรือวิธีที่เว็บใช้งานได้จริง โชคดีที่ asp.net-mvc ไม่ได้ประสบในลักษณะเดียวกันแม้ว่าจะให้เครดิตกับ Ruby และอื่น ๆ สำหรับแรงบันดาลใจนั้น

สำหรับฉันมันคือPHPขาดการตั้งชื่อและการโต้แย้งการสั่งการประชุมในห้องสมุดมาตรฐานของมัน

ถึงแม้ว่าความจำเป็นของJASSในการลบล้างการอ้างอิงหลังจากที่วัตถุอ้างอิงถูกปล่อย / ลบออก (หรือการอ้างอิงจะรั่วและหน่วยความจำหลายไบต์จะหายไป) นั้นร้ายแรงกว่า แต่เนื่องจาก JASS เป็นภาษาวัตถุประสงค์เดียวจึงไม่สำคัญ

ข้อบกพร่องในการออกแบบที่ยิ่งใหญ่ที่สุดที่ฉันเผชิญคือหลามนั้นไม่ได้ออกแบบมาเช่น python 3.x เพื่อเริ่มต้น

Array สลายตัวใน C และต่อมา C ++

ประเภทดั้งเดิมใน Java

พวกเขาทำลายหลักการที่ว่าทุกอย่างเป็นลูกหลานของjava.lang.Objectซึ่งจากมุมมองทางทฤษฎีนำไปสู่ความซับซ้อนเพิ่มเติมของการกำหนดภาษาและจากมุมมองการปฏิบัติพวกเขาใช้คอลเลกชันที่น่าเบื่ออย่างยิ่ง

Autoboxing ช่วยบรรเทาข้อเสียในทางปฏิบัติ แต่ด้วยค่าใช้จ่ายในการทำสเปคที่ซับซ้อนยิ่งขึ้นและแนะนำกล้วยผิวที่มีไขมันขนาดใหญ่: ตอนนี้คุณสามารถได้รับข้อยกเว้นตัวชี้ null จากสิ่งที่ดูเหมือนการดำเนินการทางคณิตศาสตร์อย่างง่าย

ฉันรู้ว่า Perl ดีที่สุดดังนั้นฉันจะเลือกมัน

Perl ลองหลายความคิด บางคนดี บางคนก็ไม่ดี บางคนเป็นต้นฉบับและไม่ได้คัดลอกอย่างกว้างขวางด้วยเหตุผลที่ดี

หนึ่งคือแนวคิดของบริบท - การเรียกใช้ฟังก์ชันทุกครั้งเกิดขึ้นในรายการหรือบริบทสเกลาร์และสามารถทำสิ่งที่แตกต่างอย่างสิ้นเชิงในแต่ละบริบท ขณะที่ผมชี้ให้เห็นที่http://use.perl.org/~btilly/journal/36756นี้มีความซับซ้อนทุก API และมักจะนำไปสู่ปัญหาการออกแบบที่ละเอียดอ่อนในรหัส Perl

ต่อไปคือความคิดของการผูกไวยากรณ์และชนิดข้อมูลอย่างสมบูรณ์ สิ่งนี้นำไปสู่การประดิษฐ์ tie เพื่ออนุญาตให้ออบเจกต์ปลอมเป็นชนิดข้อมูลอื่น (นอกจากนี้คุณยังสามารถใช้เอฟเฟ็กต์แบบเดียวกันได้ แต่การผูกเป็นวิธีการทั่วไปใน Perl)

ข้อผิดพลาดทั่วไปอีกอย่างที่เกิดขึ้นในหลายภาษาคือเริ่มจากการกำหนดขอบเขตแบบไดนามิกแทนที่จะเป็นศัพท์ ยากที่จะคืนการตัดสินใจการออกแบบนี้ในภายหลังและนำไปสู่หูดที่ติดทนนาน คำอธิบายคลาสสิกของหูดผู้ที่อยู่ใน Perl เป็นhttp://perl.plover.com/FAQs/Namespaces.html โปรดทราบว่าสิ่งนี้ถูกเขียนก่อน Perl เพิ่มourตัวแปรและstaticตัวแปร

คนไม่เห็นด้วยอย่างถูกต้องตามกฎหมายเกี่ยวกับการพิมพ์แบบคงที่และแบบไดนามิก ฉันชอบการพิมพ์แบบไดนามิก อย่างไรก็ตามมันเป็นสิ่งสำคัญที่จะมีโครงสร้างเพียงพอที่จะให้มีการพิมพ์ผิด Perl 5 ทำผลงานได้ดีด้วยความเข้มงวด แต่ Perl 1-4 ผิดพลาด ภาษาอื่น ๆ อีกหลายภาษามีตัวตรวจสอบที่เป็นขุยซึ่งทำสิ่งเดียวกันกับที่เข้มงวด ตราบใดที่คุณยังเก่งเกี่ยวกับการบังคับใช้การตรวจสอบผ้าสำลีก็เป็นที่ยอมรับได้

หากคุณกำลังมองหาความคิดที่ไม่ดีเพิ่มเติม (จำนวนมาก) เรียนรู้ PHP และศึกษาประวัติของมัน ความผิดพลาดในอดีตที่ฉันโปรดปราน (แก้ไขเมื่อนานมาแล้วเพราะทำให้เกิดช่องโหว่ด้านความปลอดภัยจำนวนมาก) เป็นค่าเริ่มต้นที่อนุญาตให้ทุกคนตั้งค่าตัวแปรใด ๆ โดยส่งผ่านพารามิเตอร์แบบฟอร์ม แต่นั่นก็ยังห่างไกลจากความผิดพลาดเพียงอย่างเดียว

ความคลุมเครือของ JavaScript สำหรับบล็อคโค้ดและตัวอักษรของวัตถุ

  {a:b}

อาจเป็นโค้ดบล็อกซึ่งaเป็นเลเบลและbเป็นนิพจน์ หรือมันสามารถกำหนดวัตถุที่มีคุณลักษณะaที่มีค่าb

ฉันจะกลับไปที่ฟอร์แทรนและการไม่รู้สึกถึงช่องว่าง

มันแผ่ซ่านสเปค ENDบัตรจะต้องมีการกำหนดให้เป็นบัตรที่มี 'E' เป็น 'N' และ 'D' ในการสั่งซื้อในคอลัมน์ที่ 7-72 และไม่มี nonblanks อื่น ๆ มากกว่าบัตรที่มี "END" ในที่เหมาะสม คอลัมน์และไม่มีอะไรอื่น

มันนำไปสู่ความสับสนทางวากยสัมพันธ์ง่าย DO 100 I = 1, 10เป็นคำสั่งการควบคุมวงในขณะที่DO 100 I = 1. 10เป็นคำสั่งที่ได้รับมอบหมายมูลค่า 1.1 DO10Iตัวแปรที่เรียกว่า (ความจริงที่ว่าตัวแปรสามารถสร้างขึ้นได้โดยไม่มีการประกาศประเภทของพวกเขาขึ้นอยู่กับตัวอักษรตัวแรกของพวกเขามีส่วนร่วมในเรื่องนี้) ซึ่งแตกต่างจากภาษาอื่น ๆ ไม่มีวิธีการใช้ช่องว่างเพื่อแยกโทเค็นออก

นอกจากนี้ยังอนุญาตให้ผู้อื่นเขียนโค้ดที่สับสนได้ มีเหตุผลที่คุณสมบัติของ FORTRAN นี้ไม่เคยซ้ำกันอีกเลย

หนึ่งในปัญหาที่ใหญ่ที่สุดของ BASIC คือการขาดวิธีการที่กำหนดไว้อย่างดีเพื่อขยายภาษานอกเหนือจากสภาพแวดล้อมในยุคแรก ๆ ซึ่งนำไปสู่การใช้งานที่เข้ากันไม่ได้อย่างสมบูรณ์ (และความพยายามโพสต์จริง

เกือบทุกภาษาจะงอเข้ากับการใช้งานทั่วไปโดยโปรแกรมเมอร์ที่บ้า มันเป็นการดีกว่าที่จะวางแผนสำหรับการใช้งานวัตถุประสงค์ทั่วไปนั้นในตอนต้นในกรณีที่ความคิดบ้าๆ

ฉันเชื่อใน DSL (ภาษาเฉพาะโดเมน) และสิ่งหนึ่งที่ฉันให้ความสำคัญกับภาษาคือถ้ามันอนุญาตให้ฉันกำหนด DSL ที่อยู่ด้านบนของมัน

ใน Lisp มีมาโคร - คนส่วนใหญ่คิดว่านี่เป็นสิ่งที่ดีเช่นเดียวกับฉัน

ใน C และ C ++ มีมาโคร - คนบ่นเกี่ยวกับพวกเขา แต่ฉันสามารถใช้พวกเขาเพื่อกำหนด DSL

ในจาวาพวกเขาถูกละทิ้ง (และดังนั้นใน C #) และการขาดของพวกเขาถูกประกาศให้เป็นคุณธรรม แน่ใจว่ามันจะช่วยให้คุณมี IntelliSense แต่กับผมว่าเป็นเพียงผลงาน ในการทำ DSL ของฉันฉันต้องขยายด้วยตัวเอง มันเป็นความเจ็บปวดและมันทำให้ฉันดูเหมือนโปรแกรมเมอร์ที่ไม่ดีถึงแม้ว่ามันจะช่วยให้ฉันสามารถทำสิ่งต่าง ๆ ได้มากขึ้นด้วยรหัสน้อยกว่า

งบในทุกภาษาที่มีพวกเขา พวกเขาไม่ทำอะไรที่คุณไม่สามารถทำได้ด้วยการแสดงออกและป้องกันคุณจากการทำสิ่งต่างๆมากมาย การมีอยู่ของ?:ผู้ประกอบการที่ประกอบไปด้วยเป็นตัวอย่างหนึ่งของการพยายามหลีกเลี่ยงพวกมัน ใน JavaScript พวกมันน่ารำคาญเป็นพิเศษ:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

สำหรับฉันมันเป็นปัญหาการออกแบบที่ทำให้เกิดภัยพิบัติทุกภาษาที่มาจากภาษา C กล่าวคือ " ห้อยต่องแต่งอย่างอื่น " ปัญหาทางไวยากรณ์นี้ควรได้รับการแก้ไขใน C ++ แต่ถูกนำไปใช้กับ Java และ C #

ฉันคิดว่าคำตอบทั้งหมดชี้ไปที่ความล้มเหลวเดียวของภาษากระแสหลักจำนวนมาก:

ไม่มีวิธีการเปลี่ยนภาษาหลักโดยไม่มีผลต่อความเข้ากันได้ย้อนหลัง

ถ้านี่ถูกแก้ไขแล้วกริปเปอร์อื่น ๆ ทั้งหมดนั้นสามารถแก้ไขได้

แก้ไข

สิ่งนี้สามารถแก้ไขได้ในห้องสมุดโดยมีเนมสเปซที่แตกต่างกันและคุณสามารถคิดทำสิ่งที่คล้ายกับแกนหลักของภาษาส่วนใหญ่แม้ว่านี่อาจหมายความว่าคุณต้องสนับสนุนคอมไพเลอร์ / ล่ามหลายตัว

ท้ายที่สุดฉันไม่คิดว่าฉันรู้วิธีแก้ปัญหาในลักษณะที่เป็นที่น่าพอใจโดยสิ้นเชิง แต่นั่นไม่ได้หมายความว่าไม่มีวิธีแก้ปัญหาหรือไม่สามารถทำได้มากกว่านี้

จำนวนเต็มทางคณิตศาสตร์ที่เงียบของ Java ล้น

ทั้ง Java และ C # มีปัญหาที่น่ารำคาญกับระบบประเภทเนื่องจากความต้องการที่จะรักษาความเข้ากันได้ย้อนหลังในขณะที่เพิ่มข้อมูลทั่วไป Java ไม่ชอบผสมทั่วไปและอาร์เรย์ C # ไม่อนุญาตลายเซ็นที่มีประโยชน์เพราะคุณไม่สามารถใช้ประเภทค่าเป็นขอบเขต

เป็นตัวอย่างของสิ่งหลังพิจารณาว่า

สาธารณะคงที่ T Parse <T> (ประเภท <T> ประเภทสตริงสตริง) ที่ T: Enum

วัตถุคงที่สาธารณะแยกวิเคราะห์ (ประเภทประเภทสตริง STR)

MyEnum e = Enum.Parse (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Parse (typeof (MyEnum), str);

tl; dr: คิดเกี่ยวกับตัวแปรหลายรูปแบบเมื่อคุณเริ่มออกแบบระบบชนิดของคุณไม่ใช่หลังจากที่คุณเผยแพร่เวอร์ชัน 1

ฉันรู้สึกว่าฉันเปิดตัวเองขึ้นมาเพื่อลุกเป็นไฟ แต่ฉันเกลียดความสามารถในการส่งชนิดข้อมูลแบบเก่าโดยอ้างอิงใน C ++ ฉันเกลียดที่จะผ่านประเภทที่ซับซ้อนได้เพียงเล็กน้อยโดยการอ้างอิง ถ้าฉันกำลังดูฟังก์ชั่น:

void foo()
{
    int a = 8;
    bar(a);
}

จากจุดโทรไม่มีวิธีที่จะบอกว่าbarซึ่งอาจถูกกำหนดในไฟล์ที่แตกต่างอย่างสิ้นเชิงคือ:

void bar(int& a)
{
    a++;
}

บางคนอาจโต้แย้งว่าการทำอะไรแบบนี้อาจเป็นการออกแบบซอฟต์แวร์ที่ไม่ดีและไม่โทษภาษา แต่ฉันไม่ชอบภาษาที่ให้คุณทำสิ่งนี้ในตอนแรก การใช้ตัวชี้และการโทร

bar(&a);

สามารถอ่านได้มากขึ้น

แก้ไข

เมื่อฉันเรียนภาษาโคบอลคำสั่ง ALTERยังคงเป็นส่วนหนึ่งของมาตรฐาน สรุปคำสั่งนี้จะช่วยให้คุณสามารถแก้ไขการเรียกขั้นตอนในระหว่างรันไทม์

อันตรายคือคุณสามารถใส่คำสั่งนี้ในส่วนที่คลุมเครือของรหัสซึ่งไม่ค่อยเข้าถึงและมีโอกาสที่จะเปลี่ยนการไหลของโปรแกรมที่เหลือทั้งหมด ด้วยคำสั่ง ALTER หลายรายการคุณไม่สามารถรู้ได้เลยว่าโปรแกรมของคุณกำลังทำอะไรอยู่

อาจารย์มหาวิทยาลัยของฉันอย่างเด่นชัดกล่าวว่าถ้าเขาเคยเห็นคำพูดนั้นในโปรแกรมใด ๆ ของเราเขาจะล้มเหลวเราโดยอัตโนมัติ

บาปที่เลวร้ายที่สุดของภาษาโปรแกรมไม่ได้ถูกกำหนดไว้อย่างดี กรณีที่ฉันจำได้คือ C ++ ซึ่งในต้นกำเนิด:

1. มีการกำหนดอย่างไม่ดีดังนั้นคุณจึงไม่สามารถรับโปรแกรมเพื่อคอมไพล์และรันได้โดยทำตามหนังสือหรือตัวอย่าง
2. เมื่อคุณปรับแต่งโปรแกรมเพื่อคอมไพล์และรันภายใต้คอมไพเลอร์และระบบปฏิบัติการเดียวคุณจะต้องเริ่มต้นใหม่หากคุณเปลี่ยนคอมไพเลอร์หรือแพลตฟอร์ม

ดังที่ฉันจำได้ว่ามันใช้เวลาประมาณหนึ่งทศวรรษกว่าจะได้รับการนิยาม C ++ ที่ดีพอที่จะทำให้มันเชื่อถือได้อย่างมืออาชีพเหมือนกับ C. มันเป็นสิ่งที่ไม่ควรเกิดขึ้นอีก

มีอะไรอีกที่ฉันคิดว่าเป็นบาป (มันควรจะเป็นคำตอบที่ต่างออกไปหรือไม่) กำลังมีวิธี "ดีที่สุด" มากกว่าหนึ่งอย่างในการทำงานทั่วไป เป็นกรณีของ (อีกครั้ง) C ++, Perl, และ Ruby

คลาสใน C ++ เป็นรูปแบบการออกแบบที่บังคับในภาษา

ไม่มีความแตกต่างระหว่างรันไทม์ระหว่าง struct และคลาสและมันสับสนอย่างมากที่จะเข้าใจว่าอะไรคือข้อดีของการเขียนโปรแกรมที่แท้จริงของ "การซ่อนข้อมูล" ที่ฉันต้องการวางไว้ที่นั่น

ฉันจะถูกลดระดับลงสำหรับสิ่งนั้น แต่อย่างไรก็ตามคอมไพเลอร์ C ++ ยากที่จะเขียนภาษานี้ให้ความรู้สึกเหมือนสัตว์ประหลาด

แม้ว่าทุกภาษาจะมีความผิดปกติ แต่ก็ไม่มีใครรำคาญเมื่อคุณรู้เกี่ยวกับพวกเขา ยกเว้นคู่นี้:

ไวยากรณ์ที่ซับซ้อนพร้อมกับ wordy APIs

นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งภาษาเช่น Objective-C ไม่เพียง แต่เป็นไวยากรณ์ที่ซับซ้อนอย่างท่วมท้น แต่ API ใช้ชื่อฟังก์ชั่นเช่น:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

ฉันทุกคนเป็นคนชัดเจนและไม่คลุมเครือ แต่มันไร้สาระ ทุกครั้งที่ฉันนั่งกับ xcode ฉันรู้สึกเหมือน n00b และมันน่าผิดหวังจริงๆ

1. ตัวอักษรที่ลงนามใน C - สิ่งที่น่ารังเกียจที่คิดค้นขึ้นเพื่อให้นักคณิตศาสตร์มีคอลเล็กชั่นชิ้นเล็ก ๆ
2. การใช้เคสเพื่อพกพาเนื้อหาเชิงความหมาย - อีกครั้งสำหรับนักคณิตศาสตร์ที่ไม่ต้องการพูดคุยและไม่มีพื้นที่เพียงพอสำหรับสูตรของพวกเขา
3. Let / Plain assignment vs. Set assignment ในภาษาถิ่นพื้นฐาน - ไม่มีนักคณิตศาสตร์คนใดเข้ามาเกี่ยวข้องเลย