Apa yang ingin diperhatikan oleh para perancang bahasa? [Tutup]


38

Tujuan dari pertanyaan ini bukan untuk mengumpulkan daftar cucian fitur bahasa pemrograman yang Anda tidak dapat hidup tanpanya, atau berharap berada dalam bahasa pilihan utama Anda. Tujuan dari pertanyaan ini adalah untuk menjelaskan sudut-sudut desain bahasa yang sebagian besar desainer bahasa mungkin tidak pikirkan. Jadi, alih-alih memikirkan fitur bahasa X, pikirkan sedikit lebih banyak secara filosofis.

Salah satu bias saya, dan mungkin itu mungkin kontroversial, adalah bahwa sisi teknik yang lebih lunak - mengapa dan apa alasannya - berkali-kali lebih penting daripada sisi yang lebih konkret. Misalnya, Ruby dirancang dengan tujuan yang dinyatakan untuk meningkatkan kebahagiaan pengembang. Sementara pendapat Anda mungkin beragam, apakah itu disampaikan atau tidak, fakta bahwa itu adalah tujuan berarti bahwa beberapa pilihan dalam desain bahasa dipengaruhi oleh filosofi itu.

Tolong jangan posting:

  • Sintaks perang api. Mari kita hadapi itu, kita memiliki preferensi kita, dan sintaksis penting karena berkaitan dengan desain bahasa. Saya hanya ingin menghindari pertempuran epik tentang sifat emacs vs VI (yang tidak diketahui oleh banyak orang saat ini).
  • "Bahasa apa pun yang tidak memiliki fitur X tidak layak ada" ketik komentar. Setidaknya ada satu alasan untuk semua bahasa pemrograman ada - baik atau buruk.

Tolong lakukan posting:

  • Ide-ide filosofis yang tampaknya dilewatkan oleh perancang bahasa.
  • Konsep teknis yang tampaknya diimplementasikan dengan buruk lebih sering daripada tidak. Tolong berikan contoh rasa sakit yang disebabkannya dan jika Anda memiliki ide tentang bagaimana Anda ingin berfungsi.
  • Hal-hal yang Anda inginkan ada di perpustakaan umum platform tetapi jarang ada. Satu hal yang sama, hal-hal yang biasanya ada di perpustakaan umum yang Anda inginkan tidak.
  • Fitur konseptual seperti dukungan penanganan uji / pernyataan / kontrak / kesalahan bawaan yang Anda harap semua bahasa pemrograman akan terapkan dengan benar - dan mendefinisikan dengan benar.

Harapan saya adalah bahwa ini akan menjadi topik yang menyenangkan dan membangkitkan semangat.

Sunting: Mengklarifikasi apa yang saya maksud dengan Syntax Flame Wars. Saya tidak mencoba untuk menghindari semua diskusi tentang sintaks, terutama karena sintaks adalah bagian mendasar dari desain bahasa program.


Mengatakan bahwa sintaks hanyalah detail implementasi sama sekali salah. Desain sintaksis adalah bagian penting yang mendasar dalam mendesain bahasa. Dan banyak poin yang Anda lakukan ingin melihat diposting sebenarnya mungkin melibatkan sintaks. Kasihan. Tampak seperti pertanyaan menarik.
Konrad Rudolph

Yang ingin saya hindari adalah perang api. Jika Anda dapat mendiskusikan sintaksis tanpa memulai nyala api, lakukanlah.
Berin Loritsch

Jawaban:


49

Dukungan Unicode secara default

Hari ini dan usia, program sedang dikembangkan untuk digunakan secara internasional, atau dengan asumsi bahwa mereka dapat digunakan secara internasional. Mereka harus memberikan dukungan untuk rangkaian karakter mereka atau membuat program yang ditulis dalam bahasa itu tidak berguna.


2
+1 Sebenarnya, bahasa itu sendiri harus memungkinkan Anda untuk menggunakan karakter apa pun untuk pengidentifikasi Anda. Kita tidak semua berbahasa Inggris.
Berin Loritsch

13
@Berin: Sebenarnya, meskipun saya orang Prancis, saya lebih suka program bahasa Inggris. Masalahnya adalah salah satu dari komunikasi, jika Anda menulis program dengan pengidentifikasi Hungaria, Spanyol atau Portugis, jangan berharap saya akan pernah bisa masuk ... dalam konteks internasionalisasi itu sangat penting bahwa pengembang dapat berkomunikasi antara mereka sendiri , dan itu menyiratkan menggunakan bahasa umum untuk pengidentifikasi, komentar dan dokumentasi. Bahasa Inggris adalah lingua franca pengembang.
Matthieu M.

11
Saya akan menambahkan bahwa dukungan unicode seharusnya alami ketika menggunakan bahasa. Jika mungkin, tidak perlu usaha ekstra untuk "menambahkannya", itu harus "hanya bekerja" (jika memungkinkan).
RHSeeger

4
Terkait, bahasa harus membuat perbedaan mendasar antara data teks (urutan karakter) dan biner (urutan byte). C # mendapatkan ini dengan stringdan byte[]. Seperti halnya Python 3.x dengan strdanbytes . C (++) charsalah mengerti.
dan04

1
@RHSeeger - memang !!! Bahkan dengan Python Anda harus mengetik u'My Unicode Štring'. Saya harap Anda bisa melupakan jenis string yang Anda hadapi dan menulis kode.
orokusaki

25

Saya punya pasangan:

  • Generik / templat. Misalnya, generik Java sangat kuat, tetapi tidak selalu fleksibel. Juga, karena mereka menggunakan tipe erasure, saya telah melihat masalah menerapkannya secara abstrak, terutama di antarmuka. Dan kompiler tidak boleh memperingatkan ketika generik non-spesifik digunakan (Suka Hashmapbukan Hashmap<String, int>). Saya pikir mereka dapat ditingkatkan secara signifikan. Templating yang baik sangat berguna, tetapi sering diabaikan.

  • Dukungan Good Date di perpustakaan standar. Maksud saya bisa menambah dan mengurangi tanggal, jam, dan menit, dan tidak harus berurusan dengan jumlah milidetik sejak 1 Januari 1970.


2
"dukungan kencan yang baik" adalah persyaratan yang cukup curam! apa artinya itu? Saya pikir tanggal dan waktu adalah salah satu hal di mana Anda tidak bisa mendapatkan semuanya baik-baik saja. baik Anda membuatnya sederhana dan salah, atau Anda membuatnya benar dan rumit yang durhaka. SANGAT sulit untuk mencapai titik tengah yang baik.
sara

@ Kai Intinya adalah bahwa dukungan tanggal biasanya sangat mengerikan. Yang lama java.util.Datememiliki hampir semua kemungkinan gotcha dan masalah. Saya hanya tahu sebagian dari java.time.*paket baru , tetapi bersih, mudah digunakan dan bebas bug AFAICT. Lebih banyak pengguna tingkat lanjut mungkin menemukan masalah, tetapi ini merupakan peningkatan besar. +++ Masalahnya tampaknya, bahwa ini adalah masalah yang rumit dan versi pertama terburu-buru dan rusak.
maaartinus

24

Harap membuat bahasa Anda dapat dianalisis / diaudit untuk petugas keamanan komputer.

Orang-orang keamanan harus dapat menemukan kerentanan dalam suatu program sebelum dikirimkan. Idealnya, kami dipanggil lebih awal dan dapat mengomentari basis kode saat itu berkembang, tetapi seringkali tidak.

Ketika versi baru dari bahasa atau pustaka inti keluar, hal-hal yang sebelumnya aman mungkin tidak lagi:

  1. perpustakaan mungkin menjadi lebih kuat: mis. perpustakaan URL sekarang mendukung javascript:
  2. mungkin ada cara baru untuk mengubah string atau byte menjadi kode: mis. evalatau deserialization libraries
  3. teknik refleksi bahasa dapat menjadi lebih kuat: misalnya mengekspos variabel lokal

