ทำไมต้องดูถูก COBOL? [ปิด]

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

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

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

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

เห็นได้ชัดว่าสำหรับหลาย ๆ คนมันเป็นเพียงมุมมอง "เก่าไม่ดี" ที่ jonsca ได้อธิบายไปแล้ว - และยังมีทัศนคติแบบผ่าน ๆ แต่มีปัญหาพื้นฐานที่แท้จริงว่า

การพูดมากเกินไปเป็นปัญหาจริง - มีความยุ่งเหยิงมากเกินไปในการทำความเข้าใจรหัส นี่คือปัญหาที่ใหญ่ที่สุด คนที่มองไปที่MOVE, ADDและMULTIPLYงบอื่น ๆ ในหนังสยองขวัญมีมุมมองที่พูดเกินจริงเล็กน้อยนี้จริง - The COMPUTEงบอยู่ใกล้กับที่ได้รับมอบหมายในภาษาอื่น ๆ แต่ก็ยังมีความยุ่งเหยิงในแผนกและแผนกทั้งหมด หนึ่งในสิ่งแรกที่ฉันได้เรียนรู้ในภาษาโคบอลคือการเริ่มต้นเสมอโดยการคัดลอก SKELETON.COB ยาวหน้ามาตรฐาน A4

COBOL จะมีคุณสมบัติที่น่าสนใจบางอย่าง แต่คุณสมบัติเหล่านั้น (เช่นPICสิ่ง) มีแนวโน้มที่จะเป็นสิ่งที่เป็นส่วนหนึ่งในขณะนี้มากขึ้นของ DBMS มากกว่าการเขียนโปรแกรมภาษาและที่ดูเหมือนว่าฉันมักจะเป็นวิธีที่ดีกว่าที่จะแยกความรับผิดชอบเหล่านั้น นอกจากนี้บางไลบรารีในภาษาอื่น ๆ ก็ใช้สิ่งที่เทียบได้กับPIC(เช่น printf และ scanf ในไลบรารีมาตรฐาน C) เนื้อหาที่ดีที่สุดได้ถูกเก็บไว้ แต่ที่เลวร้ายที่สุดลดลง

นอกจากนี้สำหรับทุกคุณสมบัติที่ดีมีอย่างน้อยหนึ่งที่ทนไม่ได้ ตัวอย่างเช่นไม่ว่าลูปเล็ก ๆ น้อย ๆ จะเป็นอย่างไรคุณจะต้องย้ายร่างกายไปเป็นขั้นตอนแยกต่างหาก PERFORM ... UNTIL ...และคล้ายงบมีงบเดียว - ไม่ได้โครงสร้างบล็อก ในความรู้สึก COBOL เป็นรสชาติของการเขียนโปรแกรมโครงสร้างจากการเขียนโปรแกรมโครงสร้างก่อนที่จะถูกคิดค้น - มีเป็นGO TOแต่ก็ใช้เป็นกำลังใจ (อย่างน้อยเมื่อฉันใช้ภาษาโคบอล) แต่การวนลูปโดยเฉพาะอย่างยิ่งก็ไม่ได้รับการจัดการที่ดี

ในความเป็นจริงภาษาที่ฉันใช้หลังจาก COBOL ที่ทำให้ฉันนึกถึงมันมากที่สุดคือ ... dBase ในขณะที่ Ashton-Tate dBase III + ทุกวันนี้ผู้คนมีแนวโน้มที่จะจดจำโคลนนิ่งที่ตายแล้วหรือกำลังจะตายทั้งหมด (Clipper, FoxPro ฯลฯ ) ที่นำไปสู่ชื่อสามัญ xBase - และยังมีทายาทที่ยังมีชีวิตอยู่ใน xHarbour ประเด็นก็คือสิ่งเหล่านี้เป็นภาษาฐานข้อมูล แต่ไม่มีอะไรเหมือน SQL

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

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

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

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

ปัญหาที่ JSP สามารถจัดการได้อาจเป็นแนวทางที่ดีสำหรับสิ่งที่ COBOL สามารถทำได้ค่อนข้างดี แต่ถึงอย่างนั้นก็ไม่ได้หมายความว่า JSP หรือ COBOL เป็นวิธีที่ดีในการจัดการปัญหาเหล่านั้น

แก้ไขเมื่อวันที่ 30 กรกฎาคม 2014

