Interpreter MSH

Juru bahasa MSH


Saya memperhatikan visi saya tentang bahasa yang ideal. Dalam artikel saya sebelumnya, saya sudah mengemukakan ide saya tentang bahasa ideal Dari MUMPS ke MSH Fitur dan perbedaan bahasa pemrograman MSH dari MUMPS .

Ulasan yang sebagian besar negatif. Setelah membaca ulasan, saya terkejut menemukan bahwa segala sesuatu di dunia bahasa pemrograman sudah sangat sempurna. Tapi kecurigaan yang samar menggerogoti saya bahwa semuanya tidak begitu baik di dunia ini. Tentu saja, sudah ada banyak bahasa, tetapi berbagai konsep bahasa tidak diamati.

Jika kita membuang sedikit hiasan bahasa, maka ada beberapa konsep seperti itu.

  • Pemrograman objek
  • Manajemen data, mengetik.
  • Melewati sejumlah variabel parameter ke prosedur dan fungsi.
  • Manajemen proses eksekusi.

Dari solusi masalah ini sifat-sifat bahasa pemrograman ditambahkan.

Pemrograman objek


Menurut saya ini adalah konsep yang penting dan harus ada dalam bahasa. Tentu saja, bahkan jika bahasa tersebut tidak memiliki kelas dan objek, maka tidak ada yang menghalangi Anda untuk berpikir dan menulis program dalam gaya objek, tetapi tetap saja, keberadaan mekanisme tersebut memungkinkan untuk menyederhanakan tugas ini.

Manajemen data, mengetik


Saya menganggap bagian ini yang paling penting dalam konsep bahasa. Saya bertemu banyak diskusi tentang hal ini di Habré. Sebagian besar berpendapat untuk pengetikan statis dan dinamis. Dalam pengetikan dinamis, keunggulannya disebut fleksibilitas bahasa, tetapi kelemahannya adalah kononnya bahasa itu tidak bisa diandalkan dan kemampuan adaptasinya yang buruk terhadap lingkungan pengembangan. Dalam pengetikan statis, semuanya justru sebaliknya. Saya menganggap argumen tentang keandalan terbaik bahasa dengan pengetikan statis tidak masuk akal, ada kemungkinan pengetikan statis membantu dalam pengembangan alat pemrograman, tetapi tidak lebih. Saya bukan pendukung kedua pendekatan itu. Saya menganggap pengetikan sebagai kejahatan utama dari bahasa pemrograman modern. Meskipun hadir di sebagian besar bahasa pemrograman. Bahasa harus sepenuhnya mengambil alih semua manajemen data, termasuk memahami tipenya. Itu sangat nyata. Dan programmer harus berurusan dengan logika program. Jika Anda perlu memeriksa data, maka mengetik tidak akan membantu. Mereka hanya perlu diperiksa isinya. Saya bisa menjelaskan keberadaan tipifikasi hanya berdasarkan tradisi dan kepasifan berpikir.

Melewati sejumlah variabel parameter ke prosedur dan fungsi


Ini adalah masalah kecil, tetapi sulit dipecahkan oleh sebagian besar bahasa. Meskipun ada contoh yang bagus di Assembler. Melewati parameter melalui tumpukan. Anda hanya perlu meninggalkan daftar parameter formal, dan meneruskan parameter melalui daftar. Tidak sepenuhnya jelas bagi saya untuk mengembalikan sejumlah variabel nilai fungsi untuk apa dan bagaimana menggunakannya. Bagaimanapun, satu entitas harus dikembalikan.

Manajemen proses


Bagian ini saya juga anggap penting untuk konsep bahasa. Konstruk kontrol bahasa hampir identik. Nuansa kecil muncul menggunakan perintah goto. Saya tidak mengerti mengapa mereka melawan tim ini dengan hiruk pikuknya. Perintah yang sangat mudah, terutama jika argumen dari perintah ini dapat dihitung. Dalam implementasi komputasi paralel, varian varian utamanya adalah 2. Entah mereka diimplementasikan melalui perpustakaan, atau mereka dapat dimasukkan dalam bahasa itu sendiri. Saya seorang pendukung metode kedua.

Bahasa tidak memiliki penanganan acara. Meskipun banyak digunakan. Untuk membangun GUI, untuk mengimplementasikan pemrosesan acara, loop utama diluncurkan. Solusi ini tidak bersinar dengan keanggunan. Untuk masuk ke dalam siklus seperti itu adalah masalah lain. Bahasa yang normal harus memiliki fasilitas penanganan acara.

Ide-ide saya tentu saja subjektif, dan bahkan mungkin salah. Tetapi mereka didasarkan pada pengalaman pribadi saya. OS modern adalah sekelompok sampah yang tidak di-debug, yang tidak akan pernah di-debug. Tumpukan API, berbagai pustaka tempat kesalahan mengalir. Jumlah bahasa pemrograman telah melampaui semua batas yang mungkin. Terlebih lagi, pada prinsipnya mereka sedikit berbeda satu sama lain. Dan umumnya saya tidak akan mengatakan apa-apa tentang jumlah kerangka kerja. Apa pun sistem rata-rata adalah kue multi-layer dari berbagai, mungkin subsistem yang tidak kompatibel, debugging penuh yang tidak akan pernah dilakukan. Debugging program C sederhana bisa memakan waktu berbulan-bulan. Dan semua ini menurut saya dihasilkan dengan mengetikkan bahasa pemrograman.

Saat ini, tidak ada bahasa yang memenuhi ide saya tentang bahasa pemrograman yang benar. Yang paling dekat dengan itu menurut saya adalah bahasa pemrograman MUMPS, tetapi tidak ada implementasi bahasa seperti bahasa pemrograman. Ada implementasi basis data di mana bahasa ini digunakan sebagai bahasa. Keterbatasan pendekatan ini jelas, yang membuat saya mengembangkan bahasa MSH baru dan menulis implementasinya sebagai penerjemah. Saat ini, tidak semua yang akan saya lakukan diimplementasikan di dalamnya. Secara khusus, tidak ada lingkungan pengembangan, tetapi Anda bisa mendapatkan ide bahasa.

Implementasinya dibuat untuk Linux x64.

Yang tertarik dengan pekerjaan saya, menulis surat, saya akan kirim distribusinya.
PS.
MSH bukan hanya bahasa yang tidak memiliki tipuan, tetapi juga tidak deklaratif. Pada prinsipnya, tidak ada deskripsi variabel di dalamnya. Dalam kasus umum, variabel tidak hanya memiliki tipe, tetapi juga struktur. Array, daftar, HASH, tumpukan, dan deklarasi diperlukan untuk menggambarkan masing-masing struktur. Pada MUMPS, pada prinsipnya tidak ada bahasa deklarasi, variabel apa pun adalah pohon. Tidak ada ruang untuk pohon seperti itu disediakan. Node pohon dibuat pada saat menulis data, dan hanya node seperti itu yang ada di mana rekaman dibuat. Tidak ada batasan pada tipe indeks. Karenanya, membandingkan MUMPS dengan PHP, Java Script, dan bahasa lain salah. MUMPS adalah dunia yang terpisah, dengan masalah dan kelebihannya sendiri. Untuk memahaminya, Anda perlu membangun kembali pemikiran. Mustahil untuk memahami MUMPS dengan membaca ulasan yang kasar. Kita harus membenamkan diri di dalamnya. Baca dokumentasinya. Instal sistem MUMPS. Kerjakan itu. Fakta bahwa mereka tidak mengerti saya di sini sangat wajar. Kita berbicara tentang dunia yang berbeda. Di dunia MUMPS tidak ada diskusi yang kami lakukan di sini tentang jenis, struktur. Beberapa MUMPSis tertarik pada bagaimana dan di mana data mereka disimpan. Setiap data dalam MUMPS selalu memiliki dua representasi: angka dan string. Dan tergantung pada operasinya, representasi ini atau itu diambil. Saya selalu tahu hasil pasti tergantung pada operasi yang saya terapkan. MUMPS memaksa programmer untuk bekerja dalam hal pohon. Pohon dapat ditemukan di media eksternal: global (analog basis data), dan di memori: lokal (analog variabel dalam program). Pada dasarnya, ketika merancang sistem informasi, saya langsung bekerja dengan data pada disk data lokal menengah, saya memiliki minimum dan mereka tidak membuat masalah bagi saya. Karenanya, di forum MUMPS Anda tidak akan menemukan diskusi tentang jenis variabel pelokalannya. Metode desain yang khas adalah merancang pohon input, akhir pekan. Dan kemudian, sebagaimana diperlukan, Anda menulis program untuk membentuk pohon input dan output. Data dalam MUMPS adalah primer, dan program bersifat sekunder. Dengan artikel saya, saya bertujuan untuk memperkenalkan sebanyak mungkin programmer ke dunia MUMPS lainnya. Saya pikir dunia ini lebih benar. Saya mengagumi bahasa yang sederhana, kuat, dan elegan ini. Ini memberi saya kesenangan untuk menulis di atasnya. Saya sangat menyesal, saya tidak punya banyak hal untuk dilakukan. Saya ingin membuat bahasa di mana semuanya dapat ditulis tanpa melampaui batas bahasa ini. Tulis server, tulis klien Desktop, tambahkan bahasa ke browser.

Source: https://habr.com/ru/post/id447668/


All Articles