Setiap perubahan ini dapat meningkatkan jumlah otoritas yang dapat disalahgunakan oleh suatu program, tetapi karena jumlah kewenangan yang digunakan oleh program (ketika berhadapan dengan klien yang tidak jahat) belum berubah, petugas keamanan sulit sekali menemukan jawabannya tanpa intensif audit ulang.

Jadi, tolong pikirkan tentang kami saat merancang dan membuat versi bahasa. Berikut adalah beberapa tips:

Tetapkan beberapa primitif bahwa suatu program dapat diuraikan menjadi.

HTML5 sangat buruk dengan cara ini. Mereka jelas telah menaruh banyak pemikiran dalam keamanan dan memiliki beberapa orang yang sangat pintar, tetapi alih-alih menspesifikasikan elemen program baru seperti <video>dalam hal yang lama, atau membuat abstraksi umum yang baru <video>dan lama <img>keduanya dapat ditentukan dalam hal,<video> belum elemen program satu kali lainnya dengan konsekuensi keamanannya sendiri.

Jadikan bahasa Anda setuju dengan analisis statis (meskipun tidak diketik secara statis).

Orang-orang keamanan sering menggunakan analisis statis untuk menemukan pola, dan untuk mencoba dan mengesampingkan bagian-bagian dari suatu program sehingga mereka dapat fokus pada bit yang benar-benar rumit.

Harus jelas pengidentifikasi mana yang merupakan variabel lokal dan mana yang tidak.

Misalnya, jangan membuat kesalahan yang sama dengan JavaScript versi lama yang membuatnya tidak mungkin untuk mengetahui apakah xada referensi variabel lokal di bawah ini (menurut pembacaan literal dari versi lama spec):

if (Math.random() > 0.5) {
  Object.prototype.x = 0;
}

function f() {
  var x = 1;
  (function () {
    alert(x);  // Might alert 0, might alert 1.
  })();
}

Izinkan keamanan terurai

Banyak sistem yang aman dirancang di sekitar kernel yang aman yang menjaga properti keamanan, sehingga rakyat keamanan dapat memfokuskan upaya mereka pada menganalisis sejumlah kecil kode dan membebaskan sebagian besar programmer dari harus berurusan dengan rakyat keamanan {annoying, pedantic, paranoid} security .

Seharusnya dimungkinkan untuk menulis kernel seperti itu dalam bahasa Anda. Jika salah satu properti keamanan bahasa Anda, apakah hanya sebagian URL saja yang akan diambil, dapatkah penulis kernel melakukan sesuatu untuk menyalurkan semua URL yang mengambil kode mereka? Atau dapatkah pemeriksaan build statis (seperti melihat impor) melayani fungsi yang sama.

Beberapa bahasa seperti Newspeak menggunakan model kemampuan objek. Itu luar biasa dan cara yang bagus untuk mendapatkan keamanan yang terurai.

Tetapi jika Anda tidak dapat melakukan itu, membuat grafik modul menjadi artefak yang dapat dianalisis secara statis dapat memberi Anda cukup banyak manfaat. Jika saya dapat membuktikan bahwa suatu modul tidak dapat mencapai modul I / O file (kecuali dengan memanggil kode dalam sebuah modul di TCB), maka saya dapat mengesampingkan seluruh kelas masalah dari modul itu.

Batasi otoritas bahasa skrip tertanam

Banyak sistem yang berguna diatur sebagai inti statis yang memulai banyak kode yang ditulis dalam bahasa yang dinamis (bahkan fungsional).

Dan menanamkan bahasa skrip dapat membuat sistem menjadi lebih mudah dikembangkan.

Tetapi bahasa scripting seharusnya tidak memiliki otoritas penuh VM.

Jika Anda memilih untuk mengizinkan bahasa skrip tertanam, buat yang mudah bagi invoker untuk membatasi apa yang dapat mereka lakukan. Model kemampuan-objek (lihat komentar di Newspeak di atas) sangat sesuai di sini; jadi ketika mengevaluasi kode dalam bahasa scripting, pemanggil harus meneruskan kode untuk mengeksekusi dan semua variabel global untuk kode itu.

Perlakukan evalsebagai bahasa yang menyematkan dirinya sebagai bahasa scripting

Jika bahasa Anda dapat memanggil kompilernya sendiri untuk mengubah string menjadi kode, maka izinkanlah untuk di-sandbox sama seperti Anda menggunakan bahasa skrip tertanam apa pun.

Gunakan model konkurensi sederhana

Kami petugas keamanan tidak suka harus khawatir tentang kondisi lomba ketika mencoba mencari tahu apakah properti keamanan dikelola.

Harap pertimbangkan alternatif untuk threading sebelum menetapkan utas sebagai opsi default yang hampir mustahil untuk diamankan.

Salah satu yang sederhana adalah event loop concurrency seperti yang ditemukan di E, Verilog, dan JavaScript.

Jangan mendorong mengutip kebingungan

Beberapa bahasa adalah bahasa lem, dan mereka akhirnya berurusan dengan string dalam banyak bahasa yang berbeda.

Sebagai contoh, JavaScript sering menyusun string HTML, CSS, XML, JSON, dan bahkan JavaScript. Sangat sulit bagi pemrogram untuk mengingat untuk menyandikan string teks biasa dengan benar ketika menggabungkan mereka untuk membuat string dalam bahasa lain, sehingga program JS, tidak mengejutkan, memiliki semua jenis masalah kebingungan mengutip: XSS adalah yang terburuk.

Jika Anda ingin memasukkan fitur komposisi string, cobalah untuk mengurangi beban keamanan programmer. DSL, makro higienis, dan bahasa templat yang disematkan dapat menjadi cara yang bagus untuk melakukan ini dengan memindahkan beban untuk melarikan diri dengan benar ke pengembang perpustakaan atau bahasa dan jauh dari pengembang akhir.


Kerusakan yang indah.
Qix

23

Beberapa bahasa terbaik dirancang oleh orang-orang yang ingin membuat bahasa untuk diri mereka sendiri.

Jadi saya pikir perancang bahasa harus kurang memperhatikan pengguna mereka. Anda tidak dapat menyenangkan semua orang, Anda juga tidak harus berusaha.


4
Itu mungkin benar sampai batas tertentu. Namun, jika Anda tidak pernah mendengarkan pengguna, Anda tidak akan pernah tahu rasa sakit yang Anda timbulkan saat mereka mencoba menggunakan otak anak Anda. Tanpa mendengar / merasakan sakit itu Anda tidak akan pernah datang dengan ide hebat berikutnya yang memecahkan masalah itu dan orang lain. Tidak ada manusia yang merupakan pulau. Rasa sakit bisa menjadi motivator yang bagus untuk inovasi.
Berin Loritsch

5
@Berin: Saya kira intinya adalah bahwa Anda seharusnya tidak pernah mendengarkan pengguna Anda, tetapi jangan dengarkan pengguna yang ingin menggunakan bahasa untuk sesuatu yang tidak dirancang untuk dilakukan. Jika Anda mendesain bahasa untuk memecahkan set atau masalah tertentu, maka Anda harus melayani pengguna yang juga perlu menyelesaikan masalah tersebut. Namun, Anda benar-benar mengatasi masalah ekstrem dan terkadang bahasa dapat menemukan ceruk di domain baru, jadi +1.
Jeremy Heiler

2
@ Jeremy, ya, itulah yang saya katakan, tapi saya pikir itu tidak biasa untuk bahasa bekerja dengan baik dalam domain yang tidak dirancang untuk itu.
dan_waterworth

@dan_waterworth: Bahasa sukses biasanya berfungsi, seringkali dengan baik, di domain yang tidak dirancang untuk mereka.
David Thornley

