การเพิ่มความซับซ้อนของระบบส่งผลต่อโปรแกรมเมอร์รุ่นต่อ ๆ ไปอย่างไร?

ในฐานะโปรแกรมเมอร์ "ใหม่" (ฉันเขียนบรรทัดของรหัสในปี 2009 เป็นครั้งแรก) ฉันสังเกตว่ามันค่อนข้างง่ายที่จะสร้างโปรแกรมที่แสดงองค์ประกอบที่ค่อนข้างซับซ้อนในปัจจุบันด้วยสิ่งต่าง ๆ เช่น. NET Framework การสร้างส่วนต่อประสานที่มองเห็นหรือการเรียงลำดับรายการสามารถทำได้ด้วยคำสั่งน้อยมากในขณะนี้

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

การสร้างโปรแกรมที่ใช้หน่วยความจำนั้นมีความจำเป็น 40/50 ปีที่แล้วเพราะมีหน่วยความจำไม่เพียงพอและมีราคาแพงดังนั้นโปรแกรมเมอร์ส่วนใหญ่จึงให้ความสำคัญกับชนิดข้อมูลและวิธีการจัดการตัวประมวลผล ทุกวันนี้บางคนอาจโต้แย้งว่าเนื่องจากกำลังการประมวลผลที่เพิ่มขึ้นและหน่วยความจำที่มีอยู่ความกังวลเหล่านั้นจึงไม่ใช่เรื่องสำคัญ

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

ไม่จำเป็นเพียงเพราะมีกำลังการประมวลผลและหน่วยความจำเพิ่มขึ้น

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

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

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

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

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

คุณคิดว่าโปรแกรมเมอร์อายุน้อยจะได้รับประโยชน์จากการเรียนรู้การเขียนโปรแกรมระดับต่ำมากขึ้นก่อนที่จะสำรวจขอบเขตของห้องสมุดที่กว้างขวางหรือไม่?

คุณให้ความสำคัญกับก่อนดังนั้นฉันต้องตอบคำถามของคุณในเชิงลบ ฉันกำลังช่วยเพื่อนเก่า 12 ปีเรียนรู้ที่จะเขียนโปรแกรมตอนนี้และคุณควรที่จะเชื่อว่าฉันเริ่มต้นพวกเขาในProcessing.jsไม่ใช่ x86 Assembler หากคุณเริ่มโปรแกรมเมอร์หนุ่มในสิ่งที่Processing.jsพวกเขาจะเขียนเกม shoot-em-up ของตนเองในเวลาประมาณแปดชั่วโมง หากคุณเริ่มต้นพวกเขาในแอสเซมเบลอร์พวกเขาจะคูณสามตัวเลขเข้าด้วยกันในเวลาประมาณแปดชั่วโมง ท่านใดที่คิดว่ามีแนวโน้มที่จะดึงดูดความสนใจของโปรแกรมเมอร์อายุน้อยกว่า?

ตอนนี้ถ้าคำถามคือ "โปรแกรมเมอร์ที่เข้าใจเลเยอร์ n ของเค้กได้ประโยชน์จากการเข้าใจเลเยอร์ n - 1 หรือไม่?" คำตอบคือใช่ แต่นั่นไม่ขึ้นกับอายุหรือประสบการณ์ เป็นกรณีที่คุณสามารถปรับปรุงการเขียนโปรแกรมระดับสูงของคุณโดยการทำความเข้าใจกับนามธรรมพื้นฐาน

ฉันมีความคิดเกี่ยวกับเรื่องนี้และฉันใส่ไว้ในหนังสือ 20 ปีที่ผ่านมา มันพิมพ์ออกมานาน แต่คุณยังสามารถใช้สำเนาใน Amazonได้

หนึ่งในคำตอบที่ง่ายสำหรับคำถามของคุณเป็นเช่นเดิมเป็นอริสโตเติล: ธรรมชาติ abhors สูญญากาศ ซอฟท์แวร์ก็จะช้าลงเรื่อย ๆ