ฉันเพิ่งได้รับชื่อเสียงจากสิ่งนี้เตือนฉันว่ามันอยู่ที่นี่ เมื่อมันเกิดขึ้นเนื่องจากการสะสมหนังสือโบราณที่ชวนให้นึกถึงตอนนี้ฉันสามารถแก้ไขจุด WRT ที่SORTคำสั่ง

หนังสือเล่มแรกที่ฉันใช้เป็นข้อความที่แนะนำเมื่อเรียนรู้ COBOL คือ "การเขียนโปรแกรมตามระเบียบวิธีใน COBOL" โดย Ray Welland สิ่งนี้ไม่ครอบคลุม COBOL 85 (แม้ว่าจะมี "การเขียนโปรแกรมตามระเบียบวิธีใน COBOL-85" รุ่นที่ใหม่กว่าซึ่งฉันยังไม่เคยเห็นมาก่อน)

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

ต่อไปนี้จะยกมาจากหน้า 165-166 ของ "การเขียนโปรแกรมระเบียบในภาษาโคบอล" ...

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

นอกจากนี้ยังมีสิ่งอำนวยความสะดวกสำหรับการเรียงลำดับระเบียนจากภายในโปรแกรมภาษาโคบอล แต่นี่มันเกินขอบเขตของหนังสือเล่มนี้ด้วยเหตุผลสองประการ:

(a) ส่วนต่อประสานกับระบบปฏิบัติการมักจะค่อนข้างซับซ้อนและแตกต่างกันไปตามระบบ

(b) โมดูลการเรียงลำดับเป็นส่วนเสริมของ ANS '74 COBOL และอาจไม่สามารถนำมาใช้ในระบบ COBOL สำหรับคอมพิวเตอร์ขนาดเล็ก

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

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

สิ่งที่ฉันพูดไว้ข้างต้นนั้นเป็นสิ่งที่คุณได้รับหลังจาก 20 ปีที่ไม่สามารถตรวจสอบข้อเท็จจริงเนื่องจากทิ้งหนังสือ

ฉันควรชี้ให้เห็นว่าฉันได้ศึกษา COBOL อย่างเป็นทางการจากหนังสือแนะนำเล่มนี้ซึ่งครอบคลุมมาตรฐานปี 1974 (ไม่ใช่มาตรฐานปี 1985) ในปี 1988 และ 1989 รุ่นที่สามของ "COBOL สำหรับนักเรียน" (Parkin, Yorke, Barnes) - รุ่นแรกที่ครอบคลุม COBOL 85 - ยังไม่ได้เผยแพร่จนถึงปี 1990 ฉันไม่แน่ใจ แต่ฉันคิดว่า COBOL 85 รุ่น "ระเบียบวิธีการ" ไม่ได้เผยแพร่จนถึงปี 1994

แต่นั่นไม่ได้หมายความว่าโลกของโคบอลจะลากเท้าของมัน - ก็ไม่มากนัก การนำมาตรฐานใหม่มาใช้ต้องใช้เวลาสำหรับภาษาใด ๆ แม้แต่ตอนนี้

การใช้เวลาส่วนใหญ่ในการเขียนภาษาโคบอลวันนี้ฉันคิดว่าฉันสามารถป้อนข้อมูลปัจจุบันบางส่วนได้

สิ่งแรกที่ไม่ดี: -

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

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

• การใช้คำฟุ่มเฟื่อย ดังนั้นคุณต้องพิมพ์ตัวละครพิเศษไม่กี่ตัว! มันไม่ใช่ปัญหาร้ายแรง ในหลายกรณีภาษาโคบอลมีความละเอียดน้อยกว่าพูดภาษาจาวา

• "COBOL FILES" คุณเห็นศัพท์นี้เป็นวงกว้างมาก ไม่มีสิ่งใดที่ COBOL สามารถจัดการกับรูปแบบไฟล์ใดก็ได้และองค์กรไฟล์ใด ๆ ก็ได้

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

และสิ่งที่ดี - บางแง่มุมของภาษาโคบอลนั้นเหนือกว่าภาษาอื่น: -

