Belajar bahasa pemrograman yang dirancang khusus untuk perusahaan itu [ditutup]


10

Mengapa seseorang mengembangkan bahasanya sendiri untuk menggunakannya hanya di dalam perusahaan itu ketika Anda memiliki XY bahasa lain yang dapat membantu Anda dengan perpustakaan, logika, dll.? Bukankah itu jauh lebih sederhana untuk mengikuti arus dengan hal lain daripada mengembangkan bahasa Anda sendiri?


6
Cukup banyak bahasa "baru" yang kita miliki di alam bebas dapat menggunakan pustaka yang dirancang untuk bahasa "lama": misalnya: C ++ dapat menggunakan C libs, Scala Kotlin dan lainnya dapat menggunakan lib apa saja yang berjalan di JVM, Scriptrip dapat menggunakan JS libs. Jadi memiliki bahasa baru tidak menyiratkan kehilangan dukungan lib ...
Timothy Truckle

3
Mengapa Anda membangun dragster untuk pergi balap drag daripada dengan stock car?
candied_orange

3
Atau sungguh, selidiki alasan dan rasional di balik pembuatan bahasa pemrograman apa pun. Beberapa orang percaya bahwa Anda bukan ilmuwan komputer sungguhan sampai Anda membuat bahasa Anda sendiri. Ini mirip dengan tidak menjadi insinyur kimia sungguhan sampai Anda telah membuat bubuk senjata (dan meledakkan sebagian kecil dari rumah Anda).
candied_orange

4
Erlang juga dilahirkan dengan cara ini: jika saya tidak salah itu awalnya dikembangkan di Ericsson untuk penggunaan internal.
Giorgio

3
Bahasa yang dirancang khusus untuk perusahaan itu bodoh, di sisi lain, bahasa yang dirancang khusus untuk domain masalah tempat perusahaan itu berada, kadang-kadang bisa sangat berguna. Anda tahu Anda memiliki yang terakhir, daripada yang pertama, ketika desain dan arsitektur bahasa dibatasi untuk apa yang membuat domain masalah lebih mudah untuk dipecahkan / diekspresikan, kadang-kadang dengan mengorbankan berguna untuk pemrograman tujuan umum.
Lie Ryan

Jawaban:


25

Jauh lebih mudah untuk dipahami ketika Anda menyadari bahwa itu seringkali merupakan hasil dari proses yang panjang dan bukan seseorang yang hanya mengatakan "kami ingin membuat bahasa baru".

Biasanya dimulai dengan gagasan bahwa beberapa masalah dapat diselesaikan dengan menggunakan bahasa khusus domain sederhana. Tujuannya adalah agar non-pakar menggunakan bahasa ini, sehingga sederhana dan seringkali tidak memiliki fitur seperti pengetikan dan modul yang kuat.

Sejauh ini baik. Tapi kemudian, orang mulai memukul masalah yang tidak bisa diselesaikan oleh bahasa. Jadi "fitur" baru ditambahkan secara perlahan untuk menyelesaikan masalah tersebut. Dan karena prosesnya lambat dan fitur-fiturnya jarang, tidak ada motivasi untuk merancang fitur-fitur baru itu dengan benar, selama masalahnya terpecahkan.

Seiring waktu, bahasa baru memperoleh fitur yang mengubahnya dari bahasa khusus domain sederhana menjadi bahasa tujuan "umum" yang kompleks, sering kali dengan semantik yang saling bertentangan, membingungkan, dan aturan sintaksis yang sulit diikuti.

Dan pada saat orang-orang menyadari bahwa mereka menciptakan binatang buas sebesar itu, sudah terlambat untuk membunuhnya dan menggantinya dengan bahasa yang dirancang dengan baik.

Ada beberapa bahasa yang berkembang seperti ini yang tidak terikat kepada perusahaan tertentu batuk JavaScript batuk PHP batuk .


10
Jawaban yang bagus, dan sementara JavaScript memiliki masalah, saya pikir itu tidak adil untuk memasukkannya ke dalam kalimat yang sama dengan PHP. Itu seperti mengatakan, "Kita harus mengusir Bill dan Ted dari lingkungan kita, mereka adalah penjahat!" Tapi, Bill (JavaScript) adalah jaywalker, dan Ted (PHP) adalah pembunuh berantai.
TheCatWhisperer

12
@TheCatWhisperer saya tidak setuju. JavaScript sama buruknya, atau bahkan lebih buruk dari PHP. Karena Anda HARUS menggunakan (atau memindahkan ke) JavaScript, sementara PHP dapat diabaikan dengan aman.
Euforia

2
itu adalah poin yang paling valid.
TheCatWhisperer

1
@Euphoric Mari kita menunggu WASM , mungkin adegan akan berubah kemudian ...
Kroltan

@Kroltan +1 untuk WASM!
CraigR8806

15

Bukankah itu jauh lebih sederhana untuk mengikuti arus dengan hal lain daripada mengembangkan bahasa Anda sendiri?