สิ่งที่ฉันเสนอก็คือทฤษฎีสารสนเทศและความเกี่ยวข้องโดยตรงกับซอฟต์แวร์เป็นส่วนหนึ่งของการศึกษาวิทยาศาสตร์คอมพิวเตอร์ มันเป็นเพียงการสอนในขณะนี้ถ้าในทุกวิถีทางสัมผัส

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

ในอีกทางหนึ่งการผลิตของโปรแกรมเมอร์สามารถเข้าใจในเงื่อนไขที่คล้ายกันโดยใช้ทฤษฎีข้อมูล Kolmogorov อินพุตเป็นโครงสร้างแนวคิดเชิงสัญลักษณ์ในหัวของคุณและผลลัพธ์คือข้อความโปรแกรมที่ออกมาทางปลายนิ้วของคุณ กระบวนการเขียนโปรแกรมเป็นช่องทางระหว่างทั้งสอง เมื่อเสียงเข้าสู่กระบวนการมันจะสร้างโปรแกรมที่ไม่สอดคล้องกัน (ข้อบกพร่อง) หากข้อความของโปรแกรมเอาต์พุตมีความซ้ำซ้อนเพียงพอก็สามารถอนุญาตให้จับและแก้ไขข้อบกพร่อง (การตรวจจับข้อผิดพลาดและการแก้ไข) อย่างไรก็ตามถ้ามันซ้ำซ้อนเกินไปมันมีขนาดใหญ่เกินไปและมีขนาดที่ใหญ่มากบวกกับอัตราความผิดพลาดทำให้เกิดการแนะนำบั๊ก จากเหตุผลนี้ฉันใช้เวลาส่วนหนึ่งของหนังสือที่แสดงวิธีการปฏิบัติต่อการเขียนโปรแกรมเป็นกระบวนการออกแบบภาษาโดยมีเป้าหมายในการกำหนดภาษาเฉพาะโดเมนที่เหมาะสมกับความต้องการ เราจ่ายค่าบริการ lip ให้กับโดเมนเฉพาะภาษาในการศึกษา CS แต่อีกครั้งมันเป็นวงสัมผัส

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

เราไม่ได้รับสิ่งนี้ สำหรับการพูดคุยที่กล้าหาญของเราเกี่ยวกับการออกแบบระบบซอฟต์แวร์อัตราส่วนของโค้ดต่อความต้องการกำลังเพิ่มมากขึ้นเรื่อย ๆ

เป็นความจริงเรามีห้องสมุดที่มีประโยชน์มาก อย่างไรก็ตามฉันคิดว่าเราควรระมัดระวังอย่างมากเกี่ยวกับสิ่งที่เป็นนามธรรม เราไม่ควรคิดว่าถ้า B สร้างต่อ A และมันก็ดีถ้า C สร้างบน B จะดีกว่า ฉันเรียกมันว่าปรากฏการณ์ "เจ้าหญิงและถั่ว" การซ้อนเลเยอร์ที่อยู่ด้านบนของสิ่งที่ลำบากไม่จำเป็นต้องแก้ไข

เพื่อยุติการโพสต์ที่ยาวนานฉันได้พัฒนารูปแบบการเขียนโปรแกรม (ซึ่งบางครั้งทำให้ฉันมีปัญหา) ที่

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

สิ่งที่เป็นนามธรรมในระดับสูงมีความสำคัญต่อการบรรลุความก้าวหน้าอย่างต่อเนื่องในการคำนวณ

ทำไม? เพราะมนุษย์สามารถเก็บความรู้ไว้ในหัวได้ทุกเวลา ระบบที่ทันสมัยและมีขนาดใหญ่เป็นไปได้ในปัจจุบันเท่านั้นเพราะคุณสามารถใช้ประโยชน์จากนามธรรมดังกล่าวได้ หากไม่มี abstractions ระบบซอฟต์แวร์ก็จะพังตามน้ำหนักของตนเอง

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