8
Alih-alih "jangan mendengarkan pengguna", saran ini lebih baik diucapkan sebagai "jangan dengarkan pengguna yang tidak Anda miliki".
chrisaycock

16

Hanya 5-10% waktu yang dihabiskan untuk menulis kode. Desainer bahasa harus memperhatikan kesulitan dalam membuat perangkat lunak berfungsi, yang berarti memperbaiki kesalahan dan bug.

Itu berarti harus dari debugger yang baik. Bukan alat dengan sintaksis misterius dan perintah kunci yang hanya sedikit lebih baik daripada banyak pernyataan cetak.


2
+1. Debugging adalah salah satu tempat di mana beberapa bahasa lebih baik daripada yang lain - dan beberapa IDE membuat semua perbedaan antara bahasa yang dapat digunakan dan yang menghalangi Anda.
Berin Loritsch

2
Saya akan menambahkan sedikit ke ini dan berkata, jika memungkinkan, jejak tumpukan berguna. Jika ada kesalahan (atau pengecualian tanpa tertangkap atau apa pun, tergantung pada bahasa Anda), saya ingin dapat melihat seluruh tumpukan panggilan yang sampai ke sana, bersama dengan nilai argumen yang digunakan. Tcl melakukan ini dengan sangat baik .. tetapi, agar adil, semuanya adalah string di Tcl, sehingga Anda dapat mencetak nilai dari segala sesuatu dengan relatif mudah.
RHSeeger

1
Bukan hanya debugging, tetapi membuatnya sulit untuk menulis bug. Saya sangat senang ketika Java memperkenalkan batas-batas pemeriksaan otomatis pada array ... tapi kami di sini, 15 tahun kemudian, masih membuat kesalahan dalam bahasa lain.
Alex Feinman

3
Bukankah lebih baik memiliki bahasa yang menemukan Bug pada waktu kompilasi? Misalnya ketika saya menggunakan Ada menghabiskan waktu jauh lebih sedikit di debugger maka ketika saya menggunakan C atau C ++.
Martin

12

Saya pikir mereka harus memperhatikan Python, yang melakukan lebih banyak hal dengan benar daripada bahasa lain yang saya temui (dan bahkan jika Anda tidak menyukai beberapa fitur). Itu tidak berarti bahwa mereka harus meniru Python, tetapi penting untuk mengetahui apa yang Python lakukan dengan benar, bahkan jika Anda tidak ingin membuat bahasa seperti Python sama sekali.

Adapun ide-ide filosofis yang relevan di sana, ini adalah yang paling penting dari Zen Python:

  • Eksplisit lebih baik daripada implisit.
  • Jumlah keterbacaan diperhitungkan.
  • Kasus khusus tidak cukup istimewa untuk melanggar aturan.
  • Meskipun kepraktisan mengalahkan kemurnian.
  • Harus ada satu - dan lebih disukai hanya satu - cara yang jelas untuk melakukannya.
  • Jika implementasinya sulit dijelaskan, itu ide yang buruk.
  • Namespaces adalah salah satu ide bagus - mari kita lakukan lebih dari itu!

Saya pikir bahasa yang mengikuti aturan-aturan ini tentu harus cukup OK, tapi saya hanya tahu satu yang melakukan ini, dan itu Python. Untuk semua kesamaan dengan misalnya Ruby dalam implementasi, Ruby kehilangan hal-hal seperti keterbacaan dan mengundang Anda untuk melakukan kode golf, yang menyenangkan, tetapi tidak berguna dalam pengaturan profesional.

Satu-satunya fitur teknis yang saya lewatkan dalam Python adalah pernyataan "sampai" (seperti saat, tetapi tidak menguji ekspresi pertama kali). Lalu ada banyak hal dalam pustaka standar Python dan bahasa lain yang dapat ditingkatkan, tapi itu tidak sepenuhnya bahasa , jadi itu pertanyaan yang berbeda. :-)


4
Saya menganggap dua hal lain yang lebih penting, terutama pada tingkat desain bahasa: "Kasing khusus tidak cukup istimewa untuk melanggar aturan." karena bahasa dengan seribu kasus khusus atau aturan misterius sulit digunakan, dalam hubungannya dengan "Meskipun kepraktisan mengalahkan kemurnian." karena kalau tidak, Anda akan terseret ke ranah tarpit turing.

15
Jika eksplisit lebih baik daripada implisit, mengapa Anda tidak diharuskan mendeklarasikan variabel? Ketika kesalahan ketik yang sederhana dapat menyebabkan kesalahan debug sulit, (sebagai lawan dari kesalahan yang ditangkap pada waktu kompilasi atau kesalahan runtime yang jelas dan mudah di-debug,) itu adalah serangan besar terhadap bahasa IMO.
Mason Wheeler

4
@Mason Wheeler: Satu-satunya alasan Anda harus mendeklarasikan variabel dalam bahasa lain adalah Anda harus menyatakan jenisnya. Python bersifat dinamis, jadi ketik deklarasi tidak diperlukan, dan oleh karena itu deklarasi tidak diperlukan. Saya tidak melihat bagaimana itu ada hubungannya dengan implisit / eksplisit. Jenis-jenis dalam Python eksplisit. Begitu juga variabelnya. Setelah sepuluh tahun, kesalahan ketik tidak pernah menyebabkan kesalahan debug yang sulit. Bahkan, mereka sepele untuk debug.
Lennart Regebro

8
+1 untuk daftar, -1 untuk fanboy-ness. Memperhatikan semua bahasa yang telah memperoleh kesuksesan yang signifikan, dan berusaha untuk menggabungkan, atau setidaknya menganalisis penerapan elemen-elemen itu tampaknya seperti pendekatan yang lebih pragmatis.
Steven Evers

3
@Lennart: Saya akan mengatakan bahwa bisa (tetapi tidak diperlukan, lihat aturan 4) untuk secara eksplisit menyatakan tipe fungsi adalah hal yang baik. Ini mirip dengan desain berdasarkan kontrak. Itulah poin yang ingin saya sampaikan.
Theo Belaire

11

Kemampuan untuk memodifikasi bahasa yang sesuai dengan kebutuhan Anda adalah hal yang besar bagi saya. Untuk Lisp itu dilakukan dengan macro, untuk Tcl dengan uplevel. Pada tingkat lebih rendah, Ruby menggunakan lambdas dan sejenisnya. Saya hanya ingin kemampuan untuk menambahkan struktur kontrol baru yang sesuai dengan masalah daripada mencetak masalah saya di sekitar struktur kontrol yang tersedia. Sebagai contoh sederhana, konstruksi "do .. hingga" yang ada dalam beberapa bahasa tetapi tidak yang lain adalah cara yang lebih bersih untuk menangani beberapa kasus daripada "sementara", dapat menambahkan struktur baru untuk memenuhi kasus lain sangat berguna.

Dalam pengertian yang lebih umum, ini adalah metaprogramming ... tapi saya kebanyakan menggunakannya untuk membangun struktur kontrol baru.


Menarik. Dukungan pemrograman meta yang baik bisa jadi sulit untuk dilakukan dengan benar, tetapi sangat kuat saat itu. Saya telah mendengar dari orang-orang yang menyukai Lisp bahwa implementasi Lisp adalah yang terbaik - tetapi mereka mengatakan itu tentang segala sesuatu di Lisp. Adakah contoh dari apa yang Anda pikirkan adalah pemrograman meta dilakukan dengan benar?
Berin Loritsch

"Metaprogramming done right" harus berada di tempat yang mudah dilakukan dengan benar (well, untuk aktivitas sederhana yang masuk akal) dan di mana hasil akhirnya terasa seperti bagian alami dari bahasa tersebut.
Donal Fellows

