Jika Anda merancang bahasa pemrograman, bagaimana Anda melakukannya? Fitur apa yang akan Anda masukkan? Apa yang akan Anda tinggalkan? Diketik secara statis atau dinamis? Diketik dengan kuat atau lemah? Dikompilasi atau ditafsirkan? Benarkan jawaban Anda.

• Saya pasti berpikir bahwa bahasa pemrograman fungsional akan menangkap, jadi bahasa saya akan fungsional. Lihat Menjinakkan Efek dengan Pemrograman Fungsional

• Saya pikir CPU akan segera memiliki hundread core, dan utas akan menjadi neraka untuk dikelola. Jadi Model Aktor adalah suatu keharusan, bukan utas. Lihat Erlang - perangkat lunak untuk dunia bersamaan

• Saya juga berpikir bahwa OOP telah gagal, komunikasi antara objek dianggap asinkron . Jadi saya pikir kita perlu menyampaikan pesan , dengan pesan abadi. Kirim dan Lupakan. Seperti dalam model Aktor. Lihat Pemrograman Berorientasi Objek: The Wrong Path?

• Saya pikir akan lebih baik jika memiliki pengetikan statis , sehingga kesalahan dapat diketahui sebelumnya dalam siklus pengembangan. Tapi saya akan menggunakan inferensi tipe seperti di Haskell, sehingga pengembang tidak perlu menulis jenis di mana-mana dalam kode seperti di C, C # dan Java. Lihat Pelajari Anda Haskell untuk Bagus

• Saya juga akan mendesain perpustakaan UI yang bagus , dengan tata letak deklaratif , seperti pada WPF dan Android. Tetapi saya ingin memilikinya seperti dalam Pemrograman Reaktif Fungsional .

Jadi bahasa saya akan seperti konkurensi di Erlang tetapi dengan pengetikan seperti di Haskell dan kerangka kerja GUI seperti di WPF.NET.

Catatan: Saya telah menggunakan sintaks mirip C untuk menggambarkan fitur dalam posting ini, tapi saya tidak pilih-pilih tentang sintaks itu sendiri selama itu bukan sesuatu yang konyol seperti semua kata kunci menjadi CAPS.

1. Sistem pengetikan

Fitur nomor satu yang saya inginkan dalam bahasa adalah pengetikan statis dengan pengetikan dinamis opsional . Alasannya adalah karena pengetikan statis memungkinkan Anda untuk a) menangkap kesalahan lebih awal daripada terlambat dan b) sebagian besar kode secara implisit diketik secara statis, terlepas dari apakah bahasa membuat perbedaan. Namun, ada beberapa kasus penggunaan di mana pengetikan dinamis sangat berguna. Misalnya, saat membaca data dari file, Anda sering memiliki bidang tipe yang berbeda, dan pengetikan dinamis membuat wadah yang heterogen menjadi mudah. Jadi, bahasa ideal saya akan seperti ini:

//variable declarations
int anInt = 42 //anInt is now irrevocably an integer and assigning another type to it is an error
vartype aVariable = 42 //aVariable is currently an integer, but any type can be assigned to it in the future

//function definitions
int countElements(Collection c)
{
  return c.count();
} 

//c HAS to be a collection, since countElements doesn't make sense otherwise

void addToCollection(Collection& c, vartype v) 
{
  c.append(v)
}

//c is passed by reference here

2. Dikompilasi vs. Diartikan

Saya ingin bahasa dikompilasi terlebih dahulu, atau JIT dikompilasi, tetapi tidak murni ditafsirkan, kecepatan menjadi alasannya. Ini terkait dengan poin 1 , karena pengoptimal kompiler / jitter akan memiliki waktu yang lebih mudah mengoptimalkan kode yang diketik secara statis, dan kode yang diketik secara dinamis dapat dibiarkan apa adanya.

3. Penutupan

Bahasa harus mendukung konstruksi pemrograman fungsional, dan fungsi harus objek kelas satu.

4. Berorientasi objek

Bahasa seharusnya memungkinkan Anda untuk menulis kode berorientasi objek, tetapi kode imperatif sederhana juga harus diizinkan. yaitu, seharusnya dimungkinkan untuk menulis program hello world seperti:

int main(string<> args=null)
{
  printf("hello, world"); 
  return 0;
}

// this code also demonstrates two other features,
// default arguments for functions (not explained further)
// and immutable lists like string<> (see 6. Built-in datatypes)

5. Ruang nama

Ruang nama adalah hal yang baik. Sangat sedikit barang yang harus masuk ke ruang nama global. Tetapi jika Anda harus meletakkan barang di namespace global, Anda bisa (ala C ++).