ในยุคแรก ๆ ของการคำนวณเราใช้ภาษาเครื่อง เราเขียนโปรแกรมโลหะเปลือยขนาดเล็กมากที่มีความรู้อย่างใกล้ชิดเกี่ยวกับฮาร์ดแวร์ที่เราเขียนขึ้นมา มันเป็นกระบวนการที่ต้องใช้ความอุตสาหะ ไม่มี debuggers; โปรแกรมของคุณมักจะใช้งานได้หรือมันล้มเหลว ไม่มี GUI ทุกอย่างเป็นทั้งบรรทัดคำสั่งหรือกระบวนการแบทช์ รหัสที่คุณเขียนจะใช้ได้กับเครื่องนั้น ๆ เท่านั้น มันจะไม่ทำงานบนเครื่องที่มีโปรเซสเซอร์หรือระบบปฏิบัติการอื่น

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

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

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

คุณนามธรรมมากเกินไปหรือไม่ "แซงหน้าประปา" อย่างที่สกอตติชพูด แน่นอนคุณสามารถ. การเขียน API ที่ดีนั้นยาก การเขียน API ที่ดีที่ถูกต้องและรวบรวมโดเมนปัญหาอย่างถูกวิธีและใช้งานง่ายและค้นพบได้ยากยิ่งขึ้น การซ้อนทับกับเลเยอร์ใหม่ของซอฟต์แวร์ไม่ใช่วิธีที่ดีที่สุดเสมอไป รูปแบบการออกแบบซอฟต์แวร์มีบางอย่างทำให้สถานการณ์นี้แย่ลงเพราะบางครั้งนักพัฒนาที่ไม่มีประสบการณ์ก็สามารถเข้าถึงพวกเขาได้เมื่อเครื่องมือที่คมชัดและบางกว่าเหมาะสมกว่า

การฝึกอบรมที่ดีจริงๆเกี่ยวข้องกับทั้งสุดขั้วและสะพานเชื่อมระหว่าง

ที่ระดับต่ำ: คอมพิวเตอร์ใช้งานโค้ดจากพื้นดินอย่างไร * รวมถึงความรู้เกี่ยวกับภาษาแอสเซมบลีและคอมไพเลอร์ทำงานอย่างไร

ในระดับสูง: แนวคิดทั่วไปเช่นการใช้อาเรย์แบบเชื่อมโยงการปิดและอื่น ๆ โดยไม่ต้องเสียเวลากังวลเกี่ยวกับการทำงานภายใต้ประทุน

IMHO ทุกคนควรมีประสบการณ์กับทั้งสองอย่างรวมถึงข้อเสียของพวกเขาและรสชาติของวิธีการได้รับจากแนวคิดระดับต่ำถึงแนวคิดระดับสูง รักอาเรย์เชื่อมโยง? เยี่ยมมากลองใช้พวกมันกับตัวประมวลผลแบบฝังตัว 50 เปอร์เซ็นต์พร้อม RAM ขนาด 1kB ชอบเขียนโค้ดเร็วด้วย C หรือไม่? เยี่ยมมากตอนนี้คุณมีเวลาสามสัปดาห์ในการเขียนเว็บแอป คุณสามารถใช้เวลาในการจัดการกับโครงสร้างข้อมูลและการจัดการหน่วยความจำโดยใช้ C หรือคุณสามารถใช้เวลาในการเรียนรู้กรอบงานเว็บใหม่แล้วนำแอปพลิเคชันเว็บมาใช้ในอีกไม่กี่วัน

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

* และ "พื้น" อยู่ที่ไหนในวิธีที่คอมพิวเตอร์รันรหัส? มันเป็นภาษาประกอบหรือไม่? หรือสถาปัตยกรรมคอมพิวเตอร์ หรือตรรกะดิจิทัล หรือทรานซิสเตอร์? หรือฟิสิกส์ของอุปกรณ์?

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

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

การเพิ่มความซับซ้อนของระบบนั้นเพิ่มขึ้นอย่างไม่หยุดยั้งกดดันและทำให้ทรุดโทรมในที่สุด สำหรับฉันในฐานะโปรแกรมเมอร์รุ่นเก่ามันก็น่าผิดหวังอย่างขมขื่น