1
Bukan hanya modifikasi, tetapi modifikasi yang dapat diuraikan. Jika Anda telah memetakan sesuatu dalam bahasa tersebut, saya sebagai pembaca harus dapat dengan cepat mengetahuinya. Anotasi atau spidol ekstrinsik lainnya dapat membantu dalam hal ini.
Alex Feinman

Saya pikir Mata-Lua atau Template Haskell melakukan pekerjaan yang baik untuk menyediakan ini. (Tidak sebagus Skema makro, tetapi itulah yang Anda bayar untuk menggunakan lebih dari parens dalam bahasa)
Theo Belaire

10

Yang paling penting adalah bahasa Anda harus memiliki "gaya". Sebagai contoh, saya akan menyebut C bahasa pemrograman sistem berbasis pointer. Saya akan menyebut Erlang bahasa pemrograman fungsional yang sangat bersamaan. Beberapa bahasa lain (seperti C ++ dan bisa dibilang Jawa) adalah apa yang disebut Allan Kay sebagai bahasa "aglutinatif": Bahasa Frankenstein terdiri dari banyak fitur yang disatukan.

Berikutnya yang paling penting adalah bahwa perubahan bahasa itu sendiri harus menjadi pilihan terakhir. Bahkan yang paling jinak terdengar bisa menjadi kompleks ketika dikombinasikan dengan fitur-fitur lain dari bahasa tersebut. Saya akan mengatakan bahwa untuk menempatkan fitur baru dalam bahasa, Anda perlu:

  1. Buktikan bahwa itu benar-benar perlu.
  2. Buktikan bahwa itu tidak dapat dilakukan di perpustakaan.
  3. Buktikan bahwa itu termasuk dalam bahasa.

2
Dengan kata lain, bahasa harus memiliki satu prinsip desain yang menyeluruh, dan bahasa harus konsisten dengan prinsip itu. Komentar tentang evolusi bahasa diperlukan (saya telah melihat ini gagal beberapa kali).
Berin Loritsch

1
Mengingatkan saya pada kutipan C ++ favorit saya ... Sebuah gurita yang dibuat dengan memaku kaki ekstra ke seekor anjing.
ocodo

4
Buktikan bahwa itu tidak dapat dilakukan di perpustakaan . +1
Qix

2
Saya suka tidbit perpustakaan. Sungguh keren bagaimana bahasa seperti haskell tidak memiliki hal-hal alur kontrol bawaan seperti loop, pengecualian atau lanjutan. mereka hanya sangat mudah untuk didefinisikan dalam bahasa, menjaga sintaks tetap benar-benar bersih dan mempromosikan ekstensiabilitas dan kompabilitas daripada membuat banyak fitur bahasa yang pintar.
sara

10

Terima kasih atas pertanyaannya. Anda mendapat jawaban yang cukup bagus.

Bukan untuk mengacaukan mata Anda, tetapi saya melihat seorang programmer sebagai saluran informasi. Gagasan / konsep / persyaratan masuk di satu ujung, dan kode keluar di ujung lainnya.

Jika Anda mengambil satu set persyaratan (tidak peduli bagaimana mereka dinyatakan) dan set kode pada papan tulis besar, dan menggambar garis memetakan setiap persyaratan dengan kode yang mengimplementasikannya, kompleksitas grafik itu akan tergantung pada seberapa baik kode mengungkapkan persyaratan. Idealnya, itu harus sangat langsung dan satu-ke-satu, tetapi itu sulit untuk dipraktikkan.

Saya mengukur kekhususan domain dari suatu bahasa sebagai sejauh mana ia menyederhanakan grafik itu. Itu adalah properti yang sangat diinginkan, dan dapat didekati dengan berbagai cara, dengan apa saja dari hanya mendefinisikan kelas / rutin yang tepat (kata benda / kata kerja), ke makro, hingga menulis parser dan juru bahasa / kompiler Anda sendiri.

Biarkan saya memberi contoh apa yang saya maksud. Untuk masalah membuat antarmuka pengguna dialog fleksibel, teknik ini menghilangkan keharusan untuk menulis event-handler, pemindahan data, sebagian besar hal yang biasanya dilakukan di UI. Ini juga menghasilkan pengurangan kode sumber sekitar urutan besarnya. Bahasa meta sebenarnya hanya beberapa rutin dan makro di C / C ++ / Lisp, dan saya juga melakukannya dalam bahasa tanpa makro.

Jika menerapkan persyaratan dapat dilakukan dengan 5 poin suntingan ke kode, atau dengan 10, melakukannya dengan 5 bukan hanya kode yang lebih sedikit, tetapi lebih sedikit peluang untuk kehilangan langkah dan memasukkan bug. Jadi, semakin spesifik bahasa domain, semakin kecil kode, lebih mudah dirawat, dan lebih bebas bug. Saya pikir kita perlu tahu cara mengemudi ke arah itu. Itu tidak berarti kode lebih mudah dibaca, kecuali jika pembaca telah berinvestasi dalam kurva belajar untuk memahami teknik.


9

Tipe Integers yang terikat dan berbeda seperti di Pascal dan Ada. Jujur: seberapa sering Anda membutuhkan jangkauan penuh bilangan bulat apa pun? Saya pikir ada banyak yang harus ditingkatkan dalam tipe primitif untuk lebih mewakili dunia nyata.


2
Tipe integer terikat ala C, C ++, D, Java, C #, dll pasti ada tempatnya. Beberapa jenis pemrograman tidak peduli dan hanya perlu membedakan integer vs floating point. Meski begitu, mungkin kita hanya perlu tipe nomor dan khawatir tentang bagian integral dari nomor nanti? Singkatnya, pemrograman bisnis kurang sensitif terhadap tipe integer spesifik daripada fakta bahwa angka adalah integer. Saat Anda menerapkan protokol pada level rendah, aturan berubah secara drastis.
Berin Loritsch

2
Apa yang saya pikirkan di mana ketik di Ada di mana Anda bisa mengatakan type Date_Of_Month is 1 .. 31;dan meninggalkan keputusan seperti 16 atau 32 bit ke pengoptimal. Tetapi yang lebih penting, menugaskan 32 atau 0 atau -5 ke variabel jenis memberi Anda RANGE_ERROR.
Martin

Kisaran bekerja dengan baik untuk hal-hal seperti Date_Of_Month(atau Month_Of_Year) di mana ada rentang yang jelas untuk digunakan, tetapi banyak - mungkin sebagian besar - kasus fuzzy. type Persons_Age is 0..120? Bagaimana jika seseorang memecahkan rekor umur panjang? type Year is 0..9999? Bagaimana jika Anda seorang Egyptologist?
dan04

Jika Anda seorang ahli sejarah Mesir, Anda tidak menyadari kebutuhan Anda type Egyptian_Year is -9999 .. 300;. Dalam pengalaman saya, Anda dapat menemukan batas yang berguna untuk bilangan bulat sebagian besar waktu. Dalam hal ini Anda harus mempertimbangkan type Scrolls_Found is array Egyptian_Year of Natural;Anda tidak dapat / seharusnya tidak memiliki jenis yang tidak terikat sebagai indeks array. Itu hanya vektor serangan untuk peretas. BTW: Ada memungkinkan untuk batas jangkauan dihitung pada waktu berjalan.
Martin

1
@ Kai tidak ada yang mengatakan bahwa fitur khusus dari sistem tipe ini harus digunakan di mana-mana tanpa kecuali. Saya yakin Ada juga memungkinkan seseorang untuk menggunakan tipe numerik "biasa". Dan tipe numerik terbatas tentu berguna untuk beberapa masalah (agak umum).
Sarge Borsch

8

