ชุมชนภาษาบางภาษา (เช่น Ruby และ Python) สามารถป้องกันการแตกแฟรกเมนต์ได้อย่างไรขณะที่ชุมชนอื่น (เช่น Lisp หรือ ML) ไม่

67

คำว่า "เสียงกระเพื่อม" (หรือ "เสียงกระเพื่อมคล้าย") เป็นร่มสำหรับภาษาต่าง ๆ มากมายเช่น Common Lisp, Scheme และ Arc มีการแตกแฟรกเมนต์ที่คล้ายกันในชุมชนภาษาอื่นเช่นใน ML

อย่างไรก็ตาม Ruby และ Python มีการจัดการเพื่อหลีกเลี่ยงชะตากรรมนี้ที่นวัตกรรมเกิดขึ้นมากขึ้นในการดำเนินการ (เช่น PyPy หรือ YARV) แทนการเปลี่ยนแปลงภาษาเอง

ชุมชน Ruby และ Python ทำอะไรเป็นพิเศษเพื่อป้องกันการแตกหักของภาษาหรือไม่

programming-languages language-design

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

10

คุณพูดว่าการแยกส่วนเหมือนมันเป็นสิ่งที่ไม่ดี

— Sonia

21

@Sonia จากมุมมองของส่วนแบ่งตลาดการกระจายตัวมักเป็นหายนะ

— chrisaycock

5

ภาษามีการแข่งขันกันหรือไม่?

— Barry Brown เมื่อ

32

@ โซเนียมันอาจเป็นสิ่งที่ไม่ดี ตัวอย่างเช่นไลบรารีที่เขียนขึ้นสำหรับ Python แทบจะไม่ได้ขึ้นอยู่กับการใช้งานในขณะที่ห้องสมุดที่เขียนสำหรับ Lisp อาจไม่ทำงานใน Scheme

— Kris Harper

2

@ Barry Brown: จุดที่ดี! ภาษาไม่ควรแข่งขันกันในตลาด แต่ผู้ขายภาษานั้นมักจะมีอิทธิพลต่อการออกแบบภาษา (ฉันไม่คิดว่านี่เป็นกรณีของ Ruby, Python, Lisp, ML)

— Giorgio

77

Ruby และ Python ต่างก็มีเผด็จการใจดีอยู่ที่หางเสือ พวกเขาเป็นภาษาที่ฝังรากลึกในความกังวลในทางปฏิบัติ สิ่งเหล่านี้อาจเป็นปัจจัยที่สำคัญที่สุดที่ขัดขวางการกระจายตัว Lisp และ ML ตรงกันข้ามเป็นเหมือน "การออกแบบโดยคณะกรรมการ" ภาษาที่คิดในเชิงวิชาการเพื่อวัตถุประสงค์ทางทฤษฎี

Lisp เดิมถูกออกแบบโดย John McCarthy เป็นสัญกรณ์คณิตศาสตร์เชิงปฏิบัติสำหรับโปรแกรมคอมพิวเตอร์ เขาไม่เคยใช้มันเป็นภาษาการเขียนโปรแกรมจริง การดำเนินการครั้งแรกได้รับการพัฒนาโดยSteve Russellแต่เขาไม่ได้เป็นเผด็จการใจดี เมื่อเวลาผ่านไปการใช้งานที่แตกต่างกันจำนวนมากของ Lisp ปรากฏ; Common Lisp เป็นความพยายามสร้างมาตรฐานให้กับพวกเขา

เสียงกระเพื่อมเป็นมากกว่า "ครอบครัว" ของภาษา ดังนั้น ML จึงเป็นไปตามเส้นทางวิวัฒนาการที่คล้ายคลึงกับ Lisp

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

4

อืมฉันเห็นสถานะเผด็จการในชุมชนภาษาที่เป็นเนื้อเดียวกันเช่น Objective-C (สำหรับแอพ iOS) และ Ada (สำหรับสัญญากระทรวงกลาโหม) ในกรณีนี้พลังงานที่สูงขึ้นเรียกร้องให้ยึดมั่นซึ่งนักพัฒนาตามเพียงเพื่อให้สามารถขาย warez ของพวกเขา แต่ฉันไม่เคยต้องการรหัสใน Python (โครงการงานอดิเรก) ในลักษณะเดียวกับที่ฉันอาจต้องใช้รหัสใน C # (องค์ประกอบ. Net) นั่นคือฉันสามารถหนี Python ได้ง่ายกว่าพูดว่า C โดยไม่มีการคุกคามจากการใช้งานนี้หรือคุณจะไม่ทำยอดขายนักเผด็จการจะยึดมั่นในฝูงได้อย่างไร นั่นอาจเป็นคำถามแยกต่างหาก