ฉันเขียนโปรแกรมมานานกว่า 40 ปีแล้วมีการเขียนโค้ดในภาษาต่าง ๆ 50-100 ภาษาหรือภาษาถิ่นและกลายเป็นผู้เชี่ยวชาญใน 5-10 เหตุผลที่ฉันสามารถเรียกร้องได้มากมายคือส่วนใหญ่พวกเขาเป็นเพียงภาษาเดียวกันกับการปรับแต่ง การปรับแต่งเพิ่มความซับซ้อนทำให้ทุกภาษาแตกต่างกันเล็กน้อย

ฉันได้ใช้อัลกอริทึมเดียวกันครั้งนับไม่ถ้วน: คอลเลกชัน, การแปลง, การเรียงลำดับและการค้นหา, เข้ารหัส / ถอดรหัส, รูปแบบ / การแยกวิเคราะห์, บัฟเฟอร์และสตริง, เลขคณิต, หน่วยความจำ, I / O การใช้งานใหม่ทุกครั้งจะเพิ่มความซับซ้อนเพราะทุกอย่างแตกต่างกันเล็กน้อย

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

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

Microsoft และ IBM ฆ่าความคิดนั้นโดยกลับไปที่ C เพื่อเขียนแอพสำหรับ Windows และ OS / 2 ในขณะที่ dBase / Foxpro และแม้แต่ Delphi ก็เฉื่อยชา จากนั้นเว็บก็ทำอีกครั้งด้วยภาษาแอสเซมบลีสามภาษาที่ดีที่สุด: HTML, CSS และ JavaScript / DOM มันลงจากที่นั่นทั้งหมดแล้ว ภาษามากขึ้นและห้องสมุดมากขึ้นและกรอบและความซับซ้อนมากขึ้น

เรารู้ว่าเราควรจะทำมันแตกต่าง เรารู้เกี่ยวกับ CoffeeScript และ Dart เกี่ยวกับ Less and Sass เกี่ยวกับเทมเพลตเพื่อหลีกเลี่ยงการเขียน HTML เรารู้และเราทำมันต่อไป เรามีกรอบการทำงานของเราเต็มไปด้วย abstractions รั่วและเราเห็นสิ่งมหัศจรรย์ที่สามารถทำได้โดยผู้ที่ได้รับการคัดเลือกน้อยที่เรียนรู้คาถาลึกลับ แต่เราและโปรแกรมของเราถูกดักจับโดยการตัดสินใจในอดีต มันซับซ้อนเกินไปที่จะเปลี่ยนแปลงหรือเริ่มต้นใหม่

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

ในการตอบคำถามสุดท้ายของคุณฉันขอแนะนำโปรแกรมเมอร์ที่อายุน้อยกว่าให้เริ่มต้นเค้กเลเยอร์ให้สูงที่สุดเท่าที่จะทำได้และดำดิ่งลงไปที่ชั้นล่างตามที่ต้องการและปรารถนาให้เกิดแรงกระตุ้น การตั้งค่าของฉันสำหรับภาษาที่ไม่มีการวนซ้ำสถานะการแยกย่อยและชัดเจน Lisp และ Haskell เข้ามาในใจ ในทางปฏิบัติฉันมักจะจบลงด้วย C # / Java, Ruby, Javascript, Python และ SQL เพราะนั่นคือที่ชุมชนอยู่

คำพูดสุดท้าย: ความซับซ้อนเป็นศัตรูที่สุด! เอาชนะสิ่งนั้นและชีวิตกลายเป็นเรื่องง่าย

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

ไม่จริงเหรอ

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

สถานที่ซึ่งเป็นปัญหาสำหรับฉันคือวัฒนธรรมทั้งหมด ครึ่งทางปฏิบัติของฉันเข้าใจว่ามันเป็นไปไม่ได้ที่จะปิดใจทุกรายละเอียดและสามารถทำสิ่งที่ฉันต้องการให้เสร็จ (การแก่ขึ้นก็ไม่ได้ช่วยอะไรเช่นกัน) ครึ่งหนึ่งของผมหงอกสีเทาของผมมีช่วงเวลาที่ยากลำบากในการปล่อยให้หลายปีที่ผ่านมามีความเข้าใจอย่างละเอียดในทุกสิ่งที่ฉันทำ