6. Tipe data bawaan

Bahasa harus memiliki, sebagai tipe data bawaan, konstruksi berikut:

• Sebuah intdatatype atau jenis. Jika hanya ada satu intjenis, itu harus memiliki jangkauan tidak terbatas. Jika ada lebih banyak, harus ada upcasting implisit ke dalam tipe terkecil yang mampu menahan hasil perhitungan, dengan tipe rentang tak terbatas menjadi yang terbesar.
• floatTipe biner built-in tunggal , yang setara dengan IEEE 754double
• listTipe yang dapat diubah yang diimplementasikan sebagai daftar tertaut ganda atau blok penunjuk memori yang berdekatan untuk setiap elemen
• listTipe abadi yang bertindak seperti array tetapi ukurannya tidak dapat diubah setelah pembuatan
• Jenis yang bisa berubah dan tidak berubah string, dengan standarnya tidak berubah.
• Sebuah mapatau dicttipe yang bisa berubah, dan memegang kunci abadi dan nilai-nilai bisa berubah dan / atau berubah.
• Jenis koleksi bawaan harus homogen diketik secara default, tetapi bisa vartyped jika diperlukan
• Sebuah booleanjenis
• A nullatau nonetipe yang dapat ditugaskan ke variabel jenis apa pun.
• Bisa berubah dan abadi setjenis
• Suatu decimaltipe yang mengimplementasikan variabel floating point desimal
• Sebuah fixedjenis, yang menerapkan sejumlah fixed-point

The decimal, floatdan fixedjenisnya harus berbagi antarmuka publik yang sama persis (baik melalui pewarisan atau pengetikan bebek), memungkinkan mereka untuk diteruskan secara transparan ke dan dikembalikan dari fungsi. Tipe induk bisa dipanggil real.

7. Panggil berdasarkan nilai dan dengan referensi

Anda harus dapat memanggil fungsi dengan nilai dan referensi, dengan nilai defaultnya (yaitu, salinan argumen dibuat dan dioperasikan di dalam fungsi).

8. Pointer

Bahasa harus memiliki pointer dan memungkinkan aritmatika pointer. Pointer hanya dapat diketik secara statis (untuk menghindari mimpi buruk yang a void*). vartypepointer secara eksplisit dilarang. Memiliki aritmetika pointer dan pointer memungkinkan bahasa digunakan secara serius sebagai bahasa pemrograman sistem.

9. Majelis inline

Sehubungan dengan 8. , Bahasa harus memungkinkan kode bahasa rakitan inline untuk situasi-situasi di mana diperlukan.

10. Keamanan

Bahasa tersebut sebagian besar harus aman untuk digunakan, mendukung penanganan pengecualian, dll. Aritmetika pointer dan perakitan inline dapat diturunkan ke bagian kode yang secara eksplisit ditandai sebagai tidak aman. Kode yang tidak aman diizinkan, tetapi sangat tidak disarankan.

11. Perilaku tidak terdefinisi

Standar bahasa harus menentukan bagaimana program harus berperilaku dalam semua keadaan kecuali dalam kode yang secara eksplisit ditandai tidak aman, yaitu, seharusnya tidak ada perilaku yang tidak ditentukan di luar blok yang tidak aman. Ini memungkinkan bahasa yang akan digunakan sebagai bahasa pengembangan aplikasi yang layak, sementara masih memungkinkan Anda untuk mengatakan, menulis OS di dalamnya.

Hanya itu yang bisa saya pikirkan saat ini, tetapi saya akan mengedit / memperbarui posting karena saya memikirkan lebih banyak hal.

Beginilah tampilan bahasa pemrograman impian saya:

• Sistem tipe statis yang kuat dengan beberapa dukungan untuk pengetikan dependen.
• Pengetikan dinamis opsional.
• Numeric Tower ala Lisp tetapi diketik secara statis.
• Macro a la Lisp.
• Terutama bahasa Pemrograman Fungsional dengan dukungan dasar untuk pemrograman imperatif (seperti keluarga ML).
• Pengumpulan sampah.
• Ketikkan inferensi.
• Lanjutan.
• Semantik malas opsional.
• Semua konstruksi kontrol akan disediakan dalam bentuk fungsi perpustakaan. (Ini dapat dimungkinkan menggunakan dua fitur terakhir.)
• Sintaks minimal (tidak sesedikit Lisps, tetapi sesuatu dari jenis Ioke / Seph.)

Saya akan mendesainnya seperti C #, tetapi Microsoft mengalahkan saya untuk itu. :)