• โครงสร้างข้อมูล COBOL มีไวยากรณ์ที่กระชับและยืดหยุ่นสำหรับการกำหนดโครงสร้างข้อมูลที่ซับซ้อนและชนิดข้อมูลแปลก ๆ
• เลขคณิตทศนิยม มันมีการสนับสนุนพื้นเมืองสำหรับเลขทศนิยมเช่นเลขคณิตตามที่เข้าใจโดยนักบัญชีที่มีการปัดเศษที่เหมาะสม ฯลฯ
• ย้ายไปอยู่กับเวลา บางแง่มุมของภาษาโคบอลมีความทันสมัยอย่างน่าประหลาดใจ สนับสนุน XML ในตัวรองรับการวางโปรแกรม OO ความสามารถในการใช้คลาส Java เป็นต้น
• การรวมเข้ากับ DB2, CICS และอื่น ๆ สิ่งนี้ใช้ได้เฉพาะกับ COBOL เมนเฟรมของ IBM (แต่นั่นก็คืออันที่ใหญ่ที่สุดของ COBOL ที่ยังคงทำงานอยู่) แต่การรวมเข้ากับ DB2, CICS และสภาพแวดล้อมเมนเฟรมอื่น ๆ ทำให้ง่ายต่อการเขียนโค้ดต่างๆ บริการเว็บมากกว่าในสภาพแวดล้อมอื่น ๆ
• การจัดการหน้าจอ การจัดการหน้าจอมาตรฐานที่ใช้กับ AS / 400 และ MicroFocus Cobol นั้นยอดเยี่ยม
• ประสิทธิภาพ. คอมไพเลอร์ COBOL หลายปีได้ผลิตโปรแกรมที่มีประสิทธิภาพสูงมาก มีเพียง C ดั้งเดิมและ Native Assembler เท่านั้นที่เอาชนะ COBOL บนเมนเฟรมของ IBM

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

นี่อาจจะลงไปที่ Djikstra Djikstra กล่าวว่า "การใช้ COBOL ทำให้จิตใจทรุดโทรม; การสอนของมันจึงควรถูกมองว่าเป็นความผิดทางอาญา" Cobol ถูกมองว่าไร้เดียงสาไม่มีโครงสร้างและ verbose ด้วยความสามารถในการปรับเปลี่ยนรหัสด้วยตนเอง (การฝึกฝนทำให้หมดกำลังใจแม้ในหมู่โปรแกรมเมอร์โคบอลต์) มันก็ถูกมองว่าเป็นการยากที่จะดีบั๊กหรือติดตามด้วย

จากนั้นก็มีเรื่องของความไม่ลงรอยกันระหว่างรุ่นด้วยเช่นกัน

ฉันขอแนะนำให้อ่านส่วนคำวิจารณ์และการป้องกันใน Wikipedia สำหรับภาษา - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

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

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

เห็นได้ชัดว่ามีภาษาโคบอลออกในป่ามากกว่าภาษาอื่น ๆ อย่างไรก็ตามหลังจากทำงานในไอทีมาเกือบ 20 ปี (15 คนในธนาคาร) ฉันไม่เคยเจอระบบเดียวที่ใช้งานมา

มีอะไรเลวร้ายเกี่ยวกับภาษาโคบอล?

ไม่มีอะไร

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

ในปี 1997 กลุ่มการ์ตเนอร์รายงานว่า 80% ของธุรกิจทั่วโลกดำเนินธุรกิจบน COBOL โดยมีรหัสมากกว่า 200 พันล้านรายการและมีรหัสใหม่ประมาณ 5 พันล้านรายการต่อปี (ผ่านวิกิพีเดีย )

ในการเข้ารหัสเราต้องเลือกเครื่องมือที่ดีที่สุดสำหรับงานเสมอและด้วยอุตสาหกรรมบางอย่างที่แต่งงานกับฮาร์ดแวร์บางภาษาจึงเหมาะสมที่สุด ฉันไม่เคยทำงานด้านการธนาคารมาก่อนซึ่งฉันเคยได้ยินว่ามันได้รับความนิยม แต่คำตอบของฌอนระบุว่านี่ไม่ใช่กรณี

หากมีปัญหากับรหัสดั้งเดิมที่ดูเก่าตราบใดที่คุณสามารถตบ UI หรือเว็บอินเตอร์เฟสไว้ข้างหน้าผู้ใช้ส่วนใหญ่จะไม่ทราบถึงความแตกต่าง

ผู้คนไม่ชอบ COBOL เพราะมันมีแอปพลิเคชั่นที่ จำกัด มันถูกออกแบบมาสำหรับธุรกิจการเงินและระบบการบริหารสำหรับ บริษัท และรัฐบาล

สิ่งเหล่านี้มีอะไรที่เหมือนกัน? ข้อมูล. ข้อมูลจำนวนมากและมากมาย

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

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

ลองพิจารณารัฐบาล รัฐบาลต้องการข้อมูลอะไรติดตาม รหัสประชาชนใบสูติบัตรเวชระเบียนภาษี (โอ้ ... ใช่ ... ภาษี) เป็นต้น

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