Ada fitur yang membuat bahasa pemrograman mudah digunakan setelah Anda mempelajarinya, dan ada fitur yang membuatnya mudah dipelajari untuk digunakan. Karena pengguna bahasa idealnya memiliki hubungan jangka panjang dengannya, mengoptimalkan untuk kemudahan penggunaan lebih baik daripada mengoptimalkan untuk kemudahan belajar. Jangan membuat hal-hal lebih sulit daripada yang diperlukan, tetapi jangan mengorbankan ekspresif (bisa menulis sedikit kode yang banyak melakukan) untuk keterbacaan bagi mereka yang tidak terbiasa dengan bahasa. Di sisi lain, bahasa tersebut seharusnya tidak dibaca seperti derau baris untuk orang-orang yang telah bekerja dengannya selama bertahun-tahun; itu tidak mudah digunakan atau dipelajari.


8

Konvensi Penamaan (Saya melihat Anda PHP)


Kurang dari masalah desain bahasa. Tentu, Anda selalu harus mengawasi apa yang masuk ke perpustakaan standar, tetapi perancang bahasa tidak dapat menegakkan konvensi penamaan;)

3
Anda bisa untuk perpustakaan standar.
Malfist

3
Bahkan tidak menyebutkan PHP. Bahasa yang umum digunakan terburuk di sekitar. Tidak dirancang oleh ilmuwan komputer, hanya seorang pria yang menginginkan template, dan steroid ditambahkan.
Keyo

@delnan: beberapa bahasa, seperti Mercury atau Eiffel, memaksakan konvensi penamaan (semua nama kelas kapital, variabel dimulai dengan huruf kapital, dll.) dan mereka diberlakukan oleh kompiler. Fortran mengatakan bahwa variabel yang dimulai dengan i, j, k adalah integer (maka penggunaan tradisional sebagai variabel loop dalam kebanyakan bahasa ...). Dan seterusnya. Entah bagaimana menjengkelkan jika Anda tidak suka konvensi, tetapi setidaknya baik untuk konsistensi kode sumber.
PhiLho

@ Philho: Itu sangat terbatas. Itu tidak dapat memaksakan - hanya satu contoh - penggunaan kapitalisasi atau garis bawah yang konsisten, bermakna (bagi pembaca manusia) (itu bisa mencoba tetapi akan mengambil risiko kewarasan programmer dalam proses ini).

7

Integrasi kelas satu dengan lingkungan pengembangan.

Saat ini, pengkodean dilakukan dalam lingkungan yang kaya. Untuk HTML / CSS / JS, kami memiliki Firebug dan alat interaktif lainnya. Untuk Java, Eclipse dan IDEA dan IDE sejati lainnya. Dan seterusnya. Ada ekologi alat, dimulai dengan editor tetapi tidak berakhir di sana:

  • Organisasi kode di dalam dan antar file
  • Penyorotan cerdas
  • Pengisian cerdas / prediksi prediktif
  • Debugging statis (kesalahan flagging sintaksis, semantik, dan gaya)
  • Pembuatan dan penggunaan template dan makro
  • Kontrol versi (versi, penggabungan, percabangan, ...)
  • Pengembangan terdistribusi dengan banyak penulis (komentar, dokumen sebaris, anotasi, ...)
  • Run-time debugging (tumpukan jejak, loncatan, jam tangan, ...)
  • Debugging "live" interaktif (seperti Firebug - perilaku pengeditan sistem live)
  • ... Aku bahkan tidak tahu apa selanjutnya.

Bahasa harus dibangun untuk memberikan dukungan untuk kegiatan ini. Beberapa kemajuan telah dibuat - anotasi di Jawa untuk membantu pengembang lain memahami maksud kode, misalnya.

Tetapi kebanyakan itu diretas, seperti menggunakan $ Id $ dalam komentar sehingga sumber yang dikendalikan CVS dapat berisi nomor versi. Mengapa saya tidak bisa melakukan hal seperti ini dari bahasa itu sendiri?


Maksud Anda seperti ASIS (ISO / IEC 15291: 1999 "Ada Semantics Interface Specification")? ASIS tidak mencakup semua yang Anda inginkan tetapi cukup banyak. Saya sering berharap untuk sesuatu seperti ASIS untuk bahasa pemrograman lain. Lihat sigada.org/wg/asiswg untuk detailnya.
Martin

Beberapa dari hal-hal ini relatif murah untuk dilakukan, atau datang secara gratis dari IDE Anda: organisasi kode, penyorotan sintaksis, pelipatan kode, kontrol versi, template / makro. Yang lain membutuhkan lebih banyak usaha: debugging runtime, debugging statis, Smart typing / predictive typing, refactoring, dll. Meskipun sering diabaikan, merancang bahasa yang konsisten jauh lebih sulit ketika Anda juga harus khawatir tentang plugin IDE.
Berin Loritsch

6

Komputasi Terdistribusi

Makan siang gratis berakhir. Hari ini kita membutuhkan program yang berjalan pada banyak core / banyak prosesor (dan pada keadaan khusus banyak komputer).

Sayangnya menulis kode multi-thread sulit secara konseptual, sehingga benar-benar tidak perlu menambahkan bahasa sebagai penghalang.

Penggunaan C ++ 0x di masa depan tentu saja menarik, untuk semua yang ia bawa sebagai pustaka dan tidak membebaskan Anda dari masalah sinkronisasi yang sebenarnya (Anda tahu, hal-hal yang sangat mudah dipecahkan ...)

Saya sangat suka pendekatan Go untuk masalah: multithreading adalah built-in, dan pendekatan yang diambil (saluran dan goroutine) menetapkan pola pikir yang jauh lebih mudah daripada pendekatan semaphore / mutex / lock tradisional. Masih mudah untuk mengakses struktur yang tidak disinkronkan secara bersamaan (Go memiliki pointer) atau ke jalan buntu (siklus tunggu di saluran ...)

Saya pikir bahasa yang mendukung data yang tidak dapat diubah, seperti bahasa fungsional, mungkin memiliki hak atasnya (saya suka pengalaman di sana).

Juga, model Aktor mungkin menjadi target kami berikutnya. Itu dimaksudkan untuk komputasi terdistribusi juga.


Contoh lain adalah Erlang. Tema umum di antara bahasa-bahasa semacam ini adalah pendekatan apa-apa yang dibagikan , di mana negara pada dasarnya diteruskan bersama dengan pesannya. Pendekatan ini berskala dengan baik.
Berin Loritsch

@Berin: Anda benar, meskipun saya tidak mengutip pesan Erlang karena saya tahu sedikit tentangnya, saya ingat benar itu mengimplementasikan model Aktor.
Matthieu M.

6

Sebut saya gila, tetapi salah satu fitur bahasa yang paling penting bagi saya adalah ketersediaan referensi online yang bagus, bersama dengan contoh-contohnya. Saya tahu bahwa saya dapat menemukan hasil pencarian yang bagus untuk bahasa apa pun, tapi saya sangat suka situs MSDN dan Java API. Mereka membuat pemrograman lebih mudah bagi seseorang yang tidak memiliki banyak pengalaman dalam bahasa tertentu.


JavaDoc, CppDoc, RubyDoc, dll. Telah menjadi aset yang bagus dalam memahami pustaka standar, serta pustaka yang Anda buat. Mereka tidak semua diciptakan sama dan beberapa lebih mudah dinavigasi daripada yang lain.
Berin Loritsch

Setuju, Situs Java API adalah aset yang sangat baik. Sangat bagus memiliki format standar untuk membuat dokumentasi API juga. Keuntungan produktivitas dari menggunakan IDE dengan dukungan bawaan untuk menganalisis JavaDoc (netbeans) sungguh menakjubkan. Meskipun saya memiliki ingatan yang mengerikan sehingga mungkin bermanfaat bagi saya lebih dari yang lain.
toc777

6

Lebih banyak kemampuan untuk membantu kompiler memeriksa kode Anda.