^{_{(Kecuali tentu saja bahwa milikku akan kurang dipikirkan dengan baik dan lebih amatir.)}}

Saya tidak terlalu keberatan apakah itu dikompilasi atau ditafsirkan, jadi saya tidak perlu membenarkan bagian itu.

Mengenai pengetikan statis yang kuat, saya merasa sulit untuk menghargai mengapa ini bahkan membutuhkan pembenaran. Pengetikan statis adalah fitur yang menangkap bug selama waktu kompilasi. Pengetikan dinamis adalah kurangnya fitur itu dan tetap memperbaiki bug sampai runtime. Dalam pengalaman pribadi saya, saya memiliki beberapa kasus penggunaan di mana pengiriman dinamis masuk akal dan berguna, sehingga konvolusi yang harus saya lalui dalam C # sebelum 4.0 untuk mendapatkannya dengan mudah dibenarkan saat itu. Dengan C # 4.0 saya bahkan tidak perlu membenarkan itu lagi karena kami memiliki pengiriman dinamis sekarang.

Namun, saya mungkin akan membuat sintaks baru alih-alih menempel dengan sintaksis lama terhadap sintaks C lama seperti yang dilakukan oleh C #. Pernyataan switch sangat mengerikan, dan saya juga tidak suka sintaks pemeran (itu adalah cara yang salah). Saya tidak membuat keributan besar tentang rincian sintaks, jadi saya tidak perlu membenarkannya secara detail, kecuali bahwa saya tidak ingin verbose sebagai verbose sebagai Visual Basic.

Apa lagi yang Anda ingin saya benarkan?

Nah inilah daftar fitur yang saya masukkan:

Gila suka sintaks

Gaya canggung

Pro :

• Sintaks yang mudah diperpanjang. Pernah mencoba menerapkan foreach loop di C? Itu tidak mudah. (Pikiran Anda, saya telah melakukannya ).
• Homoiconicity. Anda bisa saja(eval "your data files")

Cons :

• Notasi polesan bersarang seringkali sulit dibaca

Pemrograman Fungsional

Gaya haskell

Pro :

• Konkurensi mudah, semua kode aman.

Cons :

• Sulit untuk menerapkan efek samping dalam kode fungsional murni, meskipun monad tampaknya melakukan pekerjaan dengan baik.

Pengetikan dinamis yang kuat

Gaya python

Pro :

• Pengetikan dinamis membuat kode mudah dibaca, Pengetikan yang kuat dapat menghilangkan kesalahan ketik

Implementasi :

Izinkan fungsi berlebihan berdasarkan jenis, mirip dengan CL defgeneric:

(define (+ (a <int>) (b <int>))
  (ints-add a b))

(define (+ (a <string>) (b <string>))
  (string-concat a b))

(define (+ a b)
  (add-generic a b))

Compilable dan Interpretable

Pro :

• Peningkatan kinerja jika dikompilasi (biasanya benar, tidak selalu)

Cons :

• Dapat membatasi fitur dalam bahasa, llvm akan didukung dengan baik.

Pemrograman sistem

Gaya C.

Pro :

• Menarik bagi rentang pengguna yang sangat sedikit.
• Lebih mudah untuk aplikasi, kernel dan driver perangkat untuk berinteraksi jika semuanya ditulis dalam bahasa yang sama

Cons :

• Membatasi abstraksi dalam bahasa, pengetikan dinamis sering tidak cocok.

Makro higienis (gaya CL dan gaya Skema)

Pro :

• Mudah untuk memperluas bahasa, terutama dengan sintaksis Lispy ™
• Saya sudah mengatakan ini sebelumnya, bukan?

Cons :

• Tidak banyak jika dilakukan dengan sintaks Lispy ™

Kalau dipikir-pikir itu, skema ini kurang lebih mendefinisikan, kecuali untuk bit kompilasi dan pemrograman sistem. Itu bisa dikerjakan dengan menggunakan libguile dan menulis bit-bit itu dalam C.

