หากภาษามีการเปลี่ยนแปลงอย่างรวดเร็วถือว่าเป็นสิ่งที่ดีหรือไม่?

14

ฉันเห็นบางภาษาที่เปลี่ยนแปลงอย่างรวดเร็ว (ฉันหมายถึงพวกเขาได้รับการปรับปรุงทุก ๆ ปี) และบางคนที่พัฒนาช้า

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

programming-languages

— Simon Smith
แหล่งที่มา

4

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

— S.Lott

โปรแกรมเดิมยังคงทำงานเหมือนเดิมหรือไม่?

4

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

— SK-logic

"การเปลี่ยนแปลง" และ "ความเข้ากันได้ย้อนหลัง" เป็นสิ่งที่แตกต่างอย่างสิ้นเชิง หลังเป็นปัญหาจริง

— user16764

16

ถ้าภาษามีการเปลี่ยนแปลงอย่างรวดเร็วนี่เป็นสิ่งที่ดีหรือไม่ดีสำหรับโปรแกรมเมอร์?

ดี

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

ไม่ดี

ภาษาเพิ่มความซับซ้อน - ฟีเจอร์ใหม่อาจไม่เล่นได้ดีกับฟีเจอร์ดั้งเดิม (เช่นความสัมพันธ์ของ C ++ กับ C)
รหัสดั้งเดิมอาจล้าสมัยและอาจใช้งานไม่ได้กับภาษาเวอร์ชันใหม่โดยไม่มีการอัปเดต (Python 2.x -> 3.x)
คอมไพเลอร์และเครื่องมืออื่น ๆ สำหรับภาษานั้นจำเป็นต้องได้รับการอัพเดต ตอนนี้อาจมีหลายรุ่น
ห้องสมุดบุคคลที่สามอาจไม่รองรับภาษาเวอร์ชันใหม่กว่า
แม้จะมีมาตรฐานอยู่ แต่อาจต้องใช้เวลาในการหาวิธีมาตรฐาน / ปกติในการใช้คุณสมบัติใหม่และกำหนดกรณีที่ไม่ชัดเจนของพฤติกรรมของพวกเขา

โปรแกรมเมอร์ชอบที่จะเรียนรู้สิ่งใหม่ในภาษาหรือไม่หรือพวกเขาชอบที่จะยึดติดกับสิ่งที่พวกเขารู้อยู่แล้ว?

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

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

— ดั๊กต.
แหล่งที่มา

C ++ ไม่ใช่วิวัฒนาการของ C แต่เป็นภาษาใหม่ที่เข้ากันได้กับ C

— Nikko

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

— sylvanaar

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

— Donal Fellows

@ นิกโกฉันเห็นด้วย แต่ส่วนใหญ่จะย้อนกลับเข้ากันได้กับ C ซึ่งสร้างปัญหาความสนุกมากมาย :)

— 5465 Doug

11

การปรับปรุงที่ดี ... ถ้าพวกเขาจะเข้ากันได้ย้อนหลัง

C # ทำสิ่งนี้อย่างดี พวกเขาเพิ่มสิ่งที่แสดงออก lamdba การสนับสนุนที่ดีกว่าสำหรับ multithreading, linq, ... แต่โปรแกรม C # 2.0 อายุห้าขวบของคุณจะยังคงทำงานได้เป็นอย่างดีโดยไม่ต้องการการเปลี่ยนแปลงใด ๆ และสามารถอัปเกรดเป็น C # 4.0 ได้อย่างง่ายดายโดยไม่จำเป็นต้องเปลี่ยนแปลงอะไรเลย

การเรียนรู้สิ่งใหม่นั้นยอดเยี่ยมถ้ามันช่วยให้คุณทำงานของคุณได้ง่ายขึ้นและเร็วขึ้น หากใช้เวลาเรียนรู้ชั่วโมงหมายถึงประหยัดเวลาในการพัฒนามันก็คุ้มค่า

— Carra
แหล่งที่มา

5

ฉันต้องการการปรับปรุงเป็นประจำ แต่ฉันไม่ต้องการให้มันทำลาย codebase ขนาด 500 kloc และเรียกใช้ "โครงการอัพเกรด" ขนาดใหญ่เพื่อให้โค้ดทำงานในแบบที่ทำกับเวอร์ชันก่อนหน้านี้

— mcottle
แหล่งที่มา

4

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

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

การเปลี่ยนแปลงยังมาพร้อมกับต้นทุนการเรียนรู้และเวลา ไม่ใช่นายจ้างทุกคนที่เต็มใจให้การศึกษาแก่นักพัฒนาในคุณสมบัติใหม่ นี่เป็นการเพิ่มภาระที่สำคัญให้กับนักพัฒนาในการฝึกอบรมตัวเองหรืออื่น ๆ - นี่ไม่ใช่เรื่องไม่สำคัญหลักสูตรพิเศษอาจอยู่ที่ $ 1,500 - $ 3,500 ต่อคน!

การเปลี่ยนแปลงอย่างต่อเนื่องสามารถล็อคนักพัฒนาซอฟต์แวร์ 'มรดก' พิจารณากรณีของนักพัฒนา ASP ที่ไม่ได้ติดต่อกับ MVVM ภายใน 2 ปีนับจากนี้หรือกรณีของผู้พัฒนา Windows Forms ที่ไม่ได้เรียนรู้ WPF การล็อคนี้อาจทำร้ายอาชีพนักพัฒนาอย่างมาก

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

