(Sidenote: หากมีคนสามารถแก้ไขปัญหา markdown ในตัวอย่างของโค้ดเล็ก ๆ น้อย ๆ ได้ฉันจะขอบคุณมัน)
Erik Max Francis เขียนว่า:
"Brandon J. Van Every" เขียน:
มีอะไรดีกว่า Ruby มากกว่า Python ฉันแน่ใจว่ามีบางอย่าง มันคืออะไร? มันจะไม่สมเหตุสมผลกว่าหรือที่จะถามคน Ruby กับเรื่องนี้มากกว่าคน Python ใช่ไหม
อาจหรืออาจจะไม่ขึ้นอยู่กับจุดประสงค์ของคน - ตัวอย่างเช่นถ้าวัตถุประสงค์ของคนนั้นรวมถึง "การศึกษาทางสังคมวิทยา" ของชุมชน Python การตั้งคำถามกับชุมชนนั้นน่าจะพิสูจน์การเปิดเผยข้อมูลเกี่ยวกับมันได้มากกว่าที่อื่น :-) โดยส่วนตัวฉันดีใจที่มีโอกาสได้ติดตามการสอน Ruby หนึ่งวันของ Dave Thomas ที่ OSCON ล่าสุด ด้านล่างแผ่นไม้อัดบางแห่งมีความแตกต่างทางไวยากรณ์ฉันพบว่า Ruby และ Python คล้ายกันอย่างน่าอัศจรรย์ - ถ้าฉันคำนวณต้นไม้ที่ครอบคลุมน้อยที่สุดในภาษาใด ๆ ฉันค่อนข้างมั่นใจว่า Python และ Ruby จะเป็นสองใบแรกที่รวมเข้าด้วยกัน โหนดระดับกลาง :-)
แน่นอนว่าฉันจะได้รับเบื่อในรูบี, การพิมพ์โง่ "จบ" ในตอนท้ายของแต่ละบล็อก (มากกว่าแค่ unindenting) - แต่แล้วฉันจะได้รับที่จะหลีกเลี่ยงการพิมพ์เท่า ๆ กันโง่:
ซึ่งงูหลามต้องที่
จุดเริ่มต้นของ แต่ละบล็อกดังนั้นมันเกือบจะเป็นล้าง :-) ความแตกต่างทางไวยากรณ์อื่น ๆ เช่น@fooเมื่อเทียบกับ
self.fooหรือความสำคัญที่สูงขึ้นของกรณีใน Ruby vs Python เป็นเพียงเกี่ยวกับฉันที่ไม่เกี่ยวข้อง
คนอื่น ๆ ไม่ต้องสงสัยเลยว่าพวกเขาเลือกภาษาการเขียนโปรแกรมในประเด็นดังกล่าวและพวกเขาสร้างการอภิปรายที่ร้อนแรงที่สุด - แต่สำหรับฉันนั่นเป็นเพียงตัวอย่างหนึ่งของกฎหมายของพาร์คินสันในการดำเนินการ (จำนวนการอภิปรายปัญหานั้นแปรผันตามสัดส่วนของปัญหา ความสำคัญจริง) หนึ่งความแตกต่างทางไวยากรณ์ที่ฉันพบว่าสำคัญและเป็นที่โปรดปรานของ Python - แต่คนอื่น ๆ จะไม่สงสัยเลยว่าสิ่งที่ตรงกันข้าม - คือ "คุณเรียกฟังก์ชันที่ไม่มีพารามิเตอร์" ได้อย่างไร ใน Python (เหมือนใน C) ในการเรียกใช้ฟังก์ชันคุณจะใช้ "ตัวดำเนินการโทร" เสมอ - วงเล็บท้ายหลังวัตถุที่คุณกำลังเรียก (ภายในวงเล็บเหล่านั้นจะไป args ที่คุณกำลังผ่านสาย - ถ้า คุณไม่ผ่าน args แล้ววงเล็บจะว่างเปล่า) สิ่งนี้ทำให้การอ้างถึงวัตถุเพียงอย่างเดียวโดยไม่มีโอเปอเรเตอร์ที่เกี่ยวข้องเป็นความหมายเพียงการอ้างอิงไปยังวัตถุ - ในบริบทใด ๆ โดยไม่มีกรณีพิเศษข้อยกเว้นกฎ ad-hoc และไม่ชอบ ใน Ruby (เหมือนใน Pascal) เพื่อเรียกใช้ฟังก์ชันที่มีอาร์กิวเมนต์คุณจะผ่าน args (โดยปกติจะอยู่ในวงเล็บแม้ว่าจะไม่ใช่กรณีที่คงเส้นคงวา) - แต่ถ้าฟังก์ชั่นนั้นไม่มี args แล้วเพียงแค่พูดถึงฟังก์ชั่น สิ่งนี้อาจตอบสนองความคาดหวังของหลาย ๆ คน (อย่างน้อยก็ไม่ต้องสงสัยเลยว่าผู้ที่เคยมีประสบการณ์การเขียนโปรแกรมมาก่อนเท่านั้นคือ Pascal หรือภาษาอื่น ๆ ที่มี "implcit call" เช่น Visual Basic) - แต่สำหรับฉันแล้วมันหมายถึง การกล่าวถึงวัตถุเพียงอย่างเดียวอาจหมายถึงการอ้างอิงไปยังวัตถุหรือการเรียกไปยังวัตถุ ขึ้นอยู่กับประเภทของวัตถุ - และในกรณีเหล่านั้นที่ฉันไม่สามารถอ้างอิงถึงวัตถุได้โดยเพียงแค่กล่าวถึงมันฉันจะต้องใช้ความชัดเจน "ให้ฉันอ้างอิงถึงสิ่งนี้อย่าเรียกมันว่า!" ผู้ประกอบการที่ไม่จำเป็นต้องใช้อย่างอื่น ฉันรู้สึกว่าสิ่งนี้ส่งผลกระทบต่อ "ชั้นหนึ่ง" ของฟังก์ชั่น (หรือวิธีการหรือวัตถุที่เรียกได้อื่น ๆ ) และความเป็นไปได้ของการเปลี่ยนวัตถุอย่างราบรื่น ดังนั้นสำหรับฉันความแตกต่างทางไวยากรณ์ที่เฉพาะเจาะจงนี้เป็นเครื่องหมายสีดำที่ร้ายแรงต่อ Ruby - แต่ฉันเข้าใจว่าทำไมคนอื่นถึงทำอย่างอื่นแม้ว่าฉันจะไม่เห็นด้วยกับพวกเขา :-) ด้านล่างไวยากรณ์เราได้รับความแตกต่างที่สำคัญในความหมายเบื้องต้น - ตัวอย่างเช่นสตริงใน Ruby เป็นวัตถุที่ไม่แน่นอน (เช่นใน C ++) ขณะที่อยู่ใน Python พวกเขาจะไม่สามารถเปลี่ยนแปลงได้ (เช่นใน Java หรือฉันเชื่อว่า C #) อีกครั้งคนที่ตัดสินโดยสิ่งที่พวกเขาคุ้นเคยอยู่แล้วอาจคิดว่านี่เป็นข้อดีสำหรับ Ruby (เว้นแต่พวกเขาจะคุ้นเคยกับ Java หรือ C # แน่นอน :-) ฉันฉันคิดว่าสตริงที่ไม่เปลี่ยนรูปนั้นเป็นความคิดที่ยอดเยี่ยม (และฉันไม่แปลกใจเลยที่ Java, ฉันคิดอย่างอิสระ, คิดใหม่แนวคิดที่มีอยู่แล้วใน Python) แม้ว่าฉันจะไม่รังเกียจว่าจะมี "บัฟเฟอร์สตริงที่ไม่แน่นอน" (และอันที่หนึ่งมีความสะดวกในการใช้งานที่ดีกว่า "สตริงบัฟเฟอร์" ของ Java); และฉันไม่ได้ตัดสินเรื่องนี้เนื่องจากความคุ้นเคย - ก่อนเรียน Java นอกเหนือจากภาษาโปรแกรมที่ใช้งานได้แล้ว คนที่ตัดสินจากสิ่งที่พวกเขาคุ้นเคยอยู่แล้วอาจคิดว่านี่เป็นข้อดีสำหรับ Ruby (เว้นแต่พวกเขาจะคุ้นเคยกับ Java หรือ C # แน่นอน :-) ฉันฉันคิดว่าสตริงที่ไม่เปลี่ยนรูปนั้นเป็นความคิดที่ยอดเยี่ยม (และฉันไม่แปลกใจเลยที่ Java, ฉันคิดอย่างอิสระ, คิดใหม่แนวคิดที่มีอยู่แล้วใน Python) แม้ว่าฉันจะไม่รังเกียจว่าจะมี "บัฟเฟอร์สตริงที่ไม่แน่นอน" (และอันที่หนึ่งมีความสะดวกในการใช้งานที่ดีกว่า "สตริงบัฟเฟอร์" ของ Java); และฉันไม่ได้ตัดสินเรื่องนี้เนื่องจากความคุ้นเคย - ก่อนเรียน Java นอกเหนือจากภาษาโปรแกรมที่ใช้งานได้แล้ว คนที่ตัดสินจากสิ่งที่พวกเขาคุ้นเคยอยู่แล้วอาจคิดว่านี่เป็นข้อดีสำหรับ Ruby (เว้นแต่พวกเขาจะคุ้นเคยกับ Java หรือ C # แน่นอน :-) ฉันฉันคิดว่าสตริงที่ไม่เปลี่ยนรูปนั้นเป็นความคิดที่ยอดเยี่ยม (และฉันไม่แปลกใจเลยที่ Java, ฉันคิดอย่างอิสระ, คิดใหม่แนวคิดที่มีอยู่แล้วใน Python) แม้ว่าฉันจะไม่รังเกียจว่าจะมี "บัฟเฟอร์สตริงที่ไม่แน่นอน" (และอันที่หนึ่งควรมีความสะดวกในการใช้งานที่ดีกว่า "สตริงบัฟเฟอร์" ของ Java); และฉันไม่ได้ตัดสินเรื่องนี้เนื่องจากความคุ้นเคย - ก่อนเรียน Java นอกเหนือจากภาษาโปรแกรมที่ใช้งานได้แล้ว ฉันคิดว่าสตริงที่ไม่เปลี่ยนรูปนั้นเป็นความคิดที่ยอดเยี่ยม (และฉันไม่แปลกใจเลยที่ Java, ฉันคิดอย่างอิสระ, นำเสนอความคิดที่มีอยู่แล้วใน Python) แม้ว่าฉันจะไม่รังเกียจที่จะมี "บัฟเฟอร์สตริงที่เปลี่ยนแปลงไม่ได้" เช่นกัน ความนึกคิดหนึ่งที่มีความสะดวกในการใช้งานที่ดีกว่า "สตริงบัฟเฟอร์" ของ Java); และฉันไม่ได้ตัดสินเรื่องนี้เนื่องจากความคุ้นเคย - ก่อนเรียน Java นอกเหนือจากภาษาโปรแกรมที่ใช้งานได้แล้ว ฉันคิดว่าสตริงที่ไม่เปลี่ยนรูปนั้นเป็นความคิดที่ยอดเยี่ยม (และฉันไม่แปลกใจเลยที่ Java, ฉันคิดอย่างอิสระ, นำเสนอความคิดที่มีอยู่แล้วใน Python) แม้ว่าฉันจะไม่รังเกียจที่จะมี "บัฟเฟอร์สตริงที่เปลี่ยนแปลงไม่ได้" เช่นกัน ความนึกคิดหนึ่งที่มีความสะดวกในการใช้งานที่ดีกว่า "สตริงบัฟเฟอร์" ของ Java); และฉันไม่ได้ตัดสินเรื่องนี้เนื่องจากความคุ้นเคย - ก่อนเรียน Java นอกเหนือจากภาษาโปรแกรมที่ใช้งานได้แล้วข้อมูลทั้งหมดเปลี่ยนแปลงไม่ได้ทุกภาษาที่ฉันรู้ว่ามีสายอักขระที่เปลี่ยนแปลงไม่ได้ - แต่เมื่อฉันเห็นแนวคิดสตริงที่ไม่เปลี่ยนรูปแบบครั้งแรกใน Java (ซึ่งฉันเรียนรู้ได้ดีก่อนที่ฉันจะเรียนรู้ Python) มันทำให้ฉันยอดเยี่ยมทันที การอ้างอิงความหมายของภาษาการเขียนโปรแกรมระดับสูง (ตรงข้ามกับความหมายของค่าที่เหมาะสมที่สุดกับภาษาที่อยู่ใกล้กับเครื่องและอยู่ไกลจากแอปพลิเคชันเช่น C) ที่มีสตริงเป็นแบบเฟิร์สคลาสในตัว สำคัญ) ประเภทข้อมูล
Ruby มีข้อได้เปรียบบางประการในความหมายเบื้องต้น - ตัวอย่างเช่นการลบ Python "list vs tuples" ที่แตกต่างอย่างมาก แต่ส่วนใหญ่คะแนน (อย่างที่ฉันเก็บไว้ด้วยความเรียบง่ายบวกที่ยิ่งใหญ่และละเอียดอ่อนความแตกต่างที่ชาญฉลาดที่น่าทึ่งลบ) เป็นกับทับทิม (เช่นมีทั้งช่วงปิดและครึ่งเปิดด้วยสัญลักษณ์ a .. b และ a .. .b [ใครต้องการที่จะอ้างว่าเป็นที่ชัดเจนหรือไม่ -)] ที่โง่ - IMHO แน่นอน!) อีกครั้งผู้ที่พิจารณาว่ามีสิ่งที่คล้ายกัน แต่มีความแตกต่างอย่างละเอียดที่แกนกลางของภาษา PLUS มากกว่า MINUS แน่นอนจะนับสิ่งเหล่านี้ "วิธีอื่น ๆ " จากวิธีที่ฉันนับ :-)
อย่าเข้าใจผิดโดยการเปรียบเทียบเหล่านี้ในการคิดว่าทั้งสองภาษานั้นมี
ความสำคัญมากแตกต่างใจคุณ พวกเขาไม่ได้ แต่ถ้าฉันขอให้เปรียบเทียบ "capelli d'angelo" กับ "spaghettini" หลังจากชี้ให้เห็นว่าพาสต้าทั้งสองชนิดนี้ไม่มีความแตกต่างกับใครและสามารถใช้แทนกันในจานใด ๆ ที่คุณอาจต้องการเตรียมไว้อย่างหลีกเลี่ยงไม่ได้ เมื่อต้องการย้ายไปยังการตรวจด้วยกล้องจุลทรรศน์ว่าความยาวและเส้นผ่าศูนย์กลางแตกต่างกันอย่างไรการสิ้นสุดของเส้นเกลียวจะเรียวในกรณีหนึ่งและไม่ใช่ในอีกกรณีและอื่น ๆ - เพื่อลองอธิบายว่าทำไมฉันเองควรมี capelli 'angelo เป็นพาสต้าในน้ำซุปทุกชนิด แต่ชอบ spaghettini เป็น pastasciutta ที่จะไปกับซอสที่เหมาะสมสำหรับรูปแบบพาสต้าบาง ๆ ที่ยาวนาน (น้ำมันมะกอกกระเทียมสับพริกแดงสับละเอียดและแอนโชวี่บดละเอียด) ตัวอย่างเช่น - แต่ถ้าคุณหั่นกระเทียมและพริกแทนที่จะหั่นเป็นชิ้นเล็ก ๆ คุณควรเลือกสปาเก็ตตี้ซาวด์มากกว่าสปาเก็ตตินีที่บางกว่า หรือแม้แต่ - ฉันเป็นคนนอกรีต ... ! - แสงสะระแหน่ ... ] ใบไม้ - ในช่วงเวลาสุดท้ายก่อนที่จะเสิร์ฟจาน) อุ๊ปส์ขอโทษแสดงว่าฉันเดินทางไปต่างประเทศและไม่เคยมีพาสต้าซักพักฉันเดา แต่การเปรียบเทียบก็ยังค่อนข้างดี! -) และจะได้รับคำแนะนำที่ดีที่จะนำหน้า achoview และเพิ่มใบโหระพาสดแทน [หรือแม้แต่ - ฉันเป็นคนนอกรีต ... ! - แสงสะระแหน่ ... ] ใบไม้ - ในช่วงเวลาสุดท้ายก่อนที่จะเสิร์ฟจาน) อุ๊ปส์ขอโทษแสดงว่าฉันเดินทางไปต่างประเทศและไม่เคยมีพาสต้าซักพักฉันเดา แต่การเปรียบเทียบก็ยังค่อนข้างดี! -) และจะได้รับคำแนะนำที่ดีที่จะนำหน้า achoview และเพิ่มใบโหระพาสดแทน [หรือแม้แต่ - ฉันเป็นคนนอกรีต ... ! - แสงสะระแหน่ ... ] ใบไม้ - ในช่วงเวลาสุดท้ายก่อนที่จะเสิร์ฟจาน) อุ๊ปส์ขอโทษแสดงว่าฉันเดินทางไปต่างประเทศและไม่เคยมีพาสต้าซักพักฉันเดา แต่การเปรียบเทียบก็ยังค่อนข้างดี! -)
ดังนั้นกลับไปที่ Python และ Ruby เรามาถึงสอง biggies (ในแง่ของภาษาที่เหมาะสม - ออกจากห้องสมุดและอุปกรณ์เสริมที่สำคัญอื่น ๆ เช่นเครื่องมือและสภาพแวดล้อมวิธีการฝัง / ขยายแต่ละภาษา ฯลฯ ฯลฯ จาก สำหรับตอนนี้ - พวกเขาจะไม่นำไปใช้กับการใช้งานทั้งหมดของแต่ละภาษาอย่างไรก็ตาม Jython vs Classic Python เป็นการนำภาษา Python มาใช้งานสองแบบ!):
iterators ของ Ruby และ codeblocks เทียบกับ iterators และ Python ของ Python;
TOTAL ของ Ruby "ไดนามิก" ที่ไม่มีการควบคุมรวมถึงความสามารถในการ "เปิด" คลาสที่มีอยู่ใด ๆ รวมถึงคลาสที่มีอยู่แล้วและเปลี่ยนพฤติกรรมในเวลาทำงาน - เทียบกับพลังแบบ Python ที่กว้างใหญ่ แต่ไม่มี ขอบเขต
ซึ่งไม่เคยเปลี่ยนพฤติกรรมของที่มีอยู่ คลาสที่มีอยู่แล้วและอินสแตนซ์ของมัน
โดยส่วนตัวแล้วฉันคิดว่า1การล้าง (ความแตกต่างนั้นลึกมากจนฉันสามารถเห็นคนที่เกลียดการเข้าใกล้และกราบไหว้คนอื่นได้ง่าย แต่ในส่วนตัวของฉัน และ [2] ปัญหาสำคัญ - หนึ่งที่ทำให้ Ruby เหมาะสำหรับ "tinkering" มากยิ่งขึ้น แต่ BUT Python นั้นเหมาะกว่าสำหรับการใช้งานในแอปพลิเคชันขนาดใหญ่ มันตลกในทางหนึ่งเพราะทั้งสองภาษานั้นมีพลังมากกว่าคนอื่น ๆ ส่วนใหญ่ในที่สุดความแตกต่างที่สำคัญระหว่างพวกเขาจาก POV ของฉันควรขึ้นอยู่กับสิ่งนั้น - ทับทิม "ไปสิบเอ็ด" ในเรื่องนี้ (อ้างอิง นี่คือ "Spinal Tap" แน่นอน) ในทับทิมฉันสามารถทำมันได้ ! นั่นคือฉันสามารถเปลี่ยนคลาสสตริงในตัวแบบไดนามิกได้
a = "สวัสดีชาวโลก"
b = "สวัสดีชาวโลก"
ถ้า a == b
พิมพ์ "เท่ากัน! \ n"
อื่น
พิมพ์ "different! \ n"
ปลาย
จะพิมพ์ "เท่ากัน" ในไพ ธ อนไม่มีทางที่ฉันจะทำได้ สำหรับวัตถุประสงค์ของ metaprogramming การนำกรอบงานทดลองมาใช้และความสามารถที่น่าทึ่งของทับทิมเป็นสิ่งที่น่าเหลือเชื่ออย่างยิ่ง
อุทธรณ์ แต่ - ถ้าเรากำลังพูดถึงแอพพลิเคชั่นขนาดใหญ่ที่พัฒนาโดยคนจำนวนมากและได้รับการดูแลรักษามากขึ้นรวมถึงห้องสมุดทุกประเภทจากแหล่งที่หลากหลายและต้องการที่จะไปผลิตในไซต์ลูกค้า ... ก็ไม่ต้องการ ภาษาที่มีพลังมากขอบคุณมาก ฉันเกลียดความคิดที่ว่าห้องสมุดบางแห่งจะทำลายสิ่งที่ไม่เกี่ยวข้องอื่น ๆ โดยไม่เจตนาซึ่งขึ้นอยู่กับสตริงเหล่านั้นแตกต่าง - นั่นคือ "ช่อง" ที่ซ่อนอยู่ลึกและลึกระหว่างส่วนของโค้ดที่ LOOK ต่างหากและควรแยกจากกัน การเขียนโปรแกรมขนาดใหญ่ โดยการปล่อยให้โมดูลใด ๆ ส่งผลกระทบต่อพฤติกรรมของ "แอบแฝง" อื่นใด
ถ้าฉันต้องใช้ Ruby สำหรับแอปพลิเคชั่นขนาดใหญ่ฉันจะพยายามใช้ข้อ จำกัด ของสไตล์การเข้ารหัสการทดสอบจำนวนมาก (จะเรียกใช้ซ้ำเมื่อใดก็ตามที่มีการเปลี่ยนแปลงใด ๆ - แม้สิ่งที่ควรจะไม่เกี่ยวข้องทั้งหมด ... ) และทำนองเดียวกัน เพื่อห้ามการใช้งานคุณสมบัติภาษานี้ แต่การไม่มีคุณสมบัติในตอนแรกดีกว่าในความคิดของฉัน - เช่นเดียวกับ Python จะเป็นภาษาที่ดียิ่งขึ้นสำหรับการเขียนโปรแกรมประยุกต์หากจำนวนบิวด์อินบางตัวอาจ "ถูกลบ" ดังนั้นฉันจึงรู้ว่า เช่น eg
len("ciao")คือ 4 (แทนที่จะต้องกังวลว่าใครบางคนเปลี่ยนความผูกพันของชื่อlenใน__builtins__
โมดูล ... หรือไม่ ฉันหวังว่าในที่สุด Python จะ "ตอกย้ำ" โครงสร้างภายในของมัน
แต่ปัญหาของปัญหาเล็กน้อยเนื่องจากการรีบิวด์อินใหม่นั้นค่อนข้างจะถูกคัดค้านรวมถึงการฝึกฝนที่หายากใน Python ใน Ruby มันทำให้ฉันรู้สึกว่าสำคัญ - เช่นเดียวกับ
สิ่งอำนวยความสะดวกที่มีประสิทธิภาพมากเกินไปของภาษาอื่น ๆ (เช่นพูด Dylan) นำเสนอความเสี่ยงที่คล้ายกันในความคิดเห็นของฉัน (ฉันหวังว่า Python จะไม่ได้รับระบบมาโครที่ทรงพลังเช่นนี้ สิ่งที่น่าดึงดูดใจของ "ให้คนนิยามภาษาเล็ก ๆ ของตัวเองโดยเฉพาะโดเมนที่ฝังอยู่ในภาษาของตัวเอง" - มันจะ IMHO ทำให้ Python มีประโยชน์ที่ยอดเยี่ยมสำหรับการเขียนโปรแกรมประยุกต์โดยจะนำเสนอ "ความน่ารำคาญที่น่าสนใจ" ให้กับคนจรจัด สิงสถิตอยู่ในหัวใจของโปรแกรมเมอร์ทุกคน ... )
อเล็กซ์