Ada beberapa bahasa di luar sana yang saya anggap sangat bagus (C # menjadi favorit saya saat ini). Karena ini adalah bahasa fantasi saya, inilah yang saya inginkan:

• Dokumentasi resmi api kick-ass. API Java bagus seperti ini, dan C # /. NET cukup bagus. Ruby / Rails cukup mengerikan di sini.
• Dokumentasi umum resmi kick-ass (caranya, penggunaan umum, banyak kode contoh). C # /. Net bagus untuk ini.
• Komunitas besar pembuat dokumen berbasis blog dan pemecah masalah StackOverflow untuk membantu saya keluar dari kesulitan
• Berbagai macam plugin / librari / ekstensi yang didukung, didokumentasikan dengan baik, dan kuat (Ruby / Rails memiliki 'kuat' tetapi tidak satu pun dari dua lainnya).
• Cukup stabil - tidak mengubah segalanya untuk memecahkan sebagian besar kode yang ada secara tahunan (melihat Anda, Ruby / Rails).
• Tidak terlalu stabil - mampu beradaptasi dengan kemajuan dalam desain bahasa (melihat Anda, c ++)

Petunjuk kompiler

Saya berbicara dengan saya, karena saya tidak tahu banyak tentang desain bahasa, tetapi saya pikir fitur yang saya bicarakan disebut petunjuk dalam bahasa lain. Petunjuk kompiler , mungkin?

Saya tidak tahu apakah saya membaca ini dalam konsep Perl6 atau hanya tinggi pada saat itu, tetapi saya membayangkan bahasa di mana semuanya secara default longgar dan gila otomatis. Tetapi jika Anda ingin benar-benar meningkatkan kinerja dan berkata, hei, nilai ini selalu bilangan bulat atau tidak pernah nol, atau ini bisa paralel, atau ini tanpa kewarganegaraan, hal-hal seperti itu ... Bahwa kompiler dapat secara otomatis pergi ke kota pada area yang ditandai khusus ini.

E: Saya akan menghargai komentar yang menjelaskan apa yang saya minta atau mengutip contoh di mana ini sudah ada.

Untuk mencoba ide-ide baru:

Saya akan membuat bahasa pemrograman fungsional dinamis-diketik, memungkinkan Anda untuk melakukan semua trik ekspresi pernyataan dan sintaks lambda paling sederhana dengan pencocokan pola. Aturan off-side diaktifkan.

// a view pattern (or Active Pattern in F#)
default = \def val: !!val.Type val def

// usage of the pattern
greet = \name<(default "world") `and` hasType Str>:
  p "Hello, \{name}!"

(p "Enter your name", .input).greet // (, ) is a sequence expression, returning the last value

Berikut ini penjelasannya:

default =mengatur penyimpanan, \def valmemulai fungsi curried dengan dua argumen, val.Typesama dengan Type[val], !!mengkonversi ke boolean, dan boolean dapat diterapkan, jadi valdandef are after it.

f x= f[x]= x.f .f=f[]

dan di greet, itu digunakan name<(default "world")dan hasType Str>, itu berarti polanya default "world"akan digunakan dan terikat name. Pola default menentukan nilai default. andadalah pola lain yang menghubungkan dua pola bersama. yang defaultpola tidak bisa gagal sementara hasTypebisa gagal. Dalam hal itu, itu melempar pengecualian.

Variabel sebenarnya adalah penyimpanan, yang dapat secara fungsional diteruskan, dan tabel penyimpanan dapat menjadi referensi, dibuat dan dimusnahkan saat ruang lingkup berubah.

Hash dan semacamnya akan seperti di Lua dan JavaScript.

Jika saya akan membuat bahasa yang dikompilasi, saya akan membuat F # untuk Java, dengan fitur seperti Haskell. Ini adalah bahasa fungsional murni, kecuali ada fitur yang menggabungkan Kutipan dan Comp Exprs bersama untuk mencapai pemrograman imperatif dengan menulis blok pseudocode-like.

Ingatlah bahwa satu-satunya bahasa yang saya tahu adalah PHP dan javascript, dan bahwa saya benar-benar harus belajar lebih banyak lagi sebelum merancang bahasa:

Sintaks: Pikirkan baik-baik tentang nama fungsi dan urutan argumen (yaitu, menjadi kurang berantakan dari PHP).

Fitur: Memiliki seperangkat stringfungsi, yang beroperasi pada variabel sebagai serangkaian byte, tetapi tidak memahami teks, dan satu set textfungsi, yang memahami banyak penyandian dan dapat beroperasi pada UTF-8 dan string multibyte lainnya. (Dan memiliki pengkodean pemeriksaan kewarasan yang dibangun ke dalam bahasa, dengan fungsi seperti text.isValidEncoding(text, encoding)yang akan memberi tahu Anda jika urutan byte salah dan tidak aman untuk diperlakukan sebagai teks.

Saya pikir saya menyukai gagasan pengetikan statis yang kuat, tetapi saya tidak pernah menggunakannya, jadi saya tidak bisa mengatakannya.

Sebelum merancang bahasa pemrograman, saya akan menemukan jawaban yang bagus untuk pertanyaan: mengapa kita membutuhkan bahasa pemrograman lain? Kode Rosetta pada saat penulisan ini mencantumkan 344 bahasa. Jika tidak ada yang memenuhi kebutuhan saya, alasan mengapa mereka tidak menentukan titik awal (bahasa yang paling dekat) dan apa yang akan ditambahkan ke dalamnya.

Jika saya memenangkan lotre dan untuk beberapa alasan tidak ada yang lebih baik untuk dilakukan, saya akan mulai dengan Liskell dan menjadikannya bahasa yang lengkap sebagai lawan dari front-end GHC, kemudian membuat FFI lebih mudah (dan otomatis) sehingga saya dapat menggunakan Pustaka C / C ++.

Bahasa yang baik adalah bahasa yang:

• mudah untuk alasan tentang (tidak ada sintaks yang tidak jelas)
• memungkinkan Anda mengekspresikan ide-ide Anda dengan distorsi minimum
• sembunyikan detail seluk beluk dari Anda (optimisasi / manajemen sumber daya)
• mudah diparalelkan (banyak inti, komputasi terdistribusi)

Cukup sulit untuk mengubah ini menjadi daftar fitur, tapi saya pikir Pemrograman Fungsional, meskipun tidak terasa alami , lebih dekat dengan ini daripada pemrograman imperatif (terutama dalam menyembunyikan detail seluk beluk)

• C-interfacing : C adalah lingua franca bahasa pemrograman dan jumlah perpustakaan yang dikembangkan dalam C luar biasa. Dengan memiliki antarmuka yang mudah (seperti Python) ke C, bahasa secara otomatis mendapat manfaat dari semua pustaka tersebut dan juga memungkinkan untuk mengirim tugas-tugas berat yang tidak dapat dioptimalkan cukup dekat dengan bahasa logam.
• Didistribusikan : Saya suka Go's mengambil multi-threading, dengan rutinitas ringan yang dikirim runtime pada utas tergantung pada aktivitasnya. Bahasa seperti itu mendorong programmer untuk berpikir tentang tugas dan mengisolasinya satu sama lain.
• Pengumpulan Sampah : tidak perlu dikatakan lagi sekarang;)
• Immutable : lebih mudah untuk beralasan tentang sesuatu yang tidak pernah bisa bermutasi, lebih mudah untuk mengimplementasikan komputasi multithreading / terdistribusi juga (Anda hanya perlu sinkronisasi untuk menangani masa pakai, yang merupakan tugas kompiler)
• Lambdas : berjalan dengan fungsi kelas satu kurasa
• Message Passing : immutability berarti tidak ada mutex, oleh karena itu kami mengikuti saran Tony Hoares
• Modul : agak mirip dengan ruang nama, tetapi dengan enkapsulasi yang lebih baik
• Refleksi : perhitungan terdistribusi memerlukan serialisasi, yang harus diserahkan kepada kompiler, dan deserialisasi lebih mudah dicapai dengan beberapa bentuk refleksi.
• Static Strong Typing : semakin cepat kesalahan terdeteksi, paling tidak biayanya

Saat ini, bahasa yang lebih dekat ke daftar ini mungkin Haskell, meskipun:

• itu tidak memiliki Rutinitas: Saya belum melihat cara alami untuk mengekspresikan paralelisme di Haskell (meskipun itu mungkin ketidaktahuan saya ...)
• itu memiliki Sintaks Jelas: entah bagaimana sepertinya programmer Haskell berkembang menggunakan operator aneh daripada kata-kata. Ini mungkin tampak licin, tetapi tidak banyak membantu untuk memahami apa yang terjadi.

Untuk pertanyaan pertama Anda, "bagaimana Anda akan melakukannya" - jawaban singkat, saya tidak akan. Saya tidak punya cukup teori parser / kompiler untuk melakukan itu. Tapi saya sudah pemrograman selama 25 tahun, jadi saya punya beberapa ide dan pendapat untuk dibagikan.

Pertama, saya akan mencoba untuk datang dengan pendekatan OOP yang memungkinkan Anda membuat model yang benar-benar terhubung. Yang saya maksud dengan itu adalah, model adalah salah satu hal terpenting dalam hampir semua jenis proyek pemrograman - selalu banyak pekerjaan kasar dan refactoring terus menerus untuk memperbaikinya, dan saya menyalahkan itu karena kurangnya konektivitas nyata di Bahasa OO.

Izinkan saya untuk menunjukkan. Katakanlah kelas House memiliki properti Door.

var door = house.Door;

Anda sekarang memiliki variabel lokal dengan referensi ke instance Door.

Tetapi pertimbangkan apa yang baru saja terjadi: Anda baru saja merobek Pintu dari Rumah, dan sekarang Anda cukup senang melewati Pintu di sekitar, dan sisa kode Anda tidak mengetahui fakta bahwa Pintu ini sebenarnya melekat pada Rumah.

Bagi saya, ini pada dasarnya salah.

Dan ya, saya tahu, ini "mudah" diperbaiki berdasarkan kasus per kasus - dalam hal ini dengan mempertahankan referensi terbalik dari setiap Pintu ke Rumah yang saat ini dilampirkan. Ini tentu saja membuka model Anda untuk kesalahan, karena sekarang tugas Anda untuk secara akurat mempertahankan dua referensi terbalik, sehingga Anda membuat House.Lantai dan Door.Rumah properti pribadi, dan Anda menambahkan metode seperti House.AddDoor (), House.RemoveDoor ( ), Door.SetHouse () dll dan kabel semuanya, dan unit-test untuk memastikan itu benar-benar berfungsi.

Bukankah ini mulai terdengar seperti banyak pekerjaan untuk memodelkan hubungan langsung seperti itu? Banyak kode untuk dipelihara? Banyak kode untuk diperbaiki saat model berkembang?

Masalahnya adalah pointer. Setiap bahasa OO yang saya lihat, secara inheren menderita dari fakta bahwa referensi objek benar-benar sebuah pointer, karena itulah yang digunakan komputer.

Pointer bukan cara yang baik untuk memodelkan dunia nyata. Terlepas dari dunia apa yang Anda coba modelkan, hampir dijamin bahwa setiap hubungan di dunia itu akan menjadi hubungan dua arah. Pointer menunjuk pada satu arah saja.

Saya ingin melihat bahasa di mana model data dasar adalah grafik - di mana semua hubungan, secara default, memiliki dua ujung. Ini hampir pasti akan memberikan kecocokan yang lebih alami untuk memodelkan dunia nyata, yang merupakan satu-satunya hal yang kita perlukan untuk komputer. (itu dan video game.)

Saya tidak tahu seperti apa sintaksis untuk bahasa seperti itu, atau apakah itu bisa diungkapkan dengan teks. (Aku bertanya-tanya apakah bahasa seperti itu harus grafis, entah bagaimana ...)

Saya juga ingin melihat semua bentuk keadaan tidak sengaja dihilangkan.

Misalnya, dalam pengembangan web, kami menghabiskan banyak waktu untuk membentuk data dari basis data, menjadi model bisnis, menjadi model tampilan untuk presentasi ... kemudian sebagian dari data tersebut disajikan pada formulir, yang sebenarnya hanyalah transformasi lain. .. dan status kembali dari form-post, dan kemudian kami membentuk kembali data itu dan memproyeksikannya kembali ke model tampilan, misalnya pengikat model tampilan dan semacamnya ... kami kemudian memproyeksikan dari model tampilan kembali ke bisnis- model ... kami kemudian menggunakan pemetaan obyek-relasional (atau pekerjaan kasar) untuk mengubah data dari model-tampilan dan memproyeksikannya ke database relasional ...

Apakah ini mulai terdengar berlebihan? Pada titik selama semua kegilaan ini apakah kita benar-benar mencapai sesuatu yang bermanfaat? Dan maksud saya, sesuatu yang nyata - sesuatu yang dapat dipahami dan diperhatikan oleh pengguna akhir. Pada akhirnya, jam yang Anda habiskan benar-benar membangun sesuatu yang bahkan dapat dipahami pengguna, adalah satu-satunya jam yang dihabiskan dengan baik. Yang lainnya adalah efek samping.

Saya ingin bahasa yang sangat dinamis. Write / compile / run-cycle adalah pemborosan waktu yang membosankan. Idealnya, bahasa harus mencari tahu apa yang berubah, dan mengkompilasi / memuat secara transparan, di latar belakang, sesuai kebutuhan.

Idealnya, Anda bahkan tidak perlu menekan "run" - sesuatu harus terjadi di layar, saat Anda membuat perubahan, segera mencerminkan perubahan yang Anda buat. Masalah dengan write / compile / run-cycle, atau bahkan dalam hal ini lebih langsung write / run-cycle, adalah bahwa Anda terlalu terputus dari apa yang Anda lakukan - untuk merasa terhubung dengan pekerjaan kami, kami butuh umpan balik segera, hasil instan. Menunggu terlalu lama!

Sekali lagi, saya bahkan tidak tahu apakah ini dapat dilakukan dengan IDE tradisional, atau apakah ini akan membutuhkan jenis antarmuka yang sama sekali baru.

Anda harus dapat menggunakan campuran pengetikan yang lemah dan kuat, apa pun yang paling cocok untuk masalah yang sedang Anda kerjakan.

Keadaan secara umum harus menjadi sesuatu yang dikelola sepenuhnya oleh bahasa untuk Anda. Mengapa Anda harus mengandalkan database untuk kegigihan? Idealnya, saya ingin menentukan jangka hidup variabel apa pun dalam model: satu permintaan web, satu sesi, 24 jam, secara permanen.

Mengapa kita harus memilih antara seluruh rangkaian solusi penyimpanan untuk berbagai media dan masa pakai? - Belum lagi mengubah dan membentuk data agar sesuai dengan masing-masing media; cache browser, database, memori, disk, siapa yang peduli! Data adalah data. Di mana Anda menyimpan data Anda (dan untuk berapa lama) harus menjadi pilihan sederhana, bukan pertempuran melawan para Dewa!

Yah, semoga sukses dengan itu.

Ini mungkin akan menjadi bahasa multi-paradigma, mendukung yang berikut:

• Pemrograman terstruktur / prosedural
• Pemrograman berorientasi objek
• Pemrograman fungsional

Kenapa ini? Berorientasi objek karena ini merupakan cara terbaik untuk mengatur program besar, terutama untuk mengatur data. Terstruktur karena Anda tidak selalu menginginkan / membutuhkannya (OOP), orang harus memiliki pilihan. Fungsional karena memudahkan programmer untuk melakukan debug dan membuat program lebih jelas.

Saya akan menggunakan model Python dengan blok indentasi untuk menandai blok kode. Sangat clen dan enak dibaca.

Sebenarnya saya akan mencuri banyak ide dari Python karena Python adalah bahasa yang sangat bagus. Saya akan mengambilnya untuk pernyataan dan saya akan menyalin peta, daftar, dan tupelnya.

Sekarang, saya mungkin tidak akan mengambil konsep dinamis dari Python: untuk satu hal, mungkin akan secara eksplisit dan diketik mengetik. Saya pikir program menjadi lebih jelas dengan itu. Variabel-variabel mungkin semuanya menjadi objek dengan metode, maka Anda bisa melakukan sesuatu sepertistr.length() mendapatkan panjang string. Dalam definisi fungsi, Anda harus menentukan jenis pengembalian dan jenis argumen (mendukung beberapa jenis jenis umum juga).

Mari kita kembali menyalin dari Python ;-). Saya suka itu cara untuk memiliki argumen prosedur opsional jadi saya mungkin akan memilikinya. Namun Python tidak mendukung prosedur yang berlebihan, saya ingin itu.