Menjadi seorang programmer sistem tertanam, saya selalu menggunakan C. Tapi saya selalu berharap saya punya lebih banyak / lebih baik cara untuk memberitahu kompiler apa yang saya harapkan dari kode saya sehingga dapat memverifikasinya.

EG saya bisa punya fungsi

f(int x)

tapi saya lebih suka

f(int range[-5..25] x)

EG Saya ingin dapat menulis pernyataan tentang fungsi menggunakan semacam bahasa fungsional tingkat tinggi seperti Lisp atau Haskell. Ini tidak akan dikompilasi menjadi kode, tetapi dapat digunakan untuk analisis statis atau dinamis.


Pada dasarnya cara yang efisien untuk melakukan pemeriksaan batas? Itu akan sangat keren. Meskipun, saya setidaknya ingin itu dimasukkan untuk pengecekan runtime dan juga kompilasi waktu pengecekan. Saat Anda menarik informasi dari database, atau dari antarmuka pengguna, Anda selalu menjamin nilainya akan valid. Jika ini adalah fitur bahasa saya ingin menggunakannya untuk keperluan ini juga.
Berin Loritsch

3
Anda harus menggunakan Pascal. Anda dapat menentukan tipe yang mencakup rentang angka yang berubah-ubah, seperti -5..25, yang dapat diverifikasi oleh kompilator pada waktu kompilasi. (Selama Anda hanya menetapkan konstanta, tentu saja.)
Mason Wheeler

1
@ Kugel: Apa lagi selain fitur kompiler yang ditegaskan? Dan Unit test tidak akan memeriksa kode dalam produksi. Dan tidak memeriksa produksi sama seperti melepas kapal hidup setelah pelayaran perdananya. Untuk menghemat bahan bakar dan membuat kapal lebih cepat.
Martin

1
Saya akan menggunakan Ada, kecuali bahwa platform yang saya kerjakan tidak memiliki kompiler Ada. Itu hanya memiliki kompiler C, jadi ini semua tetap akademik.
Rocketmagnet

1
Saya sudah menggunakan banyak penegasan, tetapi akan lebih baik jika memiliki ini dan yang lainnya sebagai fitur bahasa.
Rocketmagnet

5

Sintaks kecil dengan sesedikit mungkin kata kunci karena sintaksis verbose sulit dipelajari dan tidak membantu keterbacaan.

Contoh terburuk adalah Ada:

procedure Hello is
begin
  Put_Line("Hello World!");
end Hello;

Kata-kata pengisi seperti adalah, seperti, .. tidak masuk akal untuk bahasa pemrograman.


4
Saya pikir contoh terburuk adalah bahasa di mana Anda mengatakan public static void.
Joey Adams

1
Ide ini tidak baru dan sudah diterapkan dalam bentuk SmallTalk yang tidak memiliki kata kunci sama sekali. Jadi, Anda harus menggunakan SmallTalk sebagai contoh positif untuk klaim Anda. BTW: Jika Anda tidak tahu untuk apa ISini maka Anda belum memahami Ada (apakah Anda pernah memprogram Ada?): ISMemisahkan deklarasi prosedur dari deklarasi variabel lokal dan juga membedakan spesifikasi dari implementasi. Tentu saja Anda hanya akan melihat ketika membandingkan spesifikasi dan implementasi fungsi untuk melihat bahwa itu ISmasuk akal dan bukan pengisi sama sekali.
Martin

1
Lupa menyebutkan: Sintaks SmallTalk juga sesuai dengan bagian belakang kartu pos. Jadi itu juga akan memenuhi keinginan Anda untuk "kecil". Tentu saja sebagian besar ide di sini sudah diimplementasikan dalam beberapa bahasa di suatu tempat dan sebagian besar poster di sini menggunakan bahasa itu sebagai contoh positif alih-alih membuat contoh negatif yang salah . Saya akan memilih Anda jika saya cukup reputasi. Bukan karena ide Anda buruk - tetapi karena menggunakan contoh negatif.
Martin

7
Kata-kata pengisi sebenarnya dapat melayani tujuan jika mereka membantu untuk mengacaukan sintaks. Sebagai contoh, saya lebih memilih if x then …untuk if (x) …. Kami telah memperdagangkan sepasang tanda kurung untuk kata kunci kontekstual. Ini masuk akal karena kondisinya xmungkin ekspresi kompleks dengan tanda kurung sendiri. Menghilangkan pasangan terluar secara drastis dapat meningkatkan keterbacaan. Alternatif tentu saja adalah menggunakan titik dua di sini, seperti di Python. Bahkan, saya percaya sebagian besar pengisi yang ambigu seperti itu bisa diganti dengan titik dua. Tidak yakin metode mana yang saya sukai.
Konrad Rudolph

3
@ Konrad: Jika itu melemahkan sintaks, itu bukan pengisi. Ini is adalah pengisi karena Ada bisa membiarkan procedure Hello begin ... endtanpa ambiguitas.
dan04

4

Saya ingin melihat lebih banyak bahasa pembelajaran . Tidak hanya bahasa untuk pemula absolut dengan batasan yang lebih suci daripada Anda, seperti membutuhkan ruang di antara setiap token , tetapi bahasa untuk orang yang sudah mengetahui pemrograman dan ingin mempelajari konsep baru atau menjadi lebih baik dalam pemrograman pada umumnya.

Bagi saya, Haskell adalah contoh yang bagus tentang apa yang saya maksudkan dengan "bahasa pembelajaran" (meskipun bahasa ini juga tumbuh dalam popularitas dan utilitas umum selama bertahun-tahun). Dengan mengabaikan sintaks C yang sudah dikenal dan memiliki operator komposisi fungsi mundur (mis. (+2) . (*3)Adalah fungsi yang dikalikan 3, kemudian menambahkan 2), Haskell mengajari saya untuk menulis fungsi yang lebih pendek. Pemeriksa tipe yang kejam membantu saya mempelajari bahasa lebih cepat dan meningkatkan kemampuan saya untuk berpikir secara logis tentang kode. Kedua manfaat ini telah menyebar ke bahasa lain, bahkan bahasa.

Tujuan pembelajaran bahasa dan tujuan bahasa umum sering bertentangan. Bahasa pembelajaran harus menantang dan bermanfaat untuk dipelajari, dan harus menegakkan gaya tertentu, bahkan jika gaya itu bukan yang terbaik untuk banyak aplikasi. Bahasa tujuan umum harus baik untuk menyelesaikan pekerjaan, dan penggunaan abstraksi harus diukur dengan cermat dan "masuk akal". Misalnya, ketika memperbaiki situs web, mempelajari tentang monad akan menjadi hal terakhir yang ada di pikiran seorang programmer. Di sisi lain dari koin, ketika seseorang belajar untuk memprogram, mereka tidak harus mengarungi omong kosong "public static void" jika mereka bahkan belum belajar tentang fungsi.

Jika Anda seorang perancang bahasa, putuskan apakah bahasa Anda adalah bahasa pembelajaran atau bahasa terapan. Ini akan menentukan sejauh mana Anda ingin menggunakan kemurnian dalam desain Anda.


2
Bagaimana komposisi fungsi Haskell mundur? Ini adalah terjemahan langsung dari (f ∘ g)(x) = f(g(x)).
Jon Purdy

@ Jon Purdy: Ini berarti Anda harus menulis fungsi dalam urutan terbalik dari aplikasi mereka. Dalam kedua bentuk, gditerapkan argumen pertama, diikuti oleh f. Jika Anda ingin mengurutkan daftar, mengelompokkannya, dan mendapatkan item pertama dari daftar itu, Anda akan menulis (map head . group . sort) listatau map head $ group $ sort listatau map head (group (sort list)). Dalam semua kasus, Anda akhirnya menulis operasi mundur. Ngomong-ngomong, pengimporan Control.Arrowmemungkinkan Anda mengatakannya (sort >>> group >>> map head) list, tetapi >>>operatornya terlihat agak canggung dan kasar kepada saya.
Joey Adams

