นอกเหนือจากซอฟต์แวร์เก่าแล้วมีเหตุผลในการใช้ภาษาโคบอล?

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

แค่สงสัย.

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

COBOL ยังคงใช้เป็นอย่างมากในการคำนวณทางการเงิน

ใช่ไหม?

ขึ้นอยู่กับสิ่งที่คุณเรียกว่าการคำนวณทางการเงิน หากคุณเรียกรหัสทั้งหมดที่สถาบันการเงินดำเนินการใช่อาจเป็นไปได้ ส่วนใหญ่มีกฎเกณฑ์ทางธุรกิจที่เขียนขึ้นในยุค 60 และ 70 ความเสี่ยง + ค่าใช้จ่ายในการอัพเกรดระบบเช่นนี้เป็นสภาพแวดล้อมใหม่ไม่คุ้มค่า ฉันสงสัยว่ามีใครบางคนออกไปเขียนโค้ดภาษาโคบอลใหม่ มีคอมไพเลอร์ COBOL ในวันนี้ที่รวมเข้ากับ. NET stack เช่น บ่อยครั้งที่มีเครื่องมือสำหรับการรวมและการใช้ประโยชน์จากแอปพลิเคชันแบบดั้งเดิมในซอฟต์แวร์ที่ทันสมัย ​​แต่เครื่องมือเหล่านั้นมักไม่เป็นที่รู้จักสำหรับผู้ที่ไม่ต้องใช้เพราะเป็นตลาดที่เฉพาะ

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

COBOL ส่วนใหญ่เห็นการใช้งานแบบดั้งเดิมในขณะนี้ ฐานผู้ใช้ช้าลงเนื่องจากการขัดสีเนื่องจากไม่มีการเขียนแอปพลิเคชันใหม่และแอปพลิเคชันเก่า ๆ อย่างช้าๆ แต่แน่นอนจะค่อย ๆ หมดไป

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

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

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

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

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

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

ส่วนใหญ่ของรหัสหลักใน PeopleSoft เขียนในภาษาโคบอล

จากประสบการณ์ของโคบอล 20 ปีในสามเมนเฟรมที่แตกต่างกันมันเป็นความเห็นที่ต่ำต้อยของฉันมีโปรแกรมเมอร์ COBOL ตัวจริงเพียงไม่กี่คน โปรแกรมเมอร์ ในการแสดงความเคารพต่อพวกเขาฉันต้องพูดถึงการปรากฏตัวของโปรแกรมเมอร์ HP 3000, โปรแกรมเมอร์ BULL, และโปรแกรมเมอร์ DEC

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

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

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

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

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

โปรแกรมเมอร์ของ IBM, Sperry, Burroughs และ Tandem รู้เรื่องนี้ดังนั้นพวกเขาจึงไม่เคยเสนอแนวคิดนี้ มันจะเป็นสิ่งศักดิ์สิทธิ์สำหรับบางคน