Mari kita lihat kelas, saya akan membuang banyak warisan; untuk mudah disalahgunakan. Saya akan mengimplementasikan cakupan pribadi dan serupa dan saya mungkin akan menerapkan cara itu dilakukan dalam C ++. Saya juga akan memiliki kelas dan antarmuka abstrak; Saya tidak percaya Python memilikinya.

Itu akan mendukung kelas batin, pada kenyataannya, saya ingin bahasa berorientasi objek yang sangat kuat.

Mungkin akan ditafsirkan. Adalah mungkin untuk mendapatkannya dengan sangat cepat menggunakan kompilasi JIT yang baik (saya ingin bahasa yang cepat, meskipun produktivitas programmer akan didahulukan) dan kompilasi hanya buruk untuk produktivitas di banyak kali. Bahasa yang ditafsirkan juga mempromosikan independensi platform, sesuatu yang semakin penting untuk setiap hari.

Itu akan memiliki dukungan Unicode; hari-hari ini internasionalisasi sangat penting.

Itu pasti sampah yang dikumpulkan. Sial, aku benci melakukan manajemen memori sendiri; juga tidak baik untuk produktivitas.

Akhirnya, itu akan memiliki perpustakaan standar yang bagus.

Wow, baru sadar betapa aku sangat mencintai Python.