คุณคิดว่าโปรแกรมเมอร์อายุน้อยจะได้รับประโยชน์จากการเรียนรู้การเขียนโปรแกรมระดับต่ำมากขึ้นก่อนที่จะสำรวจขอบเขตของห้องสมุดที่กว้างขวางหรือไม่?

ดังที่ได้อธิบายไปแล้วในคำตอบอื่น ๆ มีความสมดุลระหว่างการดึงดูดและรักษาความสนใจของ neophytes และให้การศึกษาในอุดมคติจากล่างขึ้นบน หากคุณไม่สามารถทำอดีตได้สิ่งหลังไม่สามารถเกิดขึ้นได้

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

ผลที่สุดของทั้งหมดนี้คือมันไม่ได้เป็นเพียงแค่การพัฒนาอีกต่อไป ความเชี่ยวชาญอย่างต่อเนื่องหมายถึงนักพัฒนาจะต้องพัฒนาทักษะการสื่อสารและการรวมกลุ่มอย่างต่อเนื่อง

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

มันสามารถอธิบายได้ที่นี่

หรือที่นี่ - "ด้วยรหัสบรรทัดเดียวคุณสามารถเพิ่มผู้ใช้ 500 คนในโดเมน" ...

abstractions ของคุณพยายามซ่อนความซับซ้อนจากคุณ แต่จริงๆแล้วสิ่งที่พวกเขาทำคือซ่อนความซับซ้อนนั้น ความซับซ้อนยังคงอยู่ที่นั่นเพียงคุณมีการควบคุมน้อยกว่ามาก - และนั่นคือเหตุผลที่คุณจบลงด้วยสถานการณ์เช่นนี้

โปรแกรมเมอร์ที่อายุน้อยกว่ามีประโยชน์ต่อการเรียนรู้การเขียนโปรแกรมระดับต่ำมากขึ้นก่อนที่จะสำรวจอาณาจักรของห้องสมุดที่กว้างขวางหรือไม่? ถ้าเป็นเช่นนั้นทำไม

ฉันไม่คิดอย่างนั้น ยังมีอีกหลายสถานการณ์ที่เป็นประโยชน์ที่จะต้องระวังการทำงาน 'เลเยอร์ด้านล่าง' ต่ำเช่น

• เมื่อทำการดีบั๊กปัญหาบนเลเยอร์nมักจะสามารถอธิบายได้โดยพิจารณาว่าเกิดอะไรขึ้นกับเลเยอร์n-1(เช่นเลเยอร์ด้านล่าง) ฉันเดาว่าเลเยอร์ 0 จะเป็น "ทรานซิสเตอร์" แต่ถ้าคุณต้องการอธิบายปัญหาของทรานซิสเตอร์คุณอาจจะพูดถึงเรื่องฟิสิกส์ (เช่นความร้อน) ดังนั้นฟิสิกส์อาจจะอยู่ในระดับ 0

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

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

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

• ให้คอมพิวเตอร์ช่วยคุณค้นหาข้อผิดพลาดเชิงตรรกะในโปรแกรมที่คุณเขียน สิ่งต่าง ๆ เช่นระบบชนิดสแตติกหรือตัววิเคราะห์ซอร์สโค้ด (ฉันได้ยินว่าEric Lippertทำงานได้ดีในสมัยนี้) ช่วยด้วย

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

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

"ถ้าโปรแกรมเมอร์รุ่นเก่าเห็นนวัตกรรมเช่นนี้เป็นสวรรค์หรือเลเยอร์เพิ่มเติมที่เป็นนามธรรมผ่านและทำไมพวกเขาถึงคิดเช่นนั้น"

ฉันเขียนโปรแกรมมาตั้งแต่ฉันอยู่มัธยมปลายประมาณ 34 ปีเริ่มด้วย Basic และ Z80 Assembler ย้ายไปที่ C ภาษา 4GL ต่างๆ Scheme SQL และตอนนี้เว็บภาษาต่างๆ ขอบเขตขนาดและความลึกของปัญหาที่ได้รับการแก้ไขโดยผู้เชี่ยวชาญนั้นประสบกับช่วงเงินเฟ้อในช่วงเวลานั้นโดยเฉพาะอย่างยิ่งในช่วงปี 1990 โครงสร้างเช่นไลบรารีเฟรมเวิร์กและบริการของ OS นั้นเป็นการออกแบบที่เน้นความซับซ้อนที่สอดคล้องกับปัญหาที่ขยายออกไป พวกเขาไม่ได้มาจากสวรรค์หรือเป็นภาระของตัวเอง - เพียงสำรวจอย่างต่อเนื่องของพื้นที่การแก้ปัญหาที่กว้างใหญ่