นั่นหมายความว่าข้อมูลบางอย่างจาก 50 ปีจะยังคงอยู่ที่นี่กับเราในวันนี้ 7 ตุลาคม 2011 ตอนนี้เรามี SQL Server และ C # หรือ Oracle และ Java แต่ 50 ปีที่แล้วมี COBOL และไฟล์

เมื่อเวลาผ่านไปข้อมูลสำหรับรัฐบาลและธนาคารก็ใหญ่ขึ้นเรื่อย ๆ และมีขนาดใหญ่ขึ้นและมีราคาแพงมากขึ้นในการโยกย้ายระบบ ซึ่งหมายความว่าพวกเขาจะต้องยังคงอยู่ในภาษาโคบอลและได้รับการบำรุงรักษาอย่างสม่ำเสมอและพัฒนาเป็นธุรกิจวิวัฒนาการ ธนาคารบางแห่งกำลังโยกย้ายอย่างช้าๆในขณะที่ธนาคารอื่น ๆ ก็ใช้อินเตอร์เฟซ Web2.0 ด้านหน้าเมนเฟรม (c # และ Java เป็นส่วนใหญ่ที่ใช้) คุณบอกรหัสเดิมได้ไหม (COBOL ไปจับคู่กับรหัสดั้งเดิม (สุดขีด) ซึ่งบางคนประทับใจกับผู้คนมากมายในช่วงหลายสิบปีที่ผ่านมา - อีกสิ่งหนึ่งที่โปรแกรมเมอร์ไม่ชอบ: D)

และตอนนี้คุณมีช่องของกิจกรรม COBOL ตอนนี้มีแอพลิเคชัน จำกัด และประสบการณ์ของคุณได้รับผลกระทบ

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

ณ จุดนี้ความต้องการต่ำกว่าอุปทานและผู้ที่ไม่ได้ทำการตัดต้องย้ายไปที่อื่น และพวกเขาจะต้องเริ่มต้นในฐานะรุ่นน้องตั้งแต่ COBOL ทำให้ใจพิการจริงๆ (เชื่อว่าไม่ใช่ Copy-Paste เป็นรูปแบบหลักของการพัฒนาใน COBOL และบัญชีสำหรับการผลิตขนาดใหญ่ของมัน) และตอนนี้พวกเขาสาปแช่งวันที่พวกเขาหยิบ COBOLและ Don ' อย่าเสียโอกาสในการบอกเล่าเรื่องราวสยองขวัญเกี่ยวกับมัน :) แต่คุณสามารถบอกเรื่องราวเหล่านั้นเกี่ยวกับภาษาผายลมเก่า ๆ ที่ไม่ต้องการอีกต่อไปในวันนี้ แต่คุณเป็นคนที่โชคร้ายติดอยู่กับมัน O ดี...

PSและ COBOL ไม่ดีสำหรับเหตุผลอื่น ๆ ที่กล่าวถึงโดยคนอื่น ๆ :)

PS2 In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.จริงๆ? แล้ววันนั้นวัดได้อย่างไร พวกเขาไปทำทุก บริษัท ในคำศัพท์และถามพวกเขาว่าพวกเขามีโคบอลอลหรือไม่?

คุณสมบัติสองอย่าง

• คำสั่งแก้ไขเป็นความชั่วร้ายที่บริสุทธิ์ ในขณะที่ไม่ค่อยมีการใช้งานในแอพพลิเคชั่นภาษาโคบอลที่ทันสมัยกว่านี้มันถูกใช้อย่างมากใน "สมัยก่อน" เพราะมีประสิทธิภาพมากกว่าโครงสร้าง "IF-GOTO" ที่เทียบเท่ากัน เมื่อคอมพิวเตอร์มี RAM เพียง 32K คำสั่งนั้นสำคัญ ได้แก้ไขคำสั่ง GOTO เพื่อให้ปลายทางแตกต่างกัน

  สิ่งนี้ทำให้โค้ดบางทึบเนื่องจากรหัสตัวเองเป็นสถานะ

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

  สิ่งนี้ทำให้โครงสร้างข้อมูลจำนวนมากทึบเนื่องจากข้อมูลไม่สามารถเข้าใจได้หากไม่มีรหัส

ความสามารถในการอ่านของไวยากรณ์ที่คล้ายภาษาอังกฤษนั้นเสียไปโดยโครงสร้างทั้งสองนี้

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