Pertama-tama, saya akan membeli beberapa buku tentang kompiler, beberapa standar, dan mengambil satu atau dua kursus dalam bahasa dan kompiler. Saya akan berkontribusi PEP dan mengunjungi pertemuan komite standar C ++. Saya akan berkontribusi tambalan ke kompiler yang saya gunakan, semoga baik untuk fitur dan bug.

Lalu saya akan kembali dan melihat dengan ngeri pada daftar yang saya buat sekarang ini, yang merupakan arah dari mana saya akan menggunakan bahasa jika saya mulai sekarang:

• Fungsional , karena saya saat ini tidak fasih dalam bahasa fungsional dan menjadikannya cara yang bagus untuk mempelajarinya. Dalam hal itu tidak mengikuti secara langsung: semuanya konstan .
• Saya akan mengisinya dengan Tipe Inference sebanyak yang saya bisa muat di dalamnya, tetapi dengan opsi untuk menentukan antarmuka secara eksplisit. Tidak yakin dengan tipe lain. Ini berfungsi ganda karena semua fungsi menjadi generik secara default.
• Seperti yang mungkin sudah Anda duga, dengan Interfaces ; yaitu, dengan tipe yang hanya memberikan janji pada operasi yang tersedia.
• Mengatakan apakah bahasanya diketik dengan kuat atau lemah tidak terlalu berarti dalam kasus ini, sejauh yang saya tahu. Saya akan menyebutnya sangat diketik, karena hal - hal tidak pernah mengubah antarmuka apa yang mereka implementasikan .
• Itu akan memiliki banyak Desain dengan dukungan Kontrak . Sekali lagi, sebanyak yang saya bisa cocok: prasyarat dan postkondisi adalah suatu keharusan; Saya tidak tahu seberapa penting invarian terkait dengan pemrograman fungsional.
• Sementara saya melakukannya, saya akan melihat bahasa di mana Anda dapat membuktikan kebenaran secara formal dan melihat apakah saya dapat mengambil apa pun dari sana.
• Saya akan keluar dan menulis perpustakaan pengujian yang luar biasa . Bahkan jika saya gagal membuatnya luar biasa, saya setidaknya akan menghabiskan banyak waktu untuk mengerjakannya karena saya pikir itu adalah sesuatu yang harus dimiliki setiap bahasa.
• Adapun sintaksnya, bahasa tersebut akan memiliki spasi putih yang signifikan dan terlihat sangat mirip dengan Python , atau akan didasarkan pada Lojban dan berbagi banyak tata bahasa dan kosa kata. Dalam kasus pertama, saya akan melakukan yang terbaik untuk membuat tata bahasa sedekat mungkin dengan CFG.
• Saya tidak akan peduli apakah orang yang mengimplementasikan bahasa akan mengkompilasi sebelumnya, JIT, menafsirkannya, mengucapkannya di api unggun , atau membayar anak-anak kuliah untuk mengeksekusinya untuk mereka. Implementasi saya sendiri mungkin akan mulai sebagai juru bahasa atau kompiler C, dan akhirnya bergerak menuju JITter.