แต่ IMHO "นวัตกรรม" เป็นที่เข้าใจกันดีกว่าในแง่ของรูปแบบใหม่และไม่ผิดพลาดสำหรับการเคลื่อนไหวด้านข้าง - แบบฟอร์มแนะนำใหม่ที่เราเคยเห็นมาแล้ว ในบางวิธีความดกของไข่ในระบบนิเวศนั้นทนทุกข์ทรมานเมื่อรูปแบบดั้งเดิมไม่ได้แต่งขึ้นเมื่อพวกเขากำหนดการตัดสินใจในช่วงต้นของวิวัฒนาการหรือไม่สามารถทำซ้ำเศษซากของพวกเขา บางส่วนถ้าไม่มากที่สุดของโครงสร้างที่เรายังคงมุ่งเน้นไปที่ไม่ได้จัดลำดับความสำคัญในระยะยาวการดำรงชีวิตของมูลค่าเป็นกังวล ที่ได้เริ่มเปลี่ยนแปลง - วิธีการเช่นการวางแนวการบริการและการออกแบบการขับเคลื่อนโดเมนไม่พูดถึงไฮเปอร์เท็กซ์และโมเดลที่ใช้กราฟเป็นต้นตัวอย่างเช่นการเปลี่ยนแปลงภูมิทัศน์ เช่นเดียวกับระบบนิเวศใด ๆ ในที่สุดรูปแบบที่โดดเด่นจะทำให้เกิดรูปแบบใหม่ เราได้รับการบริการที่ดีที่สุดโดยการอนุญาตความหลากหลาย

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

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

OTOH แม้ว่าเป้าหมายของคุณคือการทำงานเป็นช่างเทคนิค / กลไกระดับการรับรู้การเขียนโปรแกรมระดับต่ำบางระดับยังคงเป็นประโยชน์ในการพัฒนาทักษะการแก้ปัญหาของคุณ

โปรแกรมแรกของฉัน (เป็นวัยรุ่นอายุ 15 ปี) คือในปี 1974 ในPL / 1บนบัตร punched สำหรับเมนเฟรม IBM 370/168 พ่อของฉันทำงานที่ IBM และฉันโชคดีที่สามารถไปดาต้าเซ็นเตอร์ได้ในวันอาทิตย์

ในเวลานั้นโปรแกรมที่มีงบหลายพันใบ (การ์ด iepunched) เป็นโปรแกรมขนาดใหญ่ (และการ์ดที่หนักเกินไปเช่นกันเนื่องจากการ์ดเจาะหลายพันใบมีน้ำหนักหลายกิโลกรัม) อินเตอร์เฟซที่มองเห็นไม่ได้อยู่ (โปรแกรมทั่วไปอ่านจาก "อินพุตมาตรฐาน" โดยใช้คำสั่งบัตรเจาะที่เริ่มต้นด้วย//GO.SYSIN DD *IIRC แต่ฉันไม่ได้ต้นแบบJCL ) อัลกอริทึมมีความสำคัญและ IIRC ห้องสมุดมาตรฐานค่อนข้างเล็กตามมาตรฐานของวันนี้

วันนี้โปรแกรมหลายพันบรรทัดโดยทั่วไปถือว่าเล็ก ตัวอย่างเช่นคอมไพเลอร์GCCมีซอร์สโค้ดมากกว่าสิบล้านบรรทัดและไม่มีใครเข้าใจได้เต็มที่

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

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

ความแตกต่างที่สำคัญระหว่างปี 1970 และปัจจุบันคืออัตราส่วนของต้นทุนระหว่างความพยายาม (คน) ของนักพัฒนาและพลังงานคอมพิวเตอร์