2
Saya tidak tahu, saya masih berpikir yang kanan-ke-kiri masuk akal. (map head . group . sort) listdibaca sebagai "item pertama dari masing-masing kelompok dalam semacam list", yang cukup alami — dan, menurut saya, lebih fungsional daripada (sort >>> group >>> map head) list, yang berbunyi agak imperatif dan terbelakang ketika “mengurutkan kemudian kelompok kemudian mengambil item pertama dari masing-masing kelompok. .. list"
Jon Purdy

@JoeyAdams - yang >>>Operator terlihat agak canggung dan verbose - Beberapa bahasa fungsional yang lebih baru telah mulai menggunakan |>sebagai operator chaining kiri ke kanan, yang mungkin sedikit lebih mudah pada mata ...
Jules

4

Sejak kita di 2011,

  • spesifikasi yang sangat lengkap. tidak ada lubang yang bergantung pada arsitektur seperti di C
  • dukungan multithreading; bukan hanya fitur sinkronisasi (kunci), tetapi fitur bahasa yang membuat multithreading semudah menulis loop:

    semua (o di myCollection) {o.someMethod ()}

  • multi-paradigma; biarkan saya, sang programmer, memutuskan apakah saya ingin keamanan waktu kompilasi dari bahasa statis atau kesederhanaan dari bahasa yang dinamis, berdasarkan kasus per kasus; beri saya fitur berorientasi objek, fitur fungsional, dll.

  • konsistensi (Saya tahu ini meminta sedikit banyak untuk konsistensi dan multi-paradigma ...)


Saya bersama Anda 100% untuk spesifikasi lengkap. Multi-paradigma dan konsistensi pasti akan menjadi tindakan penyeimbang. Anda dapat menentukan seperangkat perilaku untuk paradigma dinamis sebagai bagian dari perilaku untuk pemeriksaan statis - tetapi saya pikir dua pendekatan ini dapat memberikan gaya pemrograman yang sangat berbeda. Mereka benar-benar harus menjadi bahasa yang terpisah pada saat itu. Mungkin sepasang bahasa yang konsisten dengan kompatibilitas 100% akan menjadi apa yang Anda cari?
Berin Loritsch

Bahasa seperti Scala (dan mungkin Haskell? Saya tidak cukup tahu) memiliki sistem tipe statis yang kuat dan terseness, berkat inferensi tipe dan implisit.
PhiLho

2
Fitur yang bergantung pada arsitektur baik-baik saja ketika suatu bahasa memungkinkan seorang programmer menentukan apa yang penting atau tidak penting. Apa yang membuat C mengerikan adalah bahwa tidak ada cara untuk menyatakan "tipe numerik yang membungkus modulo 65536"; bahkan jika suatu platform mengimplementasikan uint16_t, standar mensyaratkan bahwa beberapa implementasi menganggap perbedaan antara dua uint16_tnilai ditandatangani, dan yang lain menganggap perbedaan sebagai tidak ditandatangani; itu tidak memberikan jalan bagi programmer untuk menentukan perilaku mana yang diinginkan.
supercat

Saya tidak setuju untuk multiparadigma; yang menyisakan terlalu banyak ruang gerak untuk mengkodekan pertarungan gaya. Perpustakaan A ditulis dengan banyak paradigma dinamis . Perpustakaan B ditulis dengan banyak paradigma statis . Nah, sekarang Perpustakaan A perlu berbicara dengan Perpustakaan B; di mana jalan tengahnya? Jika Anda harus menulis lem di antara dua bagian kode dalam bahasa yang sama, bahasa tersebut secara inheren cacat IMO.
Qix

3

Proses Ringan

Saya ingin memiliki Proses Ringan seperti di Erlang. Ini terutama masalah untuk runtime. Ini tidak ada di JVM dan .NET CLR. LWP membantu untuk membuat perangkat lunak bersamaan secara besar-besaran. Idealnya seharusnya tidak ada yang lebih mahal untuk membuat proses karena untuk membuat objek dalam bahasa. Saya ingin membuat jutaan proses dalam aplikasi saya.

Ini diimplementasikan sebagai thread-pool dengan penjadwalan preemtive, sehingga satu tugas tidak memblokir tugas lainnya, dan tugas-tugas tersebut dapat dijadwalkan pada cpu-core yang tersedia.

Dukungan untuk rekursi ekor

Saya ingin mendapat dukungan untuk rekursi ekor. Ini juga bisa menjadi masalah untuk lingkungan runtime. Misalnya JVM tidak memiliki dukungan untuk rekursi ekor.

Pemrograman yang mudah didistribusikan

Saya ingin mendapat dukungan untuk kirim ( ! ) Dan menerima primitif ke bagian aplikasi yang berjalan di komputer lain di netword yang sama seperti di Erlang. Ini membuatnya mudah untuk membangun aplikasi yang skalabel misalnya datastore terdistribusi. Ditambah dengan itu serialisasi built-in dalam bahasa ini juga sangat membantu seperti di erlang. Dan tidak seperti di Jawa saya harus melakukannya secara manual.



Scala memiliki rekursi ekor dan dikompilasi ke JVM. Kompiler IBM Java juga dapat melakukan rekursi ekor - terkadang.
Martin

3

Memfasilitasi metaprogramming.

batasi formulir khusus

Dalam Python tidak ada alasan mengapa mencetaknya bukan fungsi bawaan. Itu terlihat dan bertindak seperti fungsi kecuali untuk tidak ingin ada hubungannya dengan orangtua.

Apakah kita benar-benar membutuhkan for, foreach, whiledan sejenisnya setiap sebagai bentuk khusus mereka sendiri. Bagaimana dengan satu konstruksi looping dan beberapa makro default untuk memberikan gula sintaksis dari bentuk varian looping.

meta-programming untuk bentuk khusus

form['if'](test-fn, body-fn)


Ruby semacam memiliki "bentuk khusus" untuk perulangan, setidaknya dalam arti bahwa objek iterable biasanya memiliki metode seperti eachitu mengambil blok kode sebagai argumen. (Ruby juga memiliki fordan whilemengulang, tetapi tidak ada programmer Ruby yang menghargai diri sendiri yang benar-benar menggunakannya.)
mipadi

@mipadi: Saya penggemar berat balok-balok Ruby dan idiom-idiom terkait.
dietbuddha

mungkin mereka berpikir - Anda akan menembak keluar. :) Dugaan saya, itu adalah gabungan dari semua "Python" yang kuat dan "tidak ada alasan bagus mengapa". Namun demikian, metaprogramming adalah masalah desain bahasa yang valid yang sering diabaikan. Karena alasan itulah saya akan membenarkan ini.
Berin Loritsch

@Berin: Saya benar-benar menggunakan, dan saya penggemar Python yang membuatnya lebih lucu.
dietbuddha

Satu jenis loop akan membuat aliran kode tidak jelas. Misalnya, bagaimana do..whileloop akan terlihat jika ada satu jenis loop yang memiliki evaluasi di atas? Itu tidak akan terlihat seperti do..while loop sama sekali.
Qix

2

Kemampuan jaringan

Bahasa yang dikirimkan tanpa dukungan jaringan cukup lemah di dunia saat ini.

Sebagian besar aplikasi dunia nyata perlu berkomunikasi melalui beberapa jenis jaringan:

  • pembaruan otomatis
  • akses basis data
  • Layanan web

Ini juga merupakan landasan dukungan komputasi terdistribusi / cloud tentunya.


8
Tapi itu bisa menjadi fitur perpustakaan standar dengan baik.
Donal Fellows