Melihat bahkan hal-hal yang cukup luas ini mungkin akan cepat berubah jika saya mulai menerapkan bahasa, jadi saya pikir tidak perlu membahas lebih lanjut.

Jika saya punya waktu, saya akan merancang bahasa pemrograman yang dapat dilokalisasi yang didasarkan pada Scala, sehingga akan memiliki sebagian besar fitur-fiturnya, kecuali mungkin untuk XML. Tujuan saya adalah membuat bahasa yang membaca hampir secara alami dalam bahasa-bahasa dengan struktur yang berbeda dari bahasa Inggris, seperti bahasa Arab (bahasa ibu saya). Saya memikirkan fitur-fitur berikut:

• #langArahan pra-prosesor , digunakan untuk memberi tahu pra-prosesor bahasa manusia yang digunakan untuk pemrograman. Sebagai contoh: #lang arakan memungkinkan penggunaan kata فئةbukan class, عرفbukan def, dan sebagainya. Kata kunci khusus bahasa manusia akan didefinisikan dalam file preprosesor standar.
• Pra-prosesor akan menghapus beberapa kata kunci opsional yang tujuan utamanya adalah untuk menambahkan kejelasan pada kode. Misalnya, itu akan menghapus "terdiri dari" di class MyClass is composed of {menjadi class MyClass {, dan menghapus "sebagai" di def MyMethod(x: Int) as {menjadi def MyMethod(x: Int) {. Dalam beberapa bahasa (manusia), ini akan membuat kode lebih mudah untuk dipahami, terutama untuk siswa.
• Kompiler akan memungkinkan penggunaan notasi awalan untuk akses properti. Ini mungkin tidak masuk akal bagi sebagian besar penutur bahasa berbasis Latin, tetapi untuk beberapa bahasa lain itu masuk akal. Misalnya, akses properti dalam bahasa Arab biasanya awalan, seperti pada اعرض طول اسم محمد, yang setara dengan print(length(name(Mohammad)))pemrograman-bahasa Inggris. (Tanda kurung adalah untuk kejelasan.)

Saya percaya bahwa perubahan minimal pada pra-prosesor dan kompiler ini akan membuat pemrograman lebih mudah untuk penutur non-Inggris.