Tại sao sự khinh miệt đối với COBOL? [đóng cửa]

Khi mọi người đề cập đến COBOL, nó thường gặp tiếng khịt mũi hoặc rên rỉ. Tôi không biết nhiều về COBOL, nhưng tôi đã thấy một số chương trình được viết trong đó. Tôi có thể thấy rằng nó dài dòng, và đôi mắt không quen thuộc như của tôi, không thể hiểu được. Nhưng, thực sự, không phải tất cả các ngôn ngữ lập trình đều hoàn toàn vô nghĩa với một giáo dân sao?

Tôi hiểu rằng nó hoạt động, hoạt động tốt và vẫn được sử dụng rộng rãi trong các ngành công nghiệp mà nó được thiết kế. Không phải đó là những đặc điểm của một ngôn ngữ tốt? Có gì tệ về COBOL?

COBOL là một trong những ngôn ngữ đầu tiên tôi học - nếu bạn bỏ qua vô số phiên bản Cơ bản, ba hoặc bốn ngôn ngữ trình biên dịch và một biến thể của Forth, thì đó là trong năm ngôn ngữ đầu tiên của tôi và học đồng thời với Pascal. IOW, tôi đang trả lời từ kinh nghiệm cá nhân bằng ngôn ngữ.

EDIT Tôi nên nói kinh nghiệm cổ xưa . Tôi không bao giờ sử dụng ngôn ngữ này sau khi kết thúc thập niên 80, mặc dù tôi đã mua một cuốn sách mới (để thay thế cuốn sách cũ mà tôi đã vứt đi trong sự ghê tởm) để tôi có một cái gì đó để đề cập để những câu chuyện kinh dị của tôi sẽ không bị biến dạng. Nhưng tôi không biết ngôn ngữ đã phát triển như thế nào trong ít nhất 20 năm qua.

Rõ ràng, đối với nhiều người, nó là chỉ là "cũ là xấu" quan điểm cho rằng jonsca đã mô tả - và cũng nhiều hơn một tay thứ ba vượt qua-me-down thái độ điều. Nhưng có những vấn đề thực sự tiềm ẩn bên dưới đó.

Quá dài dòng là một vấn đề thực sự - có quá nhiều sự lộn xộn trong cách hiểu mã. Đây là vấn đề lớn nhất. Những người nhìn vào MOVE, ADDvà MULTIPLYbáo cáo vv trong kinh dị có một cái nhìn hơi phóng đại này, sự thật - sự COMPUTEtuyên bố là gần gũi hơn với các bài tập trong các ngôn ngữ khác. Nhưng vẫn còn rất nhiều lộn xộn trong tất cả các bộ phận và các bộ phận. Một trong những điều đầu tiên tôi học được ở COBOL là luôn luôn bắt đầu bằng cách sao chép một trang SKELETON.COB tiêu chuẩn dài A4.

COBOL không có một số tính năng thú vị, nhưng những tính năng (ví dụ như PICđiều) có xu hướng có những điều mà hiện nay nhiều phần của DBMS chứ không phải là ngôn ngữ lập trình, và điều đó dường như tôi thường có một cách tốt hơn để tách những trách nhiệm. Ngoài ra, một số thư viện trong các ngôn ngữ khác sử dụng một cái gì đó có thể so sánh với PIC(ví dụ printf và scanf trong thư viện chuẩn C). Có thể cho rằng, tốt nhất đã được giữ, nhưng tồi tệ nhất đã giảm.

Ngoài ra, đối với mỗi tính năng hay, có ít nhất một tính năng không thể chịu đựng được. Ví dụ, cho dù vòng lặp có tầm thường đến đâu, bạn phải di chuyển cơ thể vào một quy trình riêng. Các PERFORM ... UNTIL ...và các tuyên bố tương tự là câu lệnh đơn - không cấu trúc khối. Trong một nghĩa nào đó, COBOL là một hương vị của lập trình cấu trúc từ trước khi lập trình có cấu trúc được phát minh - có là một GO TO, nhưng nó sử dụng được nản chí (ít nhất là khi tôi đã sử dụng COBOL), nhưng vòng lặp nói riêng chỉ là không xử lý mà tốt.

Trên thực tế, ngôn ngữ mà tôi đã sử dụng sau COBOL khiến tôi nhớ nhất là ... dBase. Như trong Ashton-Tate dBase III +. Ngày nay, mọi người có nhiều khả năng nhớ tất cả các bản sao đã chết hoặc sắp chết (Clipper, FoxPro, v.v.) dẫn đến tên chung xBase - và vẫn còn một hậu duệ còn sống ở xHarbour. Vấn đề là đây là những ngôn ngữ cơ sở dữ liệu, nhưng không có gì giống như SQL.

Ngay cả khi đó, nơi mọi chương trình COBOL hoạt động trên một cơ sở dữ liệu cụ thể cần bao gồm một bản sao đặc tả của cơ sở dữ liệu đó (và các bản sao có thể không nhất quán), đó thực sự không phải là trường hợp trong xBase khi cơ sở dữ liệu biết cấu trúc của chính nó.

Sau đó, tính đến điều đó, COBOL không quá khủng khiếp nếu bạn chấp nhận nó cho những gì nó là. Nhưng những gì nó không phải là một ngôn ngữ để viết cấu trúc dữ liệu. Đó có thể là lý do tại sao COBOL phải chịu đựng rất nhiều trong thời kỳ chiến tranh thần thánh C vs Pascal - cả hai bên có thể đồng ý rằng COBOL không tốt cho việc phát minh lại cây nhị phân một lần nữa.

Ồ - và một điều tôi sẽ không bao giờ quên là cuốn sách giáo khoa COBOL đầu tiên của tôi đã không mô tả SORTlệnh như thế nào , nói rằng nó nằm ngoài phạm vi của cuốn sách - rõ ràng, tác giả không thể đối phó với ý tưởng sắp xếp, hoặc coi nó là nhiều hơn những bộ óc nhỏ bé của các sinh viên COBOL có thể đối phó với [xem chỉnh sửa ở cuối]. Điều đó làm cho rất khó để thực hiện nghiêm túc COBOL.

Một khía cạnh kỳ lạ của điều này là Lập trình cấu trúc Jackson, mà tôi cũng bị buộc phải học cùng một lúc, và đặc biệt để sử dụng với COBOL. Một phần của việc này là vẽ sơ đồ cấu trúc cho đầu vào, sau đó là sơ đồ cấu trúc cho đầu ra, sau đó vẽ sơ đồ cấu trúc ở giữa cho mã. Sắp xếp rõ ràng là một vấn đề đã được giải quyết - bạn không thể rút ra được thuật toán sắp xếp theo cách này. Vì vậy, thật kỳ lạ khi được cuốn sách văn bản khuyến nghị nói rằng toàn bộ khái niệm sắp xếp nằm ngoài tâm trí nhỏ bé của tôi, đồng thời được dạy một cái gì đó giống như hàng tá thuật toán sắp xếp khác nhau và cách thực hiện chúng trong Pascal.

Các vấn đề mà JSP có thể xử lý có lẽ là một hướng dẫn tốt cho những điều mà COBOL có thể làm tương đối tốt. Nhưng ngay cả khi đó, điều đó không nhất thiết có nghĩa là cả JSP và COBOL đều là những cách tốt để xử lý những vấn đề đó.

EDIT vào ngày 30 tháng 7 năm 2014

Tôi vừa được tăng cường danh tiếng từ việc này, nhắc nhở tôi rằng nó ở đây. Khi điều đó xảy ra, do một số bộ sưu tập sách cổ mang đầy hoài niệm, giờ đây tôi có thể sửa một SORTlệnh WRT .

Cuốn sách ban đầu tôi sử dụng làm văn bản được đề xuất khi học COBOL là "Lập trình phương pháp trong COBOL" của Ray Welland. Điều này không bao gồm COBOL 85 (mặc dù đã có phiên bản "Lập trình phương pháp trong COBOL-85" sau này mà tôi chưa từng thấy).

loại bình luận bên dưới rằng "Bạn phải sắp xếp các tệp đầu vào trước khi đọc chúng hoặc sắp xếp tệp đầu ra sau khi tạo nó, sử dụng tiện ích sắp xếp đi kèm với HĐH". Từ câu trả lời của tôi, tôi đã bỏ lỡ điểm "đi kèm với hệ điều hành". Kindall đã gợi ý một cái gì đó giống với triết lý Unix AFAICT, với COBOL được sử dụng cho các bit, nó tốt cho các tiện ích hệ điều hành như một tiện ích sắp xếp được sử dụng cho một số thứ khác, và có lẽ sử dụng ngôn ngữ bó / script / shell để dán các bit lại với nhau. Điều này có ý nghĩa hơn nhiều trong một thế giới cổ đại, nơi phần mềm tương tác hiếm khi không tồn tại, do đó, dù sao bạn cũng sẽ gửi một loạt công việc (do đó là "ngôn ngữ lô").

Sau đây được trích dẫn từ trang 165-166 của "Lập trình phương pháp trong COBOL" ...

Việc sử dụng các tệp nối tiếp có thứ tự ngụ ý rằng cần phải có một phương tiện sắp xếp các bản ghi trong một tệp thành một số thứ tự được chỉ định theo khóa. Hầu hết các hệ thống máy tính lớn hơn đều có tiện ích sắp xếp sẽ sắp xếp một tệp theo vị trí, loại và kích thước của từng mục dữ liệu tạo thành khóa.

Ngoài ra còn có một cơ sở để sắp xếp các hồ sơ từ trong một chương trình COBOL nhưng điều này nằm ngoài phạm vi của cuốn sách này vì hai lý do:

(a) giao diện cho hệ điều hành thường khá phức tạp và thay đổi tùy theo hệ thống,

(b) mô-đun sắp xếp là một phần tùy chọn của ANS '74 COBOL và có thể không được triển khai trong các hệ thống COBOL cho các máy tính nhỏ hơn.

Do đó, sẽ có giả định rằng các cơ sở tồn tại để sắp xếp các tệp theo một thứ tự được chỉ định và vấn đề cập nhật các tệp đó sẽ được xem xét.

Nói tóm lại, kindall là chính xác - giả định là thông thường việc sắp xếp sẽ được thực hiện bên ngoài COBOL. Thậm chí có thể có một lý do thực sự để loại trừ việc sắp xếp từ một ngôn ngữ lập trình vào khoảng năm 1974 cho các máy tính nhỏ.

Những gì tôi nói ở trên về cơ bản là những gì bạn nhận được sau khoảng 20 năm không thể kiểm tra sự thật do vứt cuốn sách đi.

Tuy nhiên, tôi vẫn nên chỉ ra rằng tôi đã chính thức nghiên cứu về COBOL từ cuốn sách được đề xuất này bao gồm tiêu chuẩn năm 1974 (không phải tiêu chuẩn 1985) vào năm 1988 và 1989. Phiên bản thứ ba của "COBOL dành cho sinh viên" (Parkin, Yorke, Barnes) - phiên bản đầu tiên bao gồm COBOL 85 - không được xuất bản cho đến năm 1990. Tôi không chắc chắn, nhưng tôi nghĩ rằng phiên bản "Lập trình phương pháp" của COBOL 85 đã không được xuất bản cho đến năm 1994.

Nhưng điều đó không nhất thiết đại diện cho thế giới COBOL kéo lê đôi chân của mình - tốt, dù sao thì nó cũng không nhiều. Việc áp dụng tiêu chuẩn mới cần có thời gian cho bất kỳ ngôn ngữ nào, ngay cả bây giờ.

Đã dành hầu hết ngày hôm nay để viết một số COBOL tôi nghĩ rằng tôi có thể cung cấp một số đầu vào hiện tại.

Đầu tiên là công cụ BAD: -

• Không có chức năng gọi. COBOL hiện đại có một số chức năng được xây dựng nhưng nó là một công việc kỹ thuật nghiêm túc để viết riêng của bạn.
• Không có loại kiểm tra trên các cuộc gọi chương trình con. Bạn có thể vượt qua (hoặc không vượt qua) bất cứ điều gì trong lệnh gọi chương trình con, chương trình con được gọi sẽ cho rằng nó có các tham số chính xác và không có cách nào để phát hiện các tham số bị thiếu hoặc không hợp lệ.
• Không có thư viện. Không có zilch không. Không có thư viện tiêu chuẩn, không có thư viện dễ sử dụng rộng rãi. Bạn kết thúc mã hóa các nhiệm vụ giao tiếp bằng cách bàn giao nhiều lần.
• Tất cả mọi thứ được thực hiện như một từ khóa. Bởi vì các tác giả ngôn ngữ không có khái niệm về thư viện, mọi tính năng mới kết thúc được triển khai với các từ khóa mới, ví dụ PARSE và RENDER để hỗ trợ XML.

Sự hiểu lầm, tức là những lời chỉ trích thường được chững lại đối với ngôn ngữ cũ thân yêu không hợp lệ hoặc không liên quan.

• Độ dài. Vì vậy, bạn gõ thêm một vài ký tự! Nó không phải là một vấn đề nghiêm trọng. Trong nhiều trường hợp, COBOL ít dài dòng hơn nói Java.

• "LỌC LỚN" Bạn thấy thuật ngữ này được băng bó rất nhiều. Không có gì như vậy chỉ là COBOL có thể xử lý bất kỳ định dạng tệp nào và bất kỳ tổ chức tệp nào.

• Không đa luồng. Trong các môi trường mà COBOL phát triển mạnh, đa luồng thường được dành cho các thùng chứa ứng dụng như CICS hoặc IMS, tốt hơn là các lập trình viên có xu hướng xấu về nó.

Và những thứ tốt - một số khía cạnh của COBOL vượt trội so với các ngôn ngữ khác: -

• Cấu trúc dữ liệu. COBOL có một cú pháp ngắn gọn và linh hoạt để xác định cấu trúc dữ liệu phức tạp và các kiểu dữ liệu lẻ.
• Số học thập phân. Nó có hỗ trợ riêng cho số học thập phân, tức là số học theo cách hiểu của kế toán viên, với cách làm tròn thích hợp, v.v.
• Di chuyển với Thời đại. Một số khía cạnh của COBOL là hiện đại đáng ngạc nhiên. Hỗ trợ XML tích hợp, hỗ trợ lập trình OO, khả năng sử dụng các lớp Java, v.v.
• Tích hợp với DB2, CICS, v.v. Điều này chỉ áp dụng cho COBOL của máy tính lớn của IBM (nhưng đó là phần lớn nhất của COBOL vẫn đang chạy) nhưng việc tích hợp với DB2, CICS và các môi trường máy tính lớn khác giúp dễ dàng mã hóa những thứ như cơ sở dữ liệu dịch vụ web hơn bất kỳ môi trường nào khác.
• Xử lý màn hình. Việc xử lý màn hình tiêu chuẩn như được thực hiện trên AS / 400 và MicroF Focus Cobol là tuyệt vời.
• Hiệu suất. Trong nhiều năm, trình biên dịch COBOL đã tạo ra các tệp thực thi hiệu năng rất cao. Chỉ có C và Trình biên dịch gốc bản địa đánh bại COBOL trên máy tính lớn của IBM.

Vì vậy, tất cả trong tất cả các hoạt động của nó khá tốt cho một cái gì đó đã được đưa ra bởi một ủy ban trong những năm 1950. Nếu một ứng dụng hiện có được triển khai trong COBOL và thực hiện công việc thì không có lý do gì để viết lại nó. Tuy nhiên, trừ khi có một lý do thực sự tốt, tôi không thấy bất kỳ lời biện minh nào cho các dự án mới sử dụng COBOL.

Điều này có lẽ là xuống Djikstra. Djikstra tuyên bố rằng "Việc sử dụng COBOL làm tê liệt tâm trí; do đó, việc dạy học của nó nên được coi là một hành vi phạm tội." Cobol được xem là ngây thơ, không có cấu trúc và dài dòng. Với khả năng tự thay đổi mã (một thực tế không được khuyến khích ngay cả trong số các lập trình viên cobol), nó được xem là khá khó để gỡ lỗi hoặc làm theo.

Sau đó, có vấn đề không tương thích lớn giữa các phiên bản quá.

Tôi sẽ đề nghị đọc phần phê bình và bảo vệ trong Wikipedia cho ngôn ngữ - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Đó là tuổi tác và tính dài dòng thường là những điều khiến mọi người than vãn về nó.

Tôi dường như nhớ lại rằng mục tiêu chính của IBM khi thiết kế COBOL là nó "nên cho phép người quản lý ngân hàng viết chương trình". Mục tiêu này rõ ràng có ảnh hưởng sâu sắc đến cách ngôn ngữ được thiết kế, và bây giờ nó đã phát triển.

Rõ ràng là có nhiều COBOL ngoài tự nhiên hơn bất kỳ ngôn ngữ nào khác. Tuy nhiên, sau khi làm việc trong ngành CNTT gần 20 năm (15 năm về ngân hàng), tôi chưa bao giờ gặp phải một hệ thống duy nhất nào được triển khai trong đó.

Có gì tệ về COBOL?

Không có gì.

Tôi nghĩ mọi người có một quan niệm định sẵn rằng cũ là xấu, "mới nhất là tốt nhất". Nó vẫn còn được sử dụng rất nhiều và tôi chắc chắn sẽ có đủ công việc bảo trì mã trong nửa thế kỷ nữa.

Năm 1997, Tập đoàn Gartner báo cáo rằng 80% doanh nghiệp của thế giới chạy trên COBOL với hơn 200 tỷ dòng mã tồn tại và ước tính có khoảng 5 tỷ dòng mã mới mỗi năm. (thông qua wikipedia )

Trong mã hóa, người ta phải luôn chọn công cụ tốt nhất cho công việc và với một số ngành nhất định kết hôn với phần cứng nhất định, ngôn ngữ là tối ưu. Tôi chưa bao giờ làm việc trong lĩnh vực ngân hàng, nơi tôi đã nghe nói nó rất phổ biến, nhưng câu trả lời của Sean cho thấy đây không phải là trường hợp.

Nếu có vấn đề với mã kế thừa trông cũ, miễn là bạn có thể tát UI hoặc giao diện web trước nó, hầu hết người dùng sẽ không biết sự khác biệt.

Mọi người không thích COBOL vì nó có ứng dụng hạn chế. Nó được thiết kế cho các hệ thống kinh doanh, tài chính và hành chính cho các công ty và chính phủ.

Tất cả những thứ này có điểm gì chung? Dữ liệu. Rất nhiều và rất nhiều dữ liệu.

Đoán xem ai được thiết kế để crunch dữ liệu và có nhiều tập tin cho bữa sáng? Bạn có thể nói ngôn ngữ định hướng kinh doanh COmmon ?

50 năm trước, COBOL là điều tốt nhất cho các tổ chức lớn có nhiều dữ liệu để quản lý. Ngày nay có nhiều cách tốt hơn để quản lý một khối lượng dữ liệu lớn để COBOL không còn phù hợp. Hoặc là nó?

Hãy xem xét các chính phủ. Dữ liệu nào chính phủ cần theo dõi? Id người, giấy khai sinh, hồ sơ y tế, thuế (ồ ... vâng ... thuế), v.v. Và họ phải giữ những infos này vô thời hạn, hôm nay và 50 năm trước cũng vậy.

Mọi người cũng nói xấu các ngân hàng trong một số câu trả lời và thực sự các ngân hàng là người sử dụng rất nhiều COBOL. Tại sao? bởi vì không giống như các loại công ty khác, các ngân hàng thường có một lịch sử. Một số tồn tại hàng trăm năm ( ví dụ như cái này chẳng hạn ).

Điều đó có nghĩa là một số dữ liệu từ 50 năm vẫn phải ở đây với chúng tôi, hôm nay, ngày 7 tháng 10 năm 2011. Bây giờ chúng tôi có SQL Server và C # hoặc Oracle và Java, nhưng 50 năm trước đã có COBOL và các tệp.

Khi thời gian trôi qua, dữ liệu cho các chính phủ và ngân hàng ngày càng lớn hơn và việc di chuyển các hệ thống ngày càng tốn kém hơn. Điều đó có nghĩa là họ phải ở lại COBOL và được duy trì và phát triển khi kinh doanh phát triển. Một số ngân hàng đang dần di chuyển trong khi các ngân hàng khác chỉ dán giao diện Web2.0 đẹp trước máy tính lớn (c # và Java được sử dụng nhiều nhất). Bạn có thể nói mã di sản? (COBOL đi đôi với mã di sản (cực kỳ), một số được nhiều người chạm đến qua nhiều thập kỷ tồn tại - một điều khác mà các lập trình viên chúng tôi không thích: D).

Và bây giờ bạn có một phân khúc hoạt động. COBOL hiện có ứng dụng hạn chế và trải nghiệm của bạn bị ảnh hưởng .

Và những người tham gia vào COBOL cuối cùng phát hiện ra rằng bạn làm điều tương tự hết lần này đến lần khác, hết năm này qua năm khác và khi họ thức dậy, họ không còn cạnh tranh trên thị trường bởi vì mọi người bây giờ muốn PHP, Java, C # , REST, jQuery và chỉ các ngân hàng tìm kiếm người COBOL.

Tại thời điểm này, nhu cầu thấp hơn nguồn cung và những người không thực hiện việc cắt giảm phải chuyển sang thứ khác. Và họ phải bắt đầu với tư cách là đàn em vì COBOL thực sự làm tê liệt tâm trí (tin rằng không phải Copy-Paste là phong cách phát triển chính của COBOL và chiếm năng suất lớn) và bây giờ họ nguyền rủa ngày họ nhặt được COBOL và không ' T mất bất kỳ dịp nào để kể những câu chuyện kinh dị của họ về nó :). Nhưng bạn có thể kể những câu chuyện về bất kỳ ngôn ngữ rắm cũ nào không còn có nhu cầu ngày nay nhưng bạn là người không may mắc kẹt với nó. O tốt...

PS và COBOL là xấu cho tất cả các lý do khác được đề cập bởi những người khác :)

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.Có thật không? Và làm thế nào để đo ngày đó? Họ đã đi làm mọi công ty trong từ và hỏi họ có bao nhiêu dòng COBOL họ có hoặc những gì?

Hai tính năng.

• Tuyên bố ALTER là tà ác thuần túy. Mặc dù hiếm khi được sử dụng trong các ứng dụng COBOL hiện đại hơn, nhưng nó được sử dụng rất nhiều trong "thời xa xưa" vì nó hiệu quả hơn cấu trúc "IF-GOTO" tương đương. Khi máy tính chỉ có 32K RAM, mỗi lệnh đều quan trọng. Nó đã sửa đổi một tuyên bố GOTO để có một đích khác.

  Điều này làm cho một số mã mờ đục vì bản thân mã là trạng thái.

• Mệnh đề REDEFINES trong cấu trúc dữ liệu (như uniontrong C) là một vấn đề muôn thuở. Thuật ngữ "liên minh tự do" - nghĩa là các cấu trúc dữ liệu được phủ mà không có người phân biệt đối xử - là một cách để tóm tắt vấn đề. Hai bí danh REDEFINES không thể được phân biệt bằng dữ liệu; chỉ đọc rộng rãi logic chương trình mới có thể xác định ý nghĩa của hai cách hiểu xen kẽ của các byte.

  Điều này làm cho nhiều cấu trúc dữ liệu mờ đục vì dữ liệu không thể hiểu được nếu không có mã.

Khả năng đọc của cú pháp giống như tiếng Anh đã bị đánh bại bởi hai cấu trúc này.

[Tôi đã được cảnh báo bởi những người điều hành rằng những câu trả lời ngắn sẽ loại bỏ câu hỏi quan trọng và thú vị của bạn. Nếu bạn tìm thấy sự bác bỏ này, bạn có thể yêu cầu chi tiết. Hoặc gắn cờ để người điều hành có thể xóa nó.]

Tôi đã lập trình trong COBOL trong vài năm. Cú pháp của nó đơn giản so với các ngôn ngữ ngày nay và bạn không cần phải có nhiều lý thuyết để học. COBOL đã làm việc rất tốt với CICS của IBM (một hệ thống quản lý giao dịch trực tuyến) và lập trình viên cần lưu ý mã để mở rộng số lượng người dùng ứng dụng từ 1 đến vài nghìn. CICS cung cấp GUI dựa trên ký tự hoạt động với màn hình dưới dạng một đơn vị hiển thị (không có cửa sổ). Bạn có thể hiển thị các biểu đồ bằng cách sử dụng (GDDM của IBM) trên máy tính lớn. COBOL có thể nói chuyện với các tệp được lập chỉ mục (VSAM và ISAM) cũng như DB2 (quan hệ dựa trên SQL) và IMS. COBOL / CICS là một môi trường rất mạnh mẽ và bạn có thể học nó trong vài tuần. Điều đó có nghĩa là bạn tập trung vào công việc kinh doanh không phải là công nghệ, vì vậy bạn làm việc 7 trên 8 giờ về mã hóa không phải là học MVM, JavaScript và tương tự.

Vấn đề với COBOL là tiếp thị xấu dẫn đến sự thiếu quan tâm của các bên thứ 3 để phát triển các công cụ và môi trường lập trình cho nó. Ngoài ra, việc thiếu hỗ trợ cho Windows như giao diện khiến mức độ phổ biến của nó giảm sau năm 1993. Chi phí máy tính lớn khiến khách hàng tìm kiếm các lựa chọn thay thế và trình biên dịch cho COBOL có sẵn trong UNIX và DOS. Ngôn ngữ C đã thu hút nhiều ánh sáng vì nó có thể dễ mang theo hơn và có quyền truy cập trực tiếp vào các chức năng của hệ điều hành, điều mà COBOL có rất ít.

Các ngôn ngữ như VB, DBase, FoxPro và Clipper có cách tốt hơn để truy cập vào 'cơ sở dữ liệu' trên PC so với COBOL tương đương trên DOS nên đã mất COBOL. CICS đã không được làm cho rẻ trên DOS hoặc UNIX trong một thời gian dài, vì vậy giá trị của nó không có trên các môi trường này.

Ngày nay, COBOL được hỗ trợ với .NET nhưng tôi đoán rằng nó đã thua trận chiến trên tất cả các nền tảng ngoại trừ máy tính lớn (và có thể là AS / 400), nơi nó vẫn còn ở đó vì số lượng lớn các ứng dụng quan trọng phụ thuộc hoàn toàn vào nó

Heh, tôi đã đi học đại học vào đầu những năm 80, và mọi người đã khinh miệt về COBOL ngay cả khi đó. Tôi nghĩ vấn đề lớn nhất là tính dài dòng của nó - một câu đơn giản "Xin chào, thế giới!" trong COBOL có lẽ là hơn năm mươi dòng, 95% trong số đó là bắt buộc. Nó không phải là một ngôn ngữ rất thanh lịch hoặc hấp dẫn. Nó cũng được thiết kế để xử lý các vấn đề của ngày hôm qua và không thực sự cho vay các mô hình phát triển được phát triển sau khoảng năm 1970. Đó là một ngôn ngữ tạo báo cáo khá tốt - miễn là các báo cáo của bạn là các cột số vô tận với các tiêu đề và chân trang. Nếu bạn muốn dán vào biểu đồ hoặc logo ở đâu đó, hãy quên nó đi. Tôi nghĩ rằng đây vẫn là ngôn ngữ nhanh nhất cho các tác vụ "xử lý dữ liệu" (lấy tệp định dạng cố định với 5M giao dịch ATM và thực hiện điều chỉnh số dư đơn giản cho từng tác vụ), Nhưng có bao nhiêu nhà phát triển làm những điều đó nữa? Và ngày nay, rất nhiều hệ thống sử dụng XML hoặc JSON, tôi không muốn nghĩ về việc cố gắng phân tích bất cứ điều gì như thế với COBOL (thực ra, tôi rất ghét nghĩ về việc phân tích cú pháp nói chung trong COBOL!)