— ไม่มีโอกาส
แหล่งที่มา

2

ฉันไม่คิดว่าจะมีคำตอบใดที่เหมาะสม

โดยทั่วไปเมื่อภาษายังค่อนข้างเล็กมีอิสระในการเปลี่ยนแปลงขนาดใหญ่ค่อนข้างเร็ว ไม่มีรหัสขนาดใหญ่ที่จะทำลายดังนั้นคนทั่วไปจึงเปิดกว้างต่อการทดลองมากขึ้น

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

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

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

อีกปัจจัยหนึ่งคือขนาดและอายุขัยของโครงการที่ใช้ภาษานั้น ภาษาที่เหมาะสำหรับโครงการที่ค่อนข้างเล็กหรือภาษาที่เรารู้ล่วงหน้ามีอายุขัยสั้น (เช่น UI ของเว็บ) สามารถหลุดพ้นจากสิ่งต่าง ๆ ได้ค่อนข้างบ่อยเพราะไม่น่าเป็นไปได้ที่หลายคนจะใช้ฐานรหัสเดียวกันต่อไป สำหรับพูด 10 ปี แต่อย่างใด ภาษา (เช่น C ++ หรือ Java) ที่ให้ความสำคัญกับโครงการขนาดใหญ่ที่มีอายุยืนกว่าซึ่งอาจใช้เวลา 5 ปีในการเปิดตัวครั้งแรกอาจใช้งานเป็นประจำ (และการพัฒนาอย่างต่อเนื่อง) เป็นเวลาสามหรือสี่ทศวรรษที่ดีมีความมั่นคงมากขึ้นข้อตกลง

— Jerry Coffin
แหล่งที่มา

2

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

อีกคนชอบ C # และไม่รู้จักคำหลักทุกคำหรือรู้จักไลบรารี NET 4 (async และทั้งหมด) และไม่ได้ใช้คำหลักที่เป็นนามธรรมหรือแอตทริบิวต์ที่ใช้

ฉันแค่พูดว่าคนส่วนใหญ่ไม่สนใจ

ตอนนี้เอฟเฟกต์ของการอัพเกรดกำลังแตกหัก (สำหรับ libs หรือโค้ดที่คอมไพล์แล้ว) ผู้คนจะใส่ใจ

"วิวัฒนาการ" C ++ คือ C ++ 11 ซึ่งเป็นบรรทัดฐานใหม่ "C #" หรือ "D" ไม่ใช่วิวัฒนาการ C ++ .. เนื่องจาก C ++ ไม่ใช่วิวัฒนาการของ C

— Nikko

1

@Nikko: อ่าฮ่า จุดดี. ทั้งหมดยกเว้นโปรแกรมเมอร์ C ++ จำนวนน้อยที่ฉันรู้จักเคยได้ยินแม้แต่ C ++ 0x หรือ C ++ 11 ผมค่อนข้างมั่นใจว่าเขาเคยดูแลหรือดูที่คุณสมบัติเว้นแต่คอมไพเลอร์ของ บริษัท และการอัพเกรดที่เกิดขึ้นที่จะเห็นสิ่งที่พวกเขาได้รับอยากรู้อยากเห็นมากพอ (ฉันหวังว่าการย้ายเป็นหนึ่งในนั้น)

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

— จอร์โจ

0

ฉันจะตอบ C # (แต่การวิเคราะห์นี้อาจนำไปใช้กับ Scala เช่นกัน):

การเปลี่ยนคุณสมบัตินี้ทำให้เกิดปัญหาเมื่อคุณเข้าใกล้ "สไตล์" ของภาษา:

ในปี 2011 C # สามารถทำสิ่งต่าง ๆ มากมายและนี่เป็นสิ่งที่ดี น่าเสียดายที่มันมีกระบวนทัศน์ที่แตกต่างกันสองแบบ (หากไม่เพิ่ม):

OOP
ฟังก์ชั่น (คิดว่าฟังก์ชั่นแลมบ์ดาและ LINQ)

สไตล์การตรวจสอบประเภทต่าง ๆ

การพิมพ์แบบไดนามิก
พิมพ์ดีดแบบคงที่

มันไม่ชัดเจนเสมอเมื่อคุณต้องการใช้อย่างใดอย่างหนึ่ง

— volothamp
แหล่งที่มา

0

ฉันคิดว่ามันขึ้นอยู่กับภาษาและต่อไปนี้เป็นภาษาที่มี ยกตัวอย่างเช่นผมคิดว่าถ้า C # และ Java เริ่ม popping จากการเปลี่ยนแปลงในก้าวอย่างรวดเร็วมากขึ้นว่ามันจะได้รับการยอมรับ (ตราบเท่าที่พวกเขาจะเข้ากันได้เช่นCarraกล่าว) อย่างไรก็ตามหากภาษายังไม่ได้รับแรงฉุดและยังคงมีการเปลี่ยนแปลงอย่างรวดเร็วฉันรู้ว่าฉันจะไม่รบกวนเพราะมีโอกาสที่ฉันพยายามเรียนรู้ในวันนี้จะแตกต่างอย่างสิ้นเชิงกับสิ่งที่ออกมาใน 6 เดือนและ เนื่องจากภาษาเป็นภาษาใหม่ / ไม่เป็นที่นิยมจึงไม่เป็นอันตรายต่อฉัน (อ่าน: อาชีพของฉัน) สำหรับฉันที่จะส่งต่อไป

— Jetti
แหล่งที่มา