@ Donal: Saya tidak pernah mengatakan sebaliknya (atau setidaknya tidak berpikir begitu), pertanyaannya terbuka untuk fitur bahasa dan perpustakaan. Maksud saya adalah bahwa jika Anda menerima paket bahasa dan tidak ada kemampuan jaringan di sana, Anda akan mengisi rasa sakit lebih cepat daripada nanti :)
Matthieu M.

3
Perpustakaan standar benar-benar merupakan bagian dari pengalaman bahasa, dan harus diperlakukan dengan perhatian dan rasa hormat yang sama. Saya juga setuju dengan persyaratan ini untuk perpustakaan standar.
Berin Loritsch

1

Saya suka bahasa pemrograman yang mudah dipelajari, dan mudah digabungkan untuk menciptakan hal-hal baru.

Misalnya, walaupun menarik untuk memiliki banyak cara untuk menulis sesuatu, saya pikir lebih baik hanya memiliki satu atau dua cara untuk menulisnya. Dengan begitu program lebih mudah dipertahankan.

Bahasa yang konsepnya dapat diterapkan di semua elemen sangat membantu (saya pikir ini disebut ortogonalitas) Jadi, lain kali Anda menghadapi fitur bahasa baru, Anda dapat menyimpulkan bagaimana menggunakannya.

Saya mengerti kadang-kadang sintaks bahasa harus menghalangi untuk melakukan lebih baik dalam fase kompilasi / interpretasi, tapi kadang-kadang saya merasa perancang bahasa menunda pekerjaan ini kepada pengembang. Misalnya, string multiline dalam Java atau Javascript.

Akhirnya, sintaks bahasa adalah antarmuka penggunanya, dan dengan demikian, itu harus jelas, ringkas, intuitif, mudah digunakan, dan harus menghormati kebiasaan Anda.


Orthogonal berarti setiap fitur melakukan sesuatu yang berbeda. Lihatlah alat-alat seperti grep atau awk. Mereka melakukan satu hal, yah. Anda kemudian menghubungkan mereka dalam pesanan berbeda untuk melakukan apa pun yang Anda butuhkan.
Theo Belaire

1
  • Keterbacaan : Semakin sedikit / terkecil simbol yang digunakan dalam tata bahasa, semakin bersih & semakin baik.
  • Jenis Berorientasi Objek : Metode, bukan fungsi.
  • Dapat dimengerti : Built-in interface lancar, nama lengkap dan pendek untuk kelas perpustakaan / interface dan semacamnya.

1
Maaf, tapi saya harus memberi Anda -1 karena benar-benar salah dalam hal ini. Terseness membantu untuk menulis kode lebih cepat, tetapi yang paling pasti tidak membuat kode lebih mudah dibaca, melampaui batas minimum tertentu. Tingkat verbositas tertentu membuat kode lebih mudah dibaca, karena kata-kata dan simbol tambahan itu berarti sesuatu dan memberikan informasi yang bermakna kepada programmer, terutama jika itu awalnya ditulis oleh orang lain dan Anda tidak memiliki keuntungan karena sudah memiliki mental model itu di kepala Anda.
Mason Wheeler

Bagi saya, kode bersih adalah kode yang dapat dibaca. Saya juga mengatakan yang terkecil: memiliki ":" alih-alih "=>" dalam array PHP, atau memiliki "." bukannya "->", tentu akan menjadi peningkatan (dan saya sudah menikmati PHP).
dukeofgaming

4
@Mason: Saya, dan banyak penulis teknis yang baik (misalnya William Zinsser), tidak setuju. Verbositas adalah musuh keterbacaan, bukan kesederhanaan.
Konrad Rudolph

2
Saya mencari bentuk kesempitan yang didefinisikan dalam istilah simbol . Saya cukup senang dengan simbol multi-karakter, selama itu adalah hal-hal yang pembaca alami memperlakukan sebagai simbol tunggal (misalnya, kata adalah simbol).
Donal Fellows

1
Poin pertama Anda secara langsung bertentangan dengan dua yang terakhir.
Qix

1

Menambahkan fitur ke bahasa pemrograman yang ada. Jadi, bahasa baru B adalah bahasa lama A plus fitur X.

Contoh yang ada:

  1. C menambahkan kelas => C ++
  2. Java menambahkan beberapa hal => C #

2
Ini adalah penyederhanaan yang sangat besar. Contoh yang jauh lebih baik adalah perbedaan antara C dan Objective-C.
Jon Purdy

0

Ketika datang ke teknologi / platform / bahasa / database dll. Sebagian besar waktu turun ke kinerja. Di masa depan banyak perangkat lunak saat ini dapat dirancang menggunakan bahasa grafis karena kita memiliki kemampuan komputasi yang lebih kuat.

Saya berharap untuk hari ketika kita memiliki kekuatan komputasi dan bahasa di mana Anda merancang aplikasi Anda dan Anda tidak perlu khawatir tentang detail bahasa .

Pembaruan: Saya mengirim tautan ke bahasa LabView seperti itu

Pembaruan: Saya harus menjelaskan lebih lanjut apa yang saya maksud dengan "kekuatan komputasi". Kinerja perangkat lunak yang dikompilasi mungkin tidak sekuat perangkat lunak yang dikompilasi berdasarkan bahasa sintaksis. Saya berpikir pemrograman grafis sebagai level pemrograman yang lebih tinggi dan mungkin ada lebih banyak overhead. Komputer saat ini dapat dan dengan mudah menjalankan bahasa pemrograman grafis.


3
Komputer sudah cukup kuat untuk melakukan ini. Ini tidak praktis, karena Anda harus masuk ke dalam kode karena suatu alasan .
Jeremy Heiler

2
Itu masih semacam bahasa. Sudah ada lebih dari satu upaya untuk mewujudkan hal ini. Alat-alat UML akan menghasilkan sejumlah kode, tetapi ketika model tersebut cukup rinci untuk menghasilkan produk yang berfungsi, tidak lagi bisa digunakan untuk memahami kode. Saya percaya bahwa ada sesuatu di lingkungan Unix untuk pemasangan kabel aplikasi secara grafis, tetapi membutuhkan banyak konfigurasi untuk memperbaikinya. Mesin alur kerja menggunakan metafora ini untuk memungkinkan non-programmer untuk merancang alur kerja.
Berin Loritsch

1
Singkatnya, sementara saya sangat meragukan kegunaan dari pendekatan ini secara umum, ada beberapa aplikasi spesifik yang saat ini digunakan dan berfungsi dengan baik untuk aplikasi itu. Re: poin Anda ... 1. Komputer memiliki kekuatan komputasi, sisi teknis bukanlah masalahnya. 2. Masalahnya adalah menyediakan bahasa visual yang cukup ekspresif untuk melakukan pekerjaan dalam pengertian umum tanpa tersesat dalam detail. Di luar aplikasi niche, teks tampaknya menjadi representasi yang jauh lebih kompak dari suatu program. Saya melakukan upvote karena ini berlaku untuk pertanyaan yang diajukan.
Berin Loritsch

1
@ Ammir: Lalu tolong jelaskan mengapa komputer harus lebih kuat agar "pemrograman grafis" untuk mendorong pengembangan perangkat lunak?
Jeremy Heiler

7
@ Amir: Anda mengacaukan batasan teknis dengan yang lebih mendasar. Alasan kami tidak memiliki banyak bahasa komputer grafis adalah karena kami tidak tahu bagaimana melakukannya dengan baik (dan tidak tahu apakah mereka dapat melakukannya dengan baik). Saya mengetahui LabView, dan telah mendengar cukup banyak mengeluh tentang melakukan hal-hal rumit di dalamnya, atau mengubah hal-hal sederhana. Kita juga tidak perlu komputer yang lebih kuat untuk merancang bahasa seperti itu, jadi silakan dan coba membuat sketsa beberapa program sampel dalam bahasa hipotetis seperti itu.
David Thornley
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.