Tentu, tetapi untuk mengikutinya sampai akhir yang tidak masuk akal, kita semua akan menulis semuanya dalam pertemuan jika tidak ada yang mengembangkan bahasa baru.

Terkadang tidak ada aliran. Bahasa baru muncul karena seseorang memiliki gatal untuk menggaruk, apakah itu hobi bahasa yang hanya ingin menciptakan sesuatu yang baru atau perusahaan dengan kebutuhan yang tidak terpenuhi oleh apa yang sudah ada.

Inilah yang terjadi ketika John Backus mengusulkan Sistem Penerjemahan Formula Matematika IBM pada tahun 1953. Dia menginginkan cara yang lebih mudah bagi pengguna ilmiah untuk menentukan rumus matematika daripada dengan menuliskannya dalam perakitan. Produk berpemilik itu menjadi bahasa pemrograman pertama yang bukan perakitan, dan Anda tahu itu Fortran.

Di mana Fortran adalah orang pertama yang menempuh rute itu, Erlang cukup banyak menjadi anak poster untuk itu. Ericsson ingin meningkatkan cara perangkat lunak untuk sakelar teleponnya dikembangkan dan menemukan bahasa untuk membuat prototipe dengan fitur-fitur khusus untuk apa yang mereka butuhkan. Ketika saya pertama kali menjelajahinya, takeaway saya adalah itu dikembangkan oleh orang-orang dengan masalah nyata untuk dipecahkan yang tidak akan dilayani dengan baik oleh bahasa lain yang tersedia pada tahun 1986. Erlang tetap menjadi produk in-house yang dipatenkan seperti produk Anda kolega bertemu sampai bersumber terbuka lebih dari satu dekade kemudian, dan sekarang bahasa utama.

Baik Go dan Scala adalah bahasa yang relatif muda dalam skema besar hal, dan sangat mungkin bahwa bahasa yang digunakan di perusahaan kolega Anda mendahului keduanya. Apa yang perlu dia lakukan adalah bertanya tentang sejarahnya, mengapa itu ada dan mengapa terus digunakan.

Saya menghabiskan dekade antara tahun 2003 dan 2013 bekerja untuk sebuah perusahaan yang banyak menggunakan lingkungan khusus industri yang mencakup bahasanya sendiri yang berakar pada akhir 1970-an. Sementara beberapa bahasa yang lebih baru mungkin merupakan pengganti yang lebih cocok (dan kaitannya dengan mereka dicangkokkan seiring waktu), industri itu memiliki investasi yang cukup besar di dalamnya dan sejumlah besar kode yang telah terbukti bahwa tidak ada kasus bisnis yang baik untuk beralih ke sesuatu yang lain.


-1

Saya pernah melihat ini sebelumnya. Itu tidak pernah bekerja dengan baik. Beberapa orang memiliki kompleks "tidak ditemukan di sini". Ini biasanya menyebabkan perusahaan berlarian menciptakan kembali roda.

Pikirkan tentang itu. Bahasa baru ini mungkin rusak sepanjang waktu. Antara parser, compiler, VM, linker, apa pun ... Sekarang ada ribuan bug yang orang-orang akan buang waktu debugging dengan masalah acak. Semua untuk apa yang mereka pikir mereka butuhkan yang tidak dimiliki bahasa lain.

C / C ++ digunakan untuk menulis sistem operasi seperti, Anda tahu, semuanya. Namun seseorang berpikir mereka membutuhkan sesuatu yang berbeda.


7
Tampaknya Anda belum pernah melihat Kotlin. Atau Javascript atau C #, dalam hal ini. Fog Creek Software menggunakan bahasa pemrograman mereka sendiri yang disebut Wasabi (berdasarkan VB) selama bertahun-tahun (meskipun diakui utang teknis akhirnya menyusul mereka ). Jadi pasti ada kasus di mana ia bekerja.
Robert Harvey

1
Sejauh yang saya ingat, C # lahir setelah Microsoft mencoba untuk membuat implementasi Java yang tidak sesuai, dituntut oleh Sun dan hilang. cnet.com/news/sun-microsoft-settle-java-suit Karena mereka tidak bisa menyebutnya Jawa lagi, mereka mengembangkan bahasa mereka sendiri, yang pada awalnya sangat mirip dengan Java.
Giorgio

1
"Bahasa baru ini mungkin rusak sepanjang waktu" - jika desain bahasa Anda memungkinkan Anda untuk menghindari seluruh kelas bug aplikasi, maka ini bisa menjadi tradeoff yang dapat diterima
Eric

16
Pernah dengar tentang C? Itu dilaporkan dikembangkan di rumah hanya untuk sistem operasi tunggal pada satu komputer. Mengapa K&R tidak hanya menggunakan sesuatu yang terbukti digunakan untuk menulis sistem operasi, seperti PL / 1, BCPL atau Algol 68?
idrougge
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.