ฉันได้โปรแกรมในภาษาโคบอลเป็นเวลาหลายปีที่ดี ไวยากรณ์ของมันง่ายมากเมื่อเทียบกับภาษาของทุกวันนี้และคุณไม่จำเป็นต้องมีทฤษฎีมากพอที่จะเรียนรู้ที่จะก้าวไปข้างหน้า COBOL ทำงานได้ดีมากกับ CICS ของ IBM (ระบบการจัดการธุรกรรมออนไลน์) และโปรแกรมเมอร์จำเป็นต้องทำการสังเกตรหัสเพื่อปรับจำนวนแอพพลิเคชั่นของผู้ใช้ตั้งแต่ 1 ถึงหลายพันคน CICS จัดเตรียม GUI แบบอักขระที่ทำงานกับหน้าจอเป็นหน่วยแสดงผล (ไม่มีหน้าต่าง) คุณสามารถแสดงแผนภูมิโดยใช้ (GDDM ของ IBM) บนเมนเฟรม COBOL สามารถพูดคุยกับไฟล์ที่จัดทำดัชนี (VSAM และ ISAM) เช่นเดียวกับ DB2 (สัมพันธ์กับ SQL) และ IMS COBOL / CICS เป็นสภาพแวดล้อมที่แข็งแกร่งมากและคุณสามารถเรียนรู้ได้ในไม่กี่สัปดาห์ นั่นหมายความว่าคุณมุ่งเน้นไปที่ธุรกิจที่ไม่ได้ใช้เทคโนโลยีดังนั้นคุณจึงทำงาน 7 จาก 8 ชั่วโมงในการเขียนโปรแกรมไม่ใช่การเรียนรู้ MVM, JavaScript และสิ่งที่คล้ายกัน

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

ภาษาเช่น VB, DBase, FoxPro และ Clipper มีวิธีที่ดีกว่าในการเข้าถึง 'ฐานข้อมูล' บนพีซีได้ดีกว่า COBOL ที่เทียบเคียงได้บน DOS เพื่อให้ COBOL หายไป CICS ไม่ถูกใน DOS หรือ UNIX เป็นเวลานานดังนั้นค่าของมันจึงไม่ปรากฏในสภาพแวดล้อมเหล่านี้

วันนี้ COBOL ได้รับการสนับสนุนด้วย. NET แต่ฉันเดาว่ามันแพ้การต่อสู้บนทุกแพลตฟอร์มยกเว้นเมนเฟรม (และอาจเป็น AS / 400) ซึ่งยังคงอยู่ที่นั่นเพราะแอพพลิเคชั่นที่สำคัญต่อภารกิจที่ต้องพึ่งพาอย่างมาก มัน.

เฮ้ฉันไปโรงเรียนในช่วงต้นยุค 80 และผู้คนก็รังเกียจภาษาโคบอลอลถึงตอนนั้น ฉันคิดว่าปัญหาที่ใหญ่ที่สุดคือการใช้คำฟุ่มเฟื่อย - ง่าย "สวัสดีโลก!" ใน COBOL น่าจะเกินห้าสิบบรรทัด 95% ซึ่งเป็นสิ่งจำเป็นสำหรับสำเร็จรูป มันไม่ใช่ภาษาที่สง่างามหรือน่าดึงดูดใจ นอกจากนี้ยังได้รับการออกแบบมาเพื่อจัดการกับปัญหาของเมื่อวานและไม่ให้ยืมตัวเองกับกระบวนทัศน์การพัฒนาที่พัฒนาขึ้นหลังจากประมาณปี 1970 มันเป็นภาษาการสร้างรายงานที่ค่อนข้างดี - ตราบใดที่รายงานของคุณเป็นคอลัมน์ตัวเลขที่ไม่มีสิ้นสุด หากคุณต้องการติดกราฟหรือโลโก้ที่ไหนสักแห่งลืมมันไป ฉันคิดว่ามันยังคงเป็นภาษาที่เร็วที่สุดสำหรับงานประเภท "การประมวลผลข้อมูล" (ใช้ไฟล์ฟอร์แมทถาวรกับธุรกรรม ATM 5M และทำการปรับสมดุลที่เรียบง่ายสำหรับแต่ละคน) แต่นักพัฒนากี่คนทำสิ่งเหล่านี้อีกต่อไป? และระบบจำนวนมากใช้ XML หรือ JSON ทุกวันนี้ฉันไม่อยากคิดที่จะแยกวิเคราะห์อะไรแบบนั้นกับ COBOL (อันที่จริงฉันเกลียดการแยกวิเคราะห์โดยทั่วไปใน COBOL!)