— chrisaycock

1

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

— Robert Harvey

4

@HenrikHansen Haskell เป็นมาตรฐานตามที่ Robert กล่าวถึง ดังนั้นคอมไพเลอร์ HUGS จะต้องเข้ากันได้กับ GHC เนื่องจากทั้งคู่เรียกตัวเองว่า "Haskell" การป้องกันตามมาตรฐานเดียวกันขยายไปถึง C และ C ++ ซึ่งเป็นสาเหตุที่ GCC และ Visual Studio ต้องเข้ากันได้ (สมมติว่าไม่มีการใช้ส่วนขยายที่เป็นกรรมสิทธิ์) ความอยากรู้อยากเห็นคือสิ่งที่เกิดขึ้นกับ Lisp ที่มีมาตรฐานอยู่แล้ว (Common LISP) และยังมี Lisps อื่น ๆ อีกมากมาย ML มีปัญหาเดียวกับที่มี Standard ML และ ML อื่น ๆ

— chrisaycock

4

"Common เสียงกระเพื่อมได้รับการพัฒนาเพื่อให้เป็นมาตรฐานสายพันธุ์ที่แตกต่างของเสียงกระเพื่อมซึ่งเกิดก่อนมัน" - en.wikipedia.org/wiki/Common_Lisp กล่าวอีกนัยหนึ่งก็มีการกระจายตัวแล้วก่อนที่มาตรฐานจะได้รับการพัฒนา

— Robert Harvey

3

ฉันจะบอกว่า ML และ Lisp ไม่ใช่ภาษาเหมือน Python และ Ruby เสียงกระเพื่อมและ ML เป็นเหมือน "แนวคิด" ซึ่งดำเนินการโดยหลายภาษาที่แตกต่างกัน

— BenjaminB

29

ปัจจัยหนึ่งที่น่าจะเป็นเพียงอายุ Lisp และ ML นั้นเก่ากว่า Python และ Ruby มาก:

เสียงกระเพื่อม: 1958
ML: 1973
Python: 1991
ทับทิม: 1995

Lisp และ ML ได้เห็นการเปลี่ยนแปลงอย่างมากของความสามารถด้านฮาร์ดแวร์แนวโน้มในด้านวิทยาศาสตร์คอมพิวเตอร์และนักเรียนปริญญาเอกอีกมากมายที่กำลังมองหาสิ่งที่จะทำ

— คาเลบ
แหล่งที่มา

7

อาจเป็นไปได้ แต่ฉันจำไม่ได้ว่า Fortran มีการฟอร์กระดับนี้ (มีบางอย่างเหมือน Fortran D แต่ Fortrans ส่วนใหญ่ผ่านมาตรฐาน) ฉันคิดว่าอายุการรวมตัวกันอาจเป็นปัจจัย

— chrisaycock

2

AFAIK, Fortran มีความไม่ลงรอยกันและการขยายที่ไม่ได้มาตรฐานจำนวนมากและการใช้งานที่แตกต่างกันจนกระทั่งคณะกรรมการมาตรฐานค่อยๆใช้มันออกไปอาจเป็นเพราะมันแพร่หลายกว่า Lisp และ ML

— erjiang

@erjian: ฟอร์แทรนมีความเข้ากันไม่ได้เนื่องจากมีแรงจูงใจที่ร้ายแรงต่อ: การใช้งานทางธุรกิจ LISP ส่วนใหญ่ใช้ในเชิงวิชาการไม่เคยมีความหรูหรา นั่นไม่ใช่การใช้งานที่แพร่หลาย แต่เป็นวิธีการที่ผู้ใช้ร่ำรวย

— MSalters

2

หรือมิฉะนั้นสายพันธุ์จะไม่ถูกเรียกว่า FORTRAN พื้นฐานเมื่อมันออกมาดูเหมือนว่า FORTRAN ที่เรียบง่าย

— David Thornley

1

@Malters Common LISP เป็นความพยายาม (ประสบความสำเร็จพอสมควรใน IMO) ในการขจัดความไม่ลงรอยกันในภาษา maclisp ต่างๆที่ถูกกำหนดเหนือสิ่งอื่นใดโดยการใช้งานทางธุรกิจ (และ DARPA ต้องการให้ห้องปฏิบัติการวิจัยทั้งหมดที่ได้รับทุน . ทุกวันนี้นอกเหนือจากรูปแบบการปิดบังและเสียงกระเพื่อมทั่วไปไม่มีการใช้งาน lisps วัตถุประสงค์ทั่วไปและทั้งสามนี้แตกต่างกันมากพอมีชุมชนที่แยกจากกันด้วยวัฒนธรรมและประวัติศาสตร์ที่แยกต่างหากเพื่อไม่ให้นับเป็นภาษาถิ่นของภาษาเดียวกันอีกต่อไป .

— Pavel Penev

24

พวกมันใช้ภาษาที่กำหนดไว้ในการติดตั้งทั้งหมด

เมื่อมันง่ายที่จะสร้างการใช้งานใหม่ของภาษาที่ส่วนใหญ่เข้ากันได้กับรหัสที่มีอยู่แล้วแฮกเกอร์เป็นแฮกเกอร์พวกเขาไปข้างหน้าและทำมัน ทุกคนเขียนการใช้ Lisp ในบางครั้ง คอมไพเลอร์ ML เกือบบังคับสำหรับนักเรียนที่จบในการออกแบบภาษา - ภาษาเป็นหลังจากที่ทุกเอกสารที่มีชื่อเสียงดี

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

ทับทิม; Perl; หลาม - ทั้งหมดกำหนดเกินไปการนำไปใช้เพื่อสร้างทางเลือกที่ทำงานได้
ghc haskell และ erlang - ถูกนิยามไว้อย่างดี แต่ก็ยากที่จะทำทุกสิ่งที่แข่งขันกับ ghc (หรือ erlang) ที่ผู้คนมักไม่รำคาญ

ข้อเสียที่ดูเหมือนว่านี้ - ภาษาที่ยากเกินกว่าจะสร้างทางเลือกที่เป็นไปได้มีข้อได้เปรียบมหาศาล : ทรัพยากรนักพัฒนาที่หายากจะเน้นไปที่การใช้งานจริงเพียงอย่างเดียว

ในฐานะที่เป็นบันทึกทางประวัติศาสตร์หลายแห่งในชุมชน Haskell ได้ดำเนินการควบรวมกิจการและมีความพยายามในการพัฒนาอย่างจริงจังโดยตระหนักว่าการแตกหักของชุมชน dev จะทำให้เราไม่ประสบความสำเร็จ GHC ได้รับเลือกและสนับสนุน

— ดอนสจ๊วต
แหล่งที่มา

2

ฉันชอบที่จะรู้มากขึ้นเกี่ยวกับ "การควบรวมและติดตามอย่างแข็งขัน"

— Sam Tobin-Hochstadt

การกระจายตัวเป็นธรรมชาติ ภาษาเช่น Python และ Ruby เป็นความผิดปกติที่ไม่ได้อยู่ในแฟรกเมนต์หลักหากคุณไม่นับตัวแปรที่ไม่ได้ใช้เช่น ChinesePython และตัวแปรจะหยุดทำงานในเวอร์ชันก่อนหน้าเช่น Jython นอกจากนี้ยังมีอคติผู้รอดชีวิตที่นี่เพราะภาษาส่วนใหญ่ที่มีเผด็จการไม่ได้รับความนิยมมากนักเช่น Nermerle, Groovy, Beanshell, Boo อันที่จริงอาจมีหลายพันคน

— Vorg van Geir

1

ถึงกระนั้น Haskell ก็ยังสามารถนำไปใช้งานได้มากขึ้นในการเข้าถึงสถานะของ Python / Ruby Haskell's cabalไม่ใช่เครื่องมือสนุกที่จะใช้งานและง่ายต่อการทำลาย: Yesod รับทราบด้วย: yesodweb.com/blog/2012/04/cabal-meta Python และ Ruby ดีขึ้นมากในแง่ของการจัดการบรรจุภัณฑ์

— Ehtesh Choudhury

1

@Shurane Python และ Ruby ไม่ต้องพิมพ์ตรวจสอบแพ็กเกจของคุณก่อนที่จะบูรณาการ ...

— ดอนสจ๊วต

2

-1: สำหรับ "ruby; perl; python - ทั้งหมดถูกกำหนดไว้เพื่อสร้างทางเลือกที่เหมาะสม" Jython, IronPython, JRuby, IronRuby, PyPy, PyPy, Stackless พิสูจน์ให้เห็นว่าคุณทำผิด นอกจากนี้ CPython ยังมีการใช้งานอ้างอิง แต่ไม่ใช่คำจำกัดความภาษานี่คือ

— vartec

12

ผมจะบอกว่าปัจจัยหนึ่งที่เป็นแพลตฟอร์มที่กำหนด สำหรับ Haskell แพลตฟอร์มนี้เป็นมาตรฐาน Haskell และ GHC (ฉันจินตนาการ) สำหรับ Ruby มันเป็น Ruby on Rails ที่ "กำหนด" แพลตฟอร์มการพัฒนา Ruby สำหรับ C มันคือ Unix

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

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

— เฮนริกแฮนเซน
แหล่งที่มา

ฉันชอบความคิดนี้จริงๆ ฉันสามารถใช้ Lisp ได้หลายรูปแบบเพราะไม่มีโครงร่าง "killer Framework" แต่ถ้าฉันต้องการใช้ Rails ฉันต้องติดกับ Ruby ตามมาตรฐาน แน่นอนว่าไม่ใช่คำตอบเดียว แต่ฉันชอบสมมติฐานของคุณ

— chrisaycock

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

— c69

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

— Robert Harvey

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

— Evan Plaice

1

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

— Evan Plaice

7

อย่าลืมชั่งน้ำหนักวัฒนธรรมที่ขับเคลื่อนการพัฒนาของภาษา

ฉันจะให้น้ำหนักกับความจริงที่ว่าการพัฒนา python / php นั้นกระทำในที่สาธารณะ คุณมีบุคคลกลุ่มเดียวที่ทำสเปคมาตรฐานที่ทุกคน / ทุกคนสามารถใช้ได้อย่างอิสระ

เหมือนกับ W3C ที่ทำกับมาตรฐาน HTML / CSS คุณมีกลุ่มบุคคลเล็ก ๆ ที่มีแรงบันดาลใจที่ควบคุมรายละเอียดที่ดีกว่าว่าภาษาใดที่ออกแบบมาเพื่อให้บรรลุผล ทุกอย่างเป็นไปตามข้อกำหนดที่กำหนดไว้อย่างชัดเจนก่อนที่จะเผยแพร่สู่สาธารณะ

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

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

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

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

ความจริงก็คือเรายังคงอาศัยอยู่ในป่าตะวันตกของการพัฒนาภาษาโปรแกรม ปัญหาของการออกแบบ 'ภาษาในอุดมคติ' นั้นยอดเยี่ยมมากถึงแม้จะมีความพยายามอย่างยิ่งใหญ่ แต่ก็ไม่มีใครเข้ามาแก้ไขได้

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

บางภาษามีความเชี่ยวชาญในอดีตบางคนมีความเชี่ยวชาญในช่วงหลัง ผู้ที่พยายามเชี่ยวชาญทั้งสองอย่างมักจะทำไม่ได้ดีและตายไป

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

— Evan Plaice
แหล่งที่มา

บันได? คุณหมายถึงหลังหรือเปล่า

— Giorgio

@ จอร์โจใช่ฉันเกลียดเมื่อฉันสะกดผิด

— Evan Plaice

2

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

ปัจจัยอีกประการหนึ่งคืออายุของภาษา ภาษาที่อยู่ภายใต้การแยกส่วนเป็นภาษาที่เก่าที่สุดและอยู่ภายใต้แรงกดดันของวิวัฒนาการและการแก้ไข เสียงกระเพื่อมถูกประดิษฐ์ขึ้นเมื่อหลายสิบปีที่ผ่านมาดังนั้นจึงมีเวลาเหลือเฟือที่จะนำความคิดบางอย่างมารวมเข้าด้วยกันเป็นภาษาใหม่ C เป็นอีกตัวอย่างหนึ่งของภาษาที่กระจัดกระจาย ในขณะที่ C มีการแก้ไขที่สำคัญเพียงภาษาเดียวเท่านั้น (K&R ถึง ANSI) แต่ก็มีหลายครั้งที่มีการปั่นรวมทั้ง C ++, Not Quite C และอื่น ๆ ทั้งหมดที่แชร์ไวยากรณ์ C-like

Ruby เองเป็น "fragmentation" (ถ้าคุณต้องการ) ของภาษาก่อนหน้า เนื่องจากมันรวมเอาความคิดจาก C, Smalltalk และ Perl (ในหมู่อื่น ๆ ) ตอนนี้มันเป็นภาษาที่ทำการแยกส่วน ฉันไม่เห็นว่าทำไมเราอาจไม่เห็นรูบี้เพิ่มเติมกับภาษาอื่น ๆ ในอนาคต

— Barry Brown
แหล่งที่มา

6

-1 เนื่องจาก: (1) Python 3.x ไม่ใช่การแยกส่วน มันเป็นเพียงขั้นตอนต่อไปในวิวัฒนาการทางภาษา Python 2.x จะลดลงอย่างสิ้นเชิงในอีกไม่กี่ปี (2) การใช้ภาษาอื่น ๆ ที่เข้ากันได้ 99% (1% เป็นรายละเอียดการใช้งานและส่วนใหญ่ค่อนข้างคลุมเครือ) และการปฏิเสธการมีส่วนร่วมในการกำหนดภาษาอย่างแข็งขันไม่ใช่การแยกส่วน (3) ภาษาที่แตกต่างกันอย่างมากมายที่ใช้พื้นฐานร่วมกันและเข้ากันได้บ้าง (C ++ ถึง C) นั้นแทบจะไม่มีการแยกส่วน (4) การยอมรับแนวคิดจากภาษาที่มีอยู่ไม่ใช่การแยกส่วนมันเป็นวิธีเดียวที่ออกแบบภาษา

2

@delnan: Python 2.x จะลดลงอย่างสิ้นเชิงในอีกไม่กี่ปีข้างหน้า? นั่นเป็นสิ่งที่โง่ที่จะพูดเมื่อ COBOL และ Fortran ยังคงอยู่!

— Mason Wheeler

3

@MasonWheeler ฉันกำลังพูดถึงการพัฒนา VCS จะยังคงมีรหัสเก่าที่เก็บถาวรการดาวน์โหลดแบบไบนารีอย่างไม่เป็นทางการอาจอยู่ได้นานหลายทศวรรษและร้านค้าบางแห่งอาจหลีกเลี่ยงการย้ายระบบ แต่ฉันคาดหวังว่าบางวันที่ไม่ไกลเกินไปการเขียนโปรแกรม Python ส่วนใหญ่เกิดขึ้นใน Python 3 หลังจากนั้นการพัฒนาฟีเจอร์ 2.x หยุดไปชั่วขณะหนึ่งก่อนหน้านี้ การอัปเดตข้อผิดพลาด / การรักษาความปลอดภัยไม่ควรดำเนินการต่อไปตลอดกาลและส่วนสำคัญของไลบรารีจะถูกส่งไปยัง Python 3 โดยส่วนใหญ่จะมองไปข้างหน้า (เช่น Djano) หรือไร้การเคลื่อนไหว

1

@MasonWheeler โอ้และสำหรับ Fortran และ COBOL: Fortran ได้รับการแก้ไขมาตรฐานใหม่เมื่อปี 2008 และ COBOL ได้รับหนึ่งในปี 2002 ด้วยรายงานทางเทคนิคจำนวนหนึ่งตั้งแต่นั้นมา

@MasonWheeler คุณรู้หรือไม่ว่า COBOL ที่ทันสมัยช่วยให้การเขียนโปรแกรมเชิงวัตถุ?

2

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

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

— Torbjørn
แหล่งที่มา

1

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

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

นอกจากนี้ยังมีหลายภาษาที่ได้รับแรงบันดาลใจจาก Python เช่น Julia, CoffeeScript เป็นต้นซึ่งจะสร้างตระกูลภาษาเชิงวัตถุที่ไวต่อช่องว่าง

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

ใครที่สนใจภาษาจริงๆ? จุดประสงค์คืออะไร: ภาษาฝรั่งเศสคล้ายกับภาษาลาติน แต่เด็กผู้หญิงที่เข้าใจภาษาฝรั่งเศสนั้นร้อนแรงกว่า;)

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