Falsafah reka bentuk Go: Less is more, dari mana asalnya?-Golang-php.cn

Semasa saya berkongsi ilmu dan pengalaman dalam komuniti Go dahulu, saya sering mendengar perkataan slanga seperti: less is more, less is more, the road to simplicity, the road to simplicity, etc.

Walaupun semasa membincangkan isu dan cadangan Go, sesetengah orang akan menggunakan "less is more" untuk menyangkal atau menyokong hujah, yang sangat menarik. Semua orang akan sangat ingin tahu, dari mana ia datang dan apakah maksudnya?

Sumber ayat emas

Konsep budaya masyarakat yang berakar umbi sebegitu pasti dicadangkan oleh orang teras. Beliau adalah penulis yang mengatakan ayat ini:

Pergi falsafah reka bentuk: kurang adalah lebih, dari mana datangnya?

Adakah sesiapa mengenalinya?

Beliau ialah Rob Pike, bapa kepada bahasa Go.

Rob Pike telah menyebut sesuatu mengikut baris "kurang adalah lebih" pada beberapa kali, dan ia diedarkan secara meluas.

Share pada masa -masa seperti:

in 2012, "less secara eksponen lebih banyak [1] " telah dikongsi di persidangan SF Go, yang merupakan artikel terawal yang disusun dari pendapat umum .
Simplicity is Complicated
[2]", yang terus menyemai budaya dan berkongsi pendapat.

Semestinya jika dilihat dari sambutan masyarakat, ada pujian dan kritikan. . , Dengan gambar, saya tidak akan mencipta semula roda dan menjelaskannya.

Seperti yang ditunjukkan di bawah:

Latar Belakang

Ini ialah kandungan ceramah (Rob Pike) saya pada persidangan Go di San Francisco pada Jun 2012.

Ini ucapan peribadi. Saya tidak bercakap bagi pihak sesiapa dalam pasukan projek Go, tetapi saya ingin bermula dengan mengucapkan terima kasih kepada pasukan atas segala yang mereka lakukan untuk membolehkan Go.

Pada masa yang sama, saya juga ingin mengucapkan terima kasih kepada komuniti San Francisco Go kerana memberi saya peluang bercakap ini.

Apa yang paling mengejutkan saya tentang Go

Beberapa minggu lalu saya ditanya: "Apa yang paling mengejutkan anda sejak melancarkan Go?"

Saya segera mendapat jawapan: Walaupun kami berharap pengaturcara C++ akan memahami Go sebagai bahasa alternatif, tetapi lebih ramai pengaturcara Go datang daripada Python dan Ruby, dan hanya beberapa daripada C++.

Kami (Ken, Robert dan saya) pernah menjadi pengaturcara C++ sendiri, dan kami mereka bentuk bahasa baharu untuk menyelesaikan masalah dalam perisian yang kami tulis.

Dan pengaturcara C++ yang lain nampaknya tidak begitu mengambil berat tentang masalah ini, yang kelihatan agak bercanggah.

Mengapa kami membangunkan Go

Hari ini saya ingin bercakap tentang perkara yang mendorong kami mencipta Go, dan mengapa kami terkejut apabila ia tidak sepatutnya berlaku.

Saya berjanji untuk membincangkan Go lebih daripada C++, dan anda masih boleh mengikuti topik ini sepenuhnya walaupun anda tidak tahu C++.

Jawapannya boleh diringkaskan sebagai: Adakah anda rasa kurang lebih, atau kurang lebih?

The Bell Labs Story

Berikut adalah kisah benar sebagai metafora. Seperti berikut:

Bell Labs pada asalnya dikenal pasti dengan tiga nombor: 111 untuk penyelidikan fizikal, 127 untuk penyelidikan sains komputer, dan sebagainya.
Pada awal 1980-an, memo tiba mengikut jadual yang menyatakan bahawa kerana penyelidikan seperti yang kami tahu ia berkembang, satu digit lagi perlu ditambah untuk mengenal pasti kerja kami dengan mudah. Jadi pusat kami menjadi 1127.
Ron Hardin secara berseloroh dan separuh serius berkata bahawa jika kita benar-benar memahami dunia dengan lebih baik, kita boleh mengurangkannya dengan satu digit dan menjadikan 127 hanya 27.

Sudah tentu pihak pengurusan tidak mendengar jenaka itu, atau mungkin mereka tidak mahu mendengarnya, tetapi saya rasa ada hikmah yang besar di dalamnya. Kurang lebih. Lebih baik anda memahami, lebih tersirat ia.

Sila ingat idea ini.

Latar belakang membangunkan Go

Kompilasi C++ menunggu

Pada bulan September 2007, saya sedang melakukan beberapa kerja yang remeh tetapi penting pada program teras Google C++ yang besar.

Saya mengambil masa kira-kira 45 minit untuk menyusun kluster teragih yang besar itu.

C++ penambahbaikan ciri baharu

Menerima pemberitahuan bahawa beberapa orang yang diambil bekerja oleh Google yang bekerja untuk jawatankuasa penyeragaman C++ akan memberikan laporan.

Mereka akan memberitahu kami apa peningkatan yang akan datang dalam apa yang pada masa itu dipanggil C++0x (kini dikenali sebagai C++11).

Semasa pembentangan selama sejam, kami mendengar perkara seperti terdapat 35 ciri yang telah dirancang.

Sebenarnya ada lagi, tetapi hanya 35 ciri yang diterangkan dalam laporan. Sudah tentu beberapa ciri adalah kecil tetapi cukup penting untuk disebut dalam laporan.

Terdapat juga beberapa yang sangat halus dan sukar difahami, seperti:

rujukan nilai.
templat variadik
literal yang ditakrifkan pengguna

Pada masa ini saya bertanya kepada diri sendiri satu soalan: AJK C++ benar-benar percaya bahawa tiada masalah dengan E?

Sudah tentu, dalam jenaka Ron Hardin yang lain,

memudahkan bahasa mencapai lebih daripada menambah ciri Sudah tentu ini agak tidak masuk akal, tetapi ingatlah idea ini

Percubaan bahasa seksual hanya beberapa bulan sebelum ini. Ceramah C++ ini, saya sendiri yang memberi ceramah, yang boleh anda lihat di YouTube, tentang bahasa konkurensi mainan yang saya bangunkan pada tahun 1980-an beberapa idea yang hilang dalam Newsqueak yang saya fikirkan semula semasa saya bekerja di Google Menulis kod sebelah pelayan menjadi lebih mudah, membolehkan Google mendapat manfaat daripadanya

Malah saya

cuba melaksanakan idea ini dalam C++, tetapi gagal.

Terlalu sukar untuk menyambungkan struktur kawalan C++ kepada operasi serentak Pada akhirnya sukar untuk melihat kelebihan sebenar

Walaupun saya mengakui bahawa saya tidak pernah benar-benar mahir menggunakan C++, tetapi C++ tulen masih menjadikan segala-galanya kelihatan terlalu kikuk .

Tetapi laporan C++0x itu membuatkan saya berfikir tentangnya semula. Satu perkara yang sangat mengganggu saya (dan saya pasti mengganggu Ken dan Robert juga) ialah model memori C++ baharu mempunyai jenis atom.

Rasanya satu kesilapan mutlak untuk menambahkan koleksi mikroskopik butiran deskriptif kepada sistem jenis yang sudah terlalu terbeban. Ini juga rabun hampir pasti bahawa perkakasan akan maju dengan cepat dalam sepuluh tahun akan datang Adalah sangat bodoh untuk mengikat bahasa terlalu rapat dengan perkakasan hari ini.

Go Initial Team

Selepas pembentangan kami kembali ke pejabat. Saya memulakan kompilasi lain, memusingkan kerusi saya ke arah Robert, dan mula menyampaikan isu utama.

Sebelum kompilasi tamat, kami telah membawa Ken masuk dan memutuskan perkara yang perlu dilakukan.

Kami tidak akan terus menulis C++, dan kami - terutamanya saya, mahu dapat menulis serentak dengan mudah semasa menulis kod Google.

Pada masa yang sama, kami juga mahu maju ke hadapan untuk mengawal "program besar", yang akan kami bincangkan kemudian.

Pergi perbincangan ciri

Kami menulis banyak perkara yang kami mahu dan syarat yang diperlukan di papan putih. Butiran sintaksis dan semantik diabaikan, dan pelan tindakan serta gambaran besar dibayangkan.

Saya masih mempunyai e-mel yang menarik dari masa itu.

Berikut ialah petikan:

Robert: Titik permulaan ialah C, betulkan beberapa kelemahan yang jelas, buang kekacauan dan tambah beberapa ciri yang hilang.

Rob: bernama "pergi". Anda boleh membuat asal usul nama itu, tetapi ia mempunyai asas yang baik. Ia pendek dan mudah dieja. Alat: goc, gol, goa. Jika anda mempunyai penyahpepijat/jurubahasa interaktif, panggil sahaja "pergi". Sambungan ialah .go.

Robert: Antara muka kosong ialah antara muka{}. Mereka melaksanakan semua antara muka, jadi ini boleh digunakan dan bukannya void *.

Kami tidak menggambarkan semuanya dengan betul. Contohnya, memetakan tatasusunan dan kepingan mengambil masa hampir setahun. Tetapi kebanyakan ciri penting bahasa telah dipaku dalam beberapa hari pertama.

Perhatikan bahawa Robert berkata C adalah titik permulaan, bukan C++. Saya tidak pasti, tetapi saya percaya dia maksudkan C, terutamanya jika Ken ada.

Tetapi hakikatnya pada akhirnya kita tidak bermula dari C. Kami bermula dari awal, hanya meminjam operator, kurungan, pendakap dan beberapa kata kunci. (Sudah tentu juga mengambil yang terbaik daripada bahasa lain yang kita tahu.)

Apa pun, kami kini melakukan yang bertentangan dengan C++, menyahbina segala-galanya, kembali ke petak pertama dan memulakan semula. Kami tidak cuba mereka bentuk C++ yang lebih baik, malah C yang lebih baik. Hanya bahasa yang lebih baik untuk jenis perisian yang kami minati.

Akhirnya, ia menjadi bahasa yang sama sekali berbeza daripada C dan C++. Setiap keluaran semakin berbeza.

Senarai Ciri Go

Saya membuat senarai pemudahan penting kepada C dan C++ dalam Go:

Sintaks kanonik (tiada jadual simbol diperlukan untuk menghurai).

Kutipan sampah (sahaja).

Tiada fail pengepala.

Kebergantungan eksplisit

Tiada kebergantungan kitaran.

Pemalar hanya boleh menjadi nombor.

int dan int32 adalah jenis yang berbeza.

Keterlihatan tetapan huruf.

Sebarang jenis boleh ada kaedah (tiada kelas).

Tiada warisan subjenis (tiada subkelas).

Pemulaan tahap pakej dan urutan pemulaan yang ditentukan.

fail disusun menjadi satu pakej.

Ekspresi global peringkat pakej adalah bebas pesanan.

Tiada penukaran aritmetik (pemalar diproses sebagai tambahan).

Pelaksanaan antara muka tersirat (tiada definisi "pelaksana" diperlukan).

Terbenam (tiada naik taraf ke kelas induk).

Kaedah ditakrifkan seperti fungsi (tiada keperluan lokasi khas).

Kaedah adalah fungsi.

Antara muka hanya mengandungi kaedah (tiada data).

Kaedah hanya sepadan dengan nama (bukan mengikut jenis).

Tiada kaedah pembinaan atau pemusnahan.

Pasca-kenaikan dan pasca-penurunan ialah kenyataan, bukan ungkapan.

Tiada kenaikan diri hadapan atau penurunan diri hadapan.

Tugasan bukan ungkapan.

Laksanakan mengikut susunan tugasan dan panggilan fungsi ditakrifkan (tiada "titik jujukan").

Tiada aritmetik penunjuk.

Memori sentiasa dimulakan dengan nilai sifar.

Adalah sah untuk mengambil alamat pembolehubah tempatan.

Kaedah tidak mempunyai "ini".

Timbunan bersegmen.

Tiada anotasi statik atau jenis lain.

Tiada templat.

Tiada yang luar biasa.

Rentetan, potong, peta terbina dalam.

Semakan sempadan tatasusunan.

Selain senarai ringkas ini dan beberapa trivia yang tidak disebutkan, saya percaya bahawa Go lebih ekspresif daripada C atau C++. Kurang lebih.

Tetapi walaupun begitu, anda tidak boleh membuang semuanya. Masih terdapat keperluan untuk menstrukturkan cara jenis berfungsi, mempunyai sintaks yang betul dalam amalan, dan untuk menjadikan perkara yang tidak dapat dijelaskan dalam menjadikan perpustakaan berinteraksi dengan lebih baik.

Kami juga menambah beberapa perkara yang tidak tersedia dalam C atau C++, seperti hirisan dan peta, pengisytiharan kompaun, ungkapan peringkat teratas setiap fail (perkara penting yang hampir dilupakan), refleksi, pengumpulan sampah, dsb. Sudah tentu, terdapat juga keselarasan.

Tidak boleh bayangkan tidak mempunyai generik

Sudah tentu apa yang jelas tiada ialah hierarki jenis. Tolong izinkan saya untuk mengatakan beberapa perkataan kasar tentang perkara ini.

Dalam versi asal Go, seseorang memberitahu saya bahawa dia tidak dapat membayangkan bekerja dalam bahasa tanpa generik. Seperti yang dinyatakan di suatu tempat sebelum ini, saya fikir ini adalah ulasan yang benar-benar ajaib.

Untuk bersikap adil, dia mungkin menggunakan caranya sendiri untuk menyatakan betapa dia menyukai apa yang STL lakukan untuknya dalam C++. Demi perdebatan, mari beri dia faedah keraguan.

Dia berkata bahawa menulis bekas seperti senarai int atau rentetan peta adalah beban yang tidak boleh ditanggung. Saya fikir ini adalah satu perkara yang menakjubkan.

Walaupun dalam bahasa yang tidak mempunyai generik, saya meluangkan sedikit masa untuk isu ini.

Pendekatan berorientasikan objek

Tetapi yang lebih penting, dia berkata jenis adalah penyelesaian untuk melepaskan beban ini. taip. Bukan polimorfisme berfungsi, bukan asas bahasa, atau bantuan lain, hanya jenis.

Ini adalah perincian yang menjebak saya.

Pengaturcara yang datang ke Go dari C++ dan Java merindui gaya pengaturcaraan bekerja dengan jenis, terutamanya warisan dan subkelas, dan semua yang berkaitan dengannya. Mungkin saya orang biasa apabila bercakap tentang jenis, tetapi saya tidak pernah mendapati model ini sangat ekspresif.

Arwah rakan saya Alain Fournier pernah memberitahu saya bahawa dia percaya bahawa bentuk biasiswa yang paling rendah ialah klasifikasi. Jadi anda tahu apa? Hierarki jenis ialah pengelasan.

Anda perlu membuat keputusan tentang bahagian mana yang masuk ke dalam kotak mana, termasuk induk setiap jenis, sama ada A mewarisi daripada B, atau B mewarisi daripada A.

Adakah tatasusunan boleh diisih ialah tatasusunan yang diisih atau pengasingan dinyatakan oleh tatasusunan? Jika anda percaya bahawa semua masalah adalah reka bentuk yang dipacu jenis, maka anda perlu membuat keputusan.

Saya percaya adalah tidak masuk akal untuk berfikir tentang pengaturcaraan dengan cara ini. Intinya bukanlah hubungan nenek moyang antara perkara, tetapi perkara yang boleh mereka lakukan untuk anda.

Sudah tentu, di sinilah antara muka masuk ke dalam Go. Tetapi mereka sudah menjadi sebahagian daripada pelan tindakan, yang merupakan falsafah Go yang sebenar.

Jika C++ dan Java adalah mengenai warisan jenis dan klasifikasi jenis, Go ialah tentang komposisi.

Doug McIlroy, pencipta akhirnya paip Unix, menulis pada tahun 1964 (!):

Entah bagaimana kita harus menyambungkan data mesej sekeping demi sekeping seperti paip taman dan hos. Ini juga kaedah yang digunakan oleh IO.

Ini juga kaedah yang digunakan oleh Go. Go mengambil idea ini dan membawanya selangkah lebih jauh. Ini adalah bahasa mengenai gabungan dan sambungan.

Contoh yang jelas ialah cara antara muka memberikan kita gabungan komponen. Selagi ia melaksanakan kaedah M, ia boleh diletakkan di tempat yang sesuai tanpa mempedulikan apa itu.

Satu lagi contoh penting ialah cara concurrency menghubungkan pengiraan yang dijalankan secara bebas. Dan terdapat juga corak gubahan jenis yang luar biasa (tetapi sangat mudah): pembenaman.

Ini ialah teknologi gabungan unik Go, yang berbeza sama sekali daripada program C++ atau Java.

Corak Pengaturcaraan Besar C++/Java

Terdapat reka bentuk Go yang tidak berkaitan yang ingin saya nyatakan: Go direka untuk membantu menulis program besar, ditulis dan diselenggara oleh pasukan besar.

Terdapat sudut pandangan yang dipanggil "Pengaturcaraan Besar", dan entah bagaimana C++ dan Java menguasai bidang ini. Saya percaya ini hanyalah kesilapan sejarah, atau kemalangan industri. Tetapi ia adalah kepercayaan yang diterima secara meluas bahawa reka bentuk berorientasikan objek boleh melakukan sesuatu.

Saya tidak percaya sama sekali. Perisian yang besar memang memerlukan perlindungan metodologi, tetapi ia tidak memerlukan pengurusan pergantungan yang begitu kuat dan abstraksi antara muka yang jelas, atau alat dokumentasi yang begitu cantik, tetapi ia tidak lebih penting daripada pengurusan pergantungan yang berkuasa, abstraksi antara muka yang jelas dan alat dokumentasi yang sangat baik. , dan tiada satu pun daripada perkara ini yang C++ lakukan dengan baik (walaupun Java jelas melakukannya dengan lebih baik).

Kami belum tahu lagi kerana tidak cukup perisian yang ditulis dalam Go, tetapi saya yakin Go akan menonjol dalam dunia pengaturcaraan besar. Masa akan menentukan.

Mengapa Go tidak disukai oleh pengaturcara C++

Sekarang, kembali kepada soalan menakjubkan yang saya nyatakan pada permulaan ceramah saya:

Mengapa Go, bahasa yang direka untuk memusnahkan C++, Dan mengapa anda mempunyai' t memenangi hati pengaturcara C++?

Ketepikan jenaka, saya rasa itu kerana Go dan C++ mempunyai falsafah yang berbeza sama sekali.

C++ membolehkan anda menyelesaikan semua masalah di hujung jari anda.

Saya memetik ini daripada Soalan Lazim C++11:

C++ mempunyai rangkaian abstraksi, keanggunan, fleksibiliti dan keupayaan ekspresif sifar kos yang lebih luas daripada pertumbuhan besar kod berkod tangan yang ditulis khas.

Arah pemikiran ini berbeza dengan Go. Kos sifar bukanlah matlamat, sekurang-kurangnya bukan sifar kos CPU. Usulan Go adalah lebih kepada meminimumkan beban kerja pengaturcara.

Pergi bukanlah menyeluruh. Anda tidak boleh mendapatkan semua terbina dalam. Anda tidak boleh mengawal setiap butiran pelaksanaan dengan tepat. Contohnya tiada RAII. Kutipan sampah boleh digunakan sebagai ganti. Juga tiada fungsi pelepasan memori.

Apa yang anda dapat adalah berkuasa tetapi mudah difahami dan mudah digunakan untuk membina beberapa modul yang digunakan untuk menyambung dan bergabung untuk menyelesaikan masalah.

Ini mungkin tidak sepantas, digilap, sejelas ideologi seperti penyelesaian anda yang ditulis dalam bahasa lain, tetapi pastinya akan lebih mudah untuk ditulis, lebih mudah dibaca, lebih mudah difahami, lebih mudah diselenggara dan lebih selamat.

Dalam erti kata lain, sudah tentu, agak terlalu ringkas:

Pengaturcara Python dan Ruby: Move to Go kerana mereka tidak melepaskan banyak ekspresi, tetapi memperoleh prestasi, dan menari dengan serentak.

Pengaturcara C++: Tidak boleh beralih ke Go kerana mereka berjuang keras untuk mendapatkan kawalan tepat ke atas bahasa mereka dan tidak mahu melepaskan apa-apa yang mereka perolehi. Bagi mereka, perisian bukan hanya tentang menyelesaikan kerja, tetapi mengenai menyelesaikannya dengan cara tertentu.

Jadi persoalannya, adakah kejayaan Go menafikan pandangan dunia mereka? Kita harus sedar sesuatu dari awal.

Mereka yang teruja dengan ciri baharu C++11 tidak akan mengambil berat tentang bahasa yang tidak mempunyai begitu banyak ciri. Walaupun ternyata bahasa itu mempunyai lebih banyak tawaran daripada yang mereka bayangkan.

Terima kasih semua.

Ringkasan

Saya sentiasa ingin tahu tentang falsafah Go tentang "kurang adalah lebih". Dari mana asalnya dan apakah maksudnya?

Saya membaca dan menyusunnya semasa Festival Musim Bunga Walaupun ucapan itu mengandungi banyak kandungan, ia juga lebih bahasa sehari-hari. Tetapi pada dasarnya apa yang Rob Pike maksudkan dengan "kurang adalah lebih" adalah sesuatu yang menarik.

Intinya ialah: "Konsep Go dan C++ adalah berbeza sama sekali. Diharapkan beban kerja pengaturcara akan diminimumkan. Sebilangan kecil cirinya sepatutnya boleh disambungkan dan digabungkan untuk menyelesaikan masalah, dan ia harus lebih ekspresif daripada fungsi timbunan."

Atas ialah kandungan terperinci Pergi falsafah reka bentuk: kurang adalah lebih, dari mana datangnya?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!