Apakah ada bahasa tingkat sangat tinggi di luar sana? [Tutup]

Secara historis HLL adalah sesuatu seperti C, Fortran atau Pascal dan VHLL adalah sesuatu seperti Ruby atau Python. Saya akrab dengan istilah 4GL, 5GL, DSL dan LOP, dan mereka yang tidak harus membaca Wikipedia untuk definisi. Saya mencari UHLL.

Pertanyaan saya adalah: apakah ada bahasa komputer di luar sana yang urutan besarnya lebih produktif, dan adakah yang mengerjakannya?

Lebih produktif berarti lebih sedikit kode yang dituliskan dan lebih sedikit waktu programmer untuk mencapai hasil, lebih sedikit bug dan lebih sedikit debugging, hubungan konseptual yang lebih dekat antara kode dan persyaratan, lebih sedikit upaya untuk memodifikasi dan memelihara.

Domain utama yang menarik minat saya adalah aplikasi bisnis dan konsumen untuk tujuan umum, dengan GUI atau browser, ketekunan data dan koneksi ke sistem lain seperti pencetakan dan email. Orang lain mungkin fokus di tempat lain.

Saya menyadari bahwa beberapa bahasa itu mungkin khusus untuk domain, dan mungkin lebih sedikit dari kemampuan konfigurasi aplikasi yang besar dan mampu. Lembar kerja Excel termasuk dalam kategori ini.

Saya menyadari bahwa beberapa bahasa itu mungkin tampak umum, tetapi mungkin masih sempit cakupannya dan tidak cocok untuk banyak masalah. Sebagai contoh, Matlab mungkin bukan pilihan yang baik untuk program yang terutama berhubungan dengan interaksi pengguna dan data tekstual.

Saya tahu beberapa fitur yang mungkin ada di UHLL, dengan analogi dengan VHLL. Saya berharap menemukan satu atau lebih dari yang berikut (dan jangan ragu untuk menambahkan ke daftar):

• Gambar bentuk GUI ADALAH program untuk bentuk GUI
• Tabel yang berisi baris, kolom, dan header adalah program untuk tabel dalam database
• Logika deklaratif mengatakan apa yang harus dilakukan dan kapan, tanpa pernyataan IF
• Operasi pada set data, tanpa loop UNTUK
• Eksekusi non-sekuensial misalnya didorong data, pencocokan pola, berjalan pohon

Motivasi untuk pertanyaan ini adalah bahwa saya semakin muak dengan kerja keras semata-mata menerjemahkan persyaratan bisnis yang relatif sederhana menjadi sejumlah besar kode untuk memenuhi apa yang diinginkan atau dibutuhkan komputer. Pertanyaannya adalah benar-benar tentang menemukan orang lain di luar sana yang berbagi rasa sakit saya dan sedang berupaya meningkatkan tingkat bahasa dan membuat komputer melakukan lebih banyak kerja keras. Ini adalah fokus utama di tahun 1970-an-80-an, tetapi apakah itu masih terjadi?

Ini adalah beberapa jawaban yang disarankan untuk pertanyaan saya, yang disediakan di sini untuk meringkas atau menghitung bahasa yang saya ketahui, dan yang menurut saya kurang.

Ada banyak bahasa yang HLL atau VHLL dan berisi fitur individual yang termasuk tingkat yang lebih tinggi. Saya telah menggunakan sebagian besar dari mereka (sering buruk). Mereka termasuk

• Lisp, dengan makro dan kemampuannya memodifikasi sendiri
• Haskell, dengan ketergantungan data dan pencocokan pola
• SQL, yang berhubungan dengan baris dan tabel
• Rebol, yang tampaknya pintar tapi aku tidak benar-benar mengerti
• APL (dan J), dengan array multi-dimensi dan operator ultra-kompak
• C # dengan LINQ
• AWK / Perl / Python / Ruby dengan koleksi indah dan regex bawaan

Bahasa-bahasa ini memiliki terlalu banyak fitur tingkat rendah untuk menjadi UHLL. Programmer masih harus menulis banyak konstruksi tingkat rendah untuk setiap program yang bermanfaat.

Ada paket RAD / 4GL. Saya telah menggunakan beberapa:

• dBase / Foxpro
• Dataflex / Powerflex (produk saya)
• Mengakses
• PowerBuilder

Dan masih banyak lagi yang belum saya gunakan. Sebagian besar bahasa adalah HLL paling baik tetapi paket berisi kerangka kerja dan koneksi istimewa antara bahasa dan paket sehingga aplikasi dapat dibangun dengan cepat. Saya tidak yakin mengapa pendekatan ini kehabisan tenaga, tetapi bagaimanapun UHLL ini tidak.

Ada kerangka kerja / perpustakaan mentah. Saya telah menggunakan beberapa:

• Rel
• Java awt dan swing
• .NET Windows Forms, WPF dan ASP.NET.

Ini saat ini canggih. Mereka meninggalkan programmer dengan kuat terjebak dalam lumpur bahasa implementasi, berurusan dengan kompleksitas di setiap kesempatan. Ini bukan UHLL, tetapi UHLL mungkin dibangun di atas salah satunya.

Ada alat desain, seperti toolset UML dan Rational, yang saya tidak tahu dengan baik. Sejauh yang saya lihat mereka membantu mengartikulasikan persyaratan bisnis tetapi tidak pernah bisa menggantikan langkah pemrograman. Saya tidak ingin menghilangkan programmer, hanya menyelesaikan lebih banyak per unit waktu dan usaha.

Jadi, setelah menyingkirkan semua pesaing saya dapat berpikir, saya berharap orang lain dapat memberikan kandidat yang lebih baik.

Edit Terlambat: Saya rasa saya punya jawaban: Bahasa Wolfram. http://www.wolfram.com/wolfram-language/

Hampir semua kriteria yang Anda daftarkan adalah hal-hal yang sudah dicoba di alat 4GL / RAD seperti MS Access, Sybase Power Builder, Formulir Oracle, Ruby-on-Rails (sebagai spesimen yang lebih modern untuk Aplikasi Web), dan banyak lagi (lihat Wikipedia untuk daftar vendor yang sangat panjang). Dan memang, menerjemahkan persyaratan bisnis yang relatif sederhana ke dalam beberapa jenis program dapat dengan sangat cepat dicapai dengan alat-alat ini. Itu sebabnya sebagian besar vendor alat RAD mengiklankan produk mereka sedemikian rupa sehingga setiap orang harus berpikir mereka telah menemukan UHLL menurut Anda.

Tangkapannya adalah, segera setelah Anda meninggalkan dasar persyaratan menjadi " relatif sederhana ", dan segera setelah Anda harus memelihara dan mengembangkan program yang ditulis dengan lingkungan ini, Anda akan melihat bahwa Anda dengan mudah mencapai batas dan memperhatikan kekurangannya. , atau untuk menerapkan persyaratan dengan mereka sama sekali tidak lebih sederhana daripada dengan "VHLL" lain yang ada dalam pikiran Anda. IMHO ada peluang bagus bahwa ini akan membunuh peningkatan efisiensi apa pun yang Anda miliki di versi 1.0 saat melangkah lebih jauh ke versi 1.1, 1.2 dan 1.3 dari program Anda.

Jika Anda ingin membangun perangkat lunak untuk persyaratan yang kompleks, Anda memerlukan lingkungan pemrograman yang kompleks. Masih tidak ada peluru perak , kami hanya mengalami peningkatan secara bertahap selama bertahun-tahun dan tidak "urutan besarnya" dalam produktivitas dengan bahasa pemrograman saat ini di atas pendahulunya (setidaknya, selama 30 tahun terakhir, yang merupakan sekitar waktu di masa lalu ketika artikel Brook diterbitkan).

Bahasa pemrograman tingkat tertinggi yang saya tahu adalah APL . Ini membutuhkan keyboard khusus untuk mewakili semua simbol yang diperlukan. Lihat video ini , di mana penulis menulis implementasi lengkap Game Kehidupan Conway dalam waktu sekitar tujuh menit.

Pertanyaan sesungguhnya, tentu saja, "apakah ini praktis?" Bisakah saya menemukan cukup programmer APL di dunia untuk mempertahankan bisnis dengan cara ini? Apakah APL akan berjalan di ponsel dan tablet? Apakah saya benar-benar perlu membeli semua pengembang perangkat lunak keyboard baru saya?

Jika Anda benar-benar menginginkan peningkatan produktivitas, taruhan terbaik Anda mungkin adalah beberapa varian Lisp. Clojure berjalan pada JVM, dan memiliki port .NET. Saya mengatakan ini karena orang sudah melakukannya; mesin pencari Orbitz berjalan pada Lisp, dan Paul Graham menjalankan seluruh bisnis menggunakan Lisp, mengklaim bahwa itu memberinya keuntungan yang signifikan atas para pesaingnya (yang semuanya menggunakan Java).

Perhatikan bahwa, semakin tinggi level bahasa pemrograman Anda, semakin banyak itu dihapus dari perangkat keras yang sebenarnya, dan semakin besar kemungkinan Anda akan memiliki masalah kinerja. Kecuali Anda memiliki kompiler yang benar-benar canggih, Anda mungkin masih menemukan diri Anda sedang mengkodekan bagian-bagian penting kinerja dari aplikasi Anda dalam bahasa yang lebih berkinerja lebih baik, tingkat yang lebih rendah dari waktu ke waktu.

Dan masih ada masalah memiliki sejumlah besar pengembang berpengalaman dalam bahasa. Terlepas dari semua kutilnya, Anda tidak akan pernah kesulitan menemukan programmer Java.

Perhatikan bahwa bahasa umum masih terus berkembang. Linq dibuat untuk tujuan khusus membuat pemrograman berbasis data lebih deklaratif. Beberapa fitur baru ditambahkan ke bahasa C # untuk membuat Linq berfungsi; semuanya harus dilakukan dengan meningkatkan produktivitas pengembang.

Bacaan Lebih Lanjut
Mengalahkan Rata-Rata

Saya pikir Anda telah mengisyaratkan sedikit pada titik lintas yang membatasi keberadaan bahasa Tingkat Tinggi Ultra - pada titik tertentu kami tidak mengidentifikasi mereka sebagai bahasa pemrograman lagi.

Contoh terbaik dari fenomena khusus ini yang saya ketahui, dan yang mungkin sangat menarik di sini, adalah Unified Modelling Language . Memang, ada tumpukan aplikasi perangkat lunak tertentu yang telah dikembangkan untuk secara spesifik melakukan apa yang Anda minta. Ini memenuhi banyak persyaratan Anda, tetapi tidak harus dengan cara Anda berpikir. Namun, ini sangat mendidik untuk situasi ini, karena saya merasakan hal yang sama dan pengalaman saya (yang mengikuti) telah mengubah cara saya berpikir tentang masalah ini.

Di sini saya pribadi akan berbicara tentang Arsitek Perangkat Lunak Rasional IBM , yang merupakan upaya untuk benar-benar memungkinkan pengembangan Ultra High Level. Tujuannya adalah agar Anda dapat membuat konsep bisnis filosofis sebagai objek, seperti Aktor atau Kelas, memberikan atribut entitas, menentukan koneksi, menentukan bagaimana informasi dapat mengalir melalui sistem saat sedang dikerjakan, dan melakukan ini semua dengan GUI.

Misalnya, Anda dapat menyeret objek DataStore, Aktor, formulir, beberapa Kelas yang relevan (seperti Pelanggan, dll), menggambar beberapa garis koneksi antara objek menggunakan grafik dan semacamnya, dan boom: ketika Anda selesai, Anda menerbitkan program kerja. (ini jelas sangat disederhanakan)

Memang, apa yang telah dilakukan adalah pembentukan GUI yang kompleks, implementasi / interpretasi UML yang sangat menyeluruh, dan kemudian dikompilasi ke kode Java / C # / VB dengan dokumen XML lengkap yang menyimpan info grafik UML, dan mereka juga mengimplementasikan / mengaktifkan Round-Trip Engineering sehingga Anda dapat bolak-balik antara Model dan Kode sehingga Anda dapat mengontrol berbagai hal baik pada level filosofis yang sangat tinggi maupun kode spesifik platform level yang sangat rendah.

Ini semua yang Anda inginkan, dan lebih banyak lagi, dan Anda tidak menyerah dalam pertukaran! Kanan?

Mengapa tidak semua orang menggunakannya?!?!

... yah, begitulah. Apa yang sebenarnya Anda dapatkan adalah usaha monolitik, semuanya melibatkan banyak bagian yang bergerak dan sihir, semuanya - atau kadang-kadang tidak - dipengaruhi oleh perubahan di banyak tempat berbeda (di GUI, XML, level bawah) kode, model UML yang dibuat / didefinisikan / dipelihara sendiri dalam berbagai level model).

Ini semua benar-benar keren untuk dimainkan, tetapi ini adalah ... bagaimana menempatkan ini ... ia memiliki kurva belajar yang sangat tinggi, dirancang dengan berbagai disiplin ilmu dalam pikiran, dan Anda benar-benar harus memperlakukannya sebagai hal yang benar-benar baru yang memungkinkan sedikit - sangat sedikit - generalisasi untuk keterampilan lain yang sudah Anda miliki.

Dan intinya adalah - meski begitu, dengan jutaan demi jutaan yang dituangkan ke dalam proyek dari lusinan perusahaan dan beberapa nama besar di belakangnya, Anda masih berakhir dengan kode gaya C pada lapisan yang dapat dieksekusi yang harus diedit langsung pada waktu tertentu. , karena beberapa hal tidak membuat terjemahan antara Deskripsi Kelas Berorientasi Objek dan UML ke tingkat pemrograman / mesin, dan otomasi tidak bisa cukup lengkap.

Pengalaman saya adalah bahwa itu adalah cara yang sangat rumit untuk menghasilkan perancah. Itu mungkin hal paling kejam yang pernah saya katakan tentang upaya teknologi yang sangat besar, tapi itulah yang saya dapatkan dari itu.

Dari orang-orang di industri yang saya ajak bicara, mereka dengan sedih mengatakan hal yang sama. Perasaan mereka adalah mereka melakukan banyak pekerjaan membuat dokumentasi, diagram yang tak terhitung jumlahnya, model, pertemuan, analisis, selama berbulan-bulan dan berbulan-bulan, dan kemudian mereka membuang semuanya dan tim pengembangan hanya menulis kode untuk itu dan sering hanya memperlakukannya sebagai Belum Binder Spesifikasi Lain (Yang Tidak Ada Yang Pernah Membaca Lagi). Jadi sekarang mereka hanya menggunakan Java dan beberapa perangkat lunak diagram / visualisasi tujuan khusus, dan Agile, dan itulah akhir dari cerita itu.

Mungkin ini tidak adil, dan itu berhasil ketika Anda melakukannya dengan benar. Mungkin, tetapi dari konsultan dan profesor saya telah berbicara dengan mereka mengklaim telah menghabiskan berjam-jam di lokakarya pengembangan multi-minggu khusus bekerja untuk mempelajari sistem, dan kembali untuk pelatihan lebih lanjut, dan secara harfiah menghabiskan bertahun-tahun untuk belajar bagaimana membuatnya. bekerja dan apa yang terjadi di mana.

Tapi mungkin itu semua kesalahan pemrogram, bahwa mereka hanya menolak untuk menerima sistem bekerja dengan baik namun tidak seperti pemrograman komputer sama sekali. Mungkin programmer kode murni hanya menolak untuk mengganti pekerjaan mereka, seperti pembuat lilin dan penenun tua, dan menolak untuk hanya melakukan tugas terbatas mereka Implementasi Untuk Spesifikasi dan ini membuat semua orang menjadi sangat frustrasi mereka membuangnya dan mengatakan hal-hal buruk, dan itu Hampir Sempurna.

Tapi ... Saya pikir mungkin ada beberapa kebenaran dalam hal itu, namun saya pikir sebagian besar itu tidak benar-benar berfungsi dengan baik. Saya pikir itu mengubah sesuatu yang tidak terlalu sulit sebagian besar waktu (pemrograman komputer), dan membuatnya lebih sulit ke titik bahwa jika bekerja itu akan menjadi besar, tetapi omong kosong suci Anda memiliki waktu yang lama tanpa apa-apa untuk tunjukkan untuk sampai ke sana!

Mungkin itu hanya akan bekerja di perusahaan dengan ribuan tim, dan mungkin kita belum sampai.

Saya tidak tahu.

Namun, sebuah studi tentang apa yang benar, dan salah, dengan pendekatan ini ke Bahasa Tingkat Tinggi Ultra - dan saya pikir jenis UML perlu dimasukkan dalam pertimbangan seperti itu - benar-benar harus mempertimbangkan hal-hal seperti Arsitek Perangkat Lunak Rasional, untuk menghindari orang bodoh yang potensial suruh.

Atau mungkin kita hanya perlu memberinya 20-50 tahun kerja keras. Saya tidak lagi optimis bahwa bahasa pemrograman adalah kendala, lagi.

Dan jika bahasa pemrograman adalah kendala sebelumnya, itu sebabnya perbaikan memberi kami urutan peningkatan besar. Jika mereka tidak lagi menjadi kendala seperti itu, maka inovasi apa pun lebih mungkin tidak mampu memberikan urutan peningkatan seperti itu. Tapi aku tidak bisa mengatakan masa depan! Jadi saya akan menganggap sisanya bukan "dalam karya", tetapi tentu saja "terlalu dini untuk mengatakan".

Jika Anda memikirkannya untuk sementara waktu, pemrograman tingkat yang lebih tinggi pada dasarnya mampu menyusun bagian-bagian yang lebih kecil yang sudah tersedia dan terbukti. Sampai pada titik di mana program Anda adalah kode lem yang sangat sederhana dari berbagai perpustakaan. Mungkin lemnya adalah DSL yang sangat ekspresif. Anda dapat melakukan ini di setiap bahasa pemrograman.

Secara pribadi, saya semakin mulai merasakan bahwa solusi untuk kompabilitas adalah - bertentangan dengan apa yang Anda rasakan secara naluriah - tidak ditemukan dalam pemrograman berorientasi objek. Paradigma ini, serta pemrograman imperatif, memberikan terlalu banyak kebebasan untuk programmer yang pada gilirannya membuatnya terlalu sulit untuk menulis kode yang mudah digunakan kembali.

Sebaliknya, saya pikir pemrograman fungsional menyediakan primitif yang jauh lebih cocok untuk kompabilitas. Bahasa pemrograman fungsional murni juga tidak memungkinkan Anda untuk mendefinisikan fungsi yang memiliki efek samping, yang tidak hanya mengurangi bug atau memudahkan mereka melihatnya, tetapi juga membuatnya lebih mudah untuk dibangun di atasnya (menyusunnya ke sistem yang lebih besar).

Jika Anda tertarik dengan pemrograman fungsional, Anda dapat melihat bahasa fungsional modern seperti Haskell . Saya pikir bahwa modul Parsec menyediakan DSL tingkat tinggi yang bagus (itu disebut perpustakaan kombinator dalam jargon fungsional) untuk parsing. Ada juga kerangka kerja pemrograman reaktif fungsional untuk Haskell yang memungkinkan Anda untuk membangun GUI yang kuat dengan beberapa baris kode.

Saya berharap bahwa Lua, seperti yang digunakan oleh game untuk skrip pencarian dan antarmuka mereka akan memenuhi kriteria ini. Ada juga bahasa khusus domain serupa (dan utilitas pembuat peta) yang digunakan untuk memungkinkan perancang level dengan cepat dan mudah mengatakan "ketika pemain berbicara dengan Bob, mulai Bob's Epic Quest".

Saya tahu beberapa bahasa esoteris yang lebih fokus pada pemindahan kode untuk menggambarkan apa yang sedang terjadi, bukan bagaimana hal itu seharusnya dilakukan. Beberapa fokus pada pendekatan berbasis logika yang sangat deklaratif. Beberapa fokus pada pemrograman reaktif untuk melakukan itu. Beberapa fokus pada aktor untuk melakukan itu (terutama untuk hal-hal yang perlu diparalelkan). Beberapa fokus hanya pada membuat sintaksis lebih alami - dengan pernyataan bahwa sintaksis alami menyebabkan lebih sedikit bug yang disebabkan oleh menerjemahkan antara bahasa alami dan kode.

Tidak ada yang benar-benar menjanjikan sejauh menghasilkan urutan besarnya lebih banyak produktivitas untuk pangkat dan pengembang file.

Saya pikir REBOL mungkin cocok dengan semua kriteria Anda. Anda dapat membuat aplikasi GUI yang relatif canggih dalam beberapa baris kode - namun "kekhususannya" adalah pembuatan DSL.