Hari ini kami menerbitkan bagian kedua dari terjemahan materi tentang matematika, tentang COBOL, dan mengapa bahasa ini masih hidup.
→
Bagian pertamaRasio pengulangan Müller dan COBOL
Mari kita lihat bagaimana COBOL menangani hubungan pengulangan Müller. Berikut adalah program COBOL yang mengimplementasikan hubungan perulangan yang sedang kita pelajari.
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
Jika ini adalah pertama kalinya Anda melihat program yang ditulis dalam COBOL, maka mari kita perjelas beberapa hal segera. Pertama, itu adalah apa yang disebut "bentuk bebas" COBOL, yang diperkenalkan pada tahun 2002 untuk membawa COBOL lebih dekat dengan bagaimana bahasa modern disusun. Secara tradisional, kode COBOL memiliki lebar tetap ketika entitas tertentu ditempatkan di kolom tertentu. Gagasan untuk mempertimbangkan kode dalam bentuk struktur tempat baris dan kolom disorot mungkin tampak aneh, tetapi struktur kode seperti itu dimaksudkan untuk mensimulasikan pemformatan kartu punch. Pada masa COBOL, program dibuat seperti itu. Kartu berlubang memiliki 80 kolom - kolom tertentu untuk data tertentu. Pendekatan yang sama adalah tradisional untuk COBOL.
Hal terpenting dalam kode ini, sesuatu yang mungkin paling menarik perhatian, adalah bagaimana variabel dinyatakan di sini:
01 X2 PIC 9(3)V9(15) VALUE 4.
Kode
01 di awal baris disebut nomor level. Dia memberi tahu COBOL bahwa kami sedang mendeklarasikan variabel baru. COBOL memungkinkan Anda untuk mengikat atau mengelompokkan variabel (contoh klasik adalah alamat yang mungkin menyertakan nama jalan, kota, dan negara sebagai variabel terpisah), sebagai akibatnya, dalam hal ini, angka level menjadi penting.
X2 adalah nama variabel - semuanya cukup sederhana. Pada akhirnya ada konstruksi yang menetapkan nilai awal variabel, yang terlihat seperti "
VALUE 4. " Titik pada akhirnya bukan salah ketik. Ini adalah cara untuk mengakhiri garis dalam COBOL.
Sekarang kita hanya perlu mempertimbangkan apa yang ada di tengah garis - konstruksi
PIC 9(3)V9(15) .
PIC adalah sedikit operator untuk menggambarkan tipe data karakter. Itu dapat menyimpan nilai alfanumerik. Ia bahkan bisa menyimpan angka desimal. COBOL adalah bahasa dengan pengetikan statis yang ketat dan dengan satu fitur yang tidak biasa, yaitu bahwa sebagian besar tipe COBOL jauh lebih fleksibel daripada jenis dalam bahasa lain. Selain itu, saat mendeklarasikan variabel, Anda harus menentukan jumlah karakter yang dapat terdiri. Dalam kasus kami, ini adalah angka dalam tanda kurung. Konstruksi
PIC 9(3) berarti bahwa suatu variabel dapat menyimpan tiga karakter, yaitu angka (ditunjukkan oleh angka
9 ).
Akibatnya, konstruksi
9(3)V9(15) harus dibaca sebagai berikut: "3 digit, diikuti oleh titik desimal (v), diikuti oleh 15 digit lainnya."
Berikut adalah hasil dari program ini:
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
Ini terjadi menggunakan angka yang memiliki 15 tempat desimal. Jika kita mengubah properti variabel
X1 ,
X2 dan
Y ke
PIC9(3)V9(25) , maka kita dapat beralih:
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
Mainframe yang berbeda menawarkan batas atas yang berbeda untuk tipe data COBOL. Di IBM (setidaknya - dalam kasus saya) adalah 18 digit. MicroFocus memiliki 38 digit.
Berapa biaya akurasi?
Semua yang baru saja kita bicarakan bertujuan untuk menunjukkan bahwa COBOL melakukan perhitungan tidak lebih baik daripada bahasa pemrograman lain yang lebih umum. Karena batasan pada ukuran angka titik tetap, COBOL sebenarnya dapat lebih rendah dari bahasa yang memberikan pengembang lebih banyak kontrol atas apa yang terjadi.
Tetapi ada satu fitur. Faktanya adalah bahwa Python (dan Java) tidak memiliki dukungan bawaan untuk angka titik tetap. Dan dalam COBOL, dukungan ini adalah.
Untuk melakukan perhitungan titik tetap dalam Python, saya harus mengimpor modul
Decimal . Jika Anda pernah bekerja dengan proyek yang memiliki sejumlah besar perintah impor, Anda harus menyadari bahwa setiap perintah tersebut memiliki "harga" tertentu. Dalam bahasa seperti Jawa (yaitu, bahasa ini biasanya dianggap oleh mereka yang akan menyingkirkan COBOL) "harga" dari perpustakaan yang sesuai bisa jauh
lebih tinggi . Ini, sebenarnya, lebih merupakan pertanyaan apakah “biaya” mengimpor perpustakaan memainkan peran apa pun dalam proyek Anda. Bagi banyak programmer, memikirkan dampak kinerja yang dimiliki perintah impor adalah puncak dari optimasi prematur.
Tetapi programmer COBOL biasanya bekerja pada sistem yang perlu memproses jutaan, dan mungkin milyaran operasi per detik, melakukannya dengan akurat dan andal. Dan, sayangnya, sangat sulit untuk memberikan argumen yang meyakinkan untuk COBOL atau menentangnya untuk skenario seperti itu, karena ini, pada kenyataannya, adalah area variasi yang tak terhitung jumlahnya. Apakah dukungan titik tetap dibangun ke dalam COBOL faktor penentu ketika memilih bahasa untuk memecahkan masalah seperti itu? Atau mungkin masalah terkait dapat diselesaikan dengan memilih kombinasi prosesor, memori, sistem operasi yang tepat? Atau, mungkin, untuk menyelesaikan masalah perhitungan yang cepat, akurat, dan andal, Anda perlu beralih ke "menari dengan rebana"? Mungkin - kita akan membatasi alasan? Kami akan mengurangi mereka untuk menemukan jawaban untuk pertanyaan seperti "Mana yang lebih baik - COBOL atau Java jika Anda menggunakan perangkat keras yang sama?". Namun demikian, akan sulit bagi kita untuk mengevaluasi bagaimana kekurangan masing-masing bahasa akan mempengaruhi kinerja pada saat sistem mulai melakukan miliaran operasi yang disebutkan di atas per detik. Akibatnya, kita hanya bisa mengatakan bahwa COBOL dan Java yang sama hanya bahasa yang sangat berbeda.
Inilah yang mereka tulis di
sini , mengeksplorasi kinerja kode Java yang diterjemahkan dari kode COBOL.
COBOL adalah bahasa yang dikompilasi yang menggunakan tumpukan yang mendukung pointer dan bergabung. Konversi tipe tidak membuat beban pada sistem selama eksekusi program. Tidak ada penjadwalan atau ketik konversi selama eksekusi program. Kode Java, di sisi lain, berjalan di mesin virtual. Ini menggunakan banyak dan tidak mendukung bergabung. Konversi tipe memberi tekanan pada sistem selama eksekusi program. Java menggunakan pengiriman dinamis dan jenis inferensi pada waktu berjalan. Meskipun dimungkinkan untuk meminimalkan jumlah penggunaan fitur-fitur ini, ini biasanya mengarah pada fakta bahwa kode lebih atau kurang "tidak seperti" kode Java biasa. Ketika mempelajari hasil menerjemahkan kode Java dari COBOL, mereka biasanya mengeluh bahwa kode tersebut tidak dapat dibaca dan tidak didukung. Ini meniadakan sebagian besar tujuan pindah dari COBOL ke Jawa.
Sebelum Anda memutuskan untuk mengesampingkan argumen ini dengan frasa "Ya, tapi ini Java, dan Java juga bukan hadiah" - ingat ini: sebagian besar bahasa pemrograman modern sama sekali tidak memiliki dukungan bawaan untuk perhitungan titik tetap. (Saya pikir akan lebih tepat untuk mengatakan bahwa tidak ada bahasa modern yang mendukung ini, tetapi saya tidak dapat memverifikasi ini dengan andal.) Tentu saja, Anda dapat memilih bahasa lain yang memiliki kelebihan dan kekurangan, tetapi jika Anda membutuhkan akurasi dalam perhitungan dengan titik tetap, dan jika Anda berpikir bahwa kehilangan kinerja kecil dari mengimpor perpustakaan yang mengimplementasikan perhitungan seperti itu dapat menyakiti Anda, ini berarti bahwa Anda memiliki satu-satunya pilihan - COBOL.
Itulah mengapa yang disebut "modernisasi" sangat kompleks: itu tergantung pada banyak faktor. Beberapa organisasi akan menerima hasil nyata dari investasi dalam mengubah platform perangkat lunak, sementara yang lain akan menemukan bahwa mereka telah kehilangan sesuatu yang penting sebagai imbalan untuk "perbaikan" yang, pada kenyataannya, tidak banyak meningkat. Jika sebuah organisasi adalah lembaga keuangan besar yang memproses jutaan transaksi setiap detik dan membutuhkan akurasi perhitungan desimal, maka, pada kenyataannya, akan lebih murah untuk melatih spesialis dalam bekerja dengan COBOL daripada membayar sumber daya dan produktivitas untuk bermigrasi ke bahasa yang lebih populer. Lagipula, popularitas bersifat sementara.
Ringkasan
Akibatnya, berbicara tentang mengapa begitu banyak organisasi masih menggunakan COBOL, Anda perlu memahami bahwa tugas memproses program berbeda dari tugas membuat program. Programmer yang menciptakan solusi memiliki keuntungan dari implementasi bertahapnya. Aplikasi biasanya berusaha sedekat mungkin dengan batas kemampuan yang didukung teknologi mereka. Dilema tentang migrasi dari COBOL bukanlah masalah beralih dari satu bahasa ke bahasa lain. Ini adalah tugas untuk berpindah dari satu paradigma ke paradigma lainnya. Batas-batas Java atau Python di Linux sama sekali tidak sama dengan batas-batas COBOL pada mainframe. Dalam beberapa kasus, aplikasi COBOL mampu melakukan apa yang tidak bisa dilakukan oleh bahasa modern. Untuk kasus seperti itu, menggunakan COBOL pada mainframe modern akan menjadi, pada kenyataannya, solusi yang lebih murah, produktif, dan akurat.
Pembaca yang budiman! Apakah Anda pikir COBOL benar-benar bahasa yang dalam beberapa situasi ternyata benar-benar lebih baik daripada bahasa yang lebih modern?
