+1
Saya sangat ingin melihat ini terjadi.
Lebih mudah dibaca seperti end digunakan untuk pengindeksan.

+1
Pada 27 Desember 2013 13:06, "GaborOszlanyi" [email protected] menulis:

+1
Saya sangat ingin melihat ini terjadi.
Lebih mudah dibaca seperti akhir yang digunakan untuk pengindeksan.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/JuliaLang/julia/issues/5238#issuecomment -31280112
.

Saya suka saran ini juga.

Saya sedikit terkejut dengan gelombang dukungan yang didapat. Saya selalu merasa bahwa operator yang disebutkan jauh lebih intuitif untuk aliran kontrol, tetapi saya tidak menyadari bahwa perasaan itu tersebar luas.

Saya bukan penggemar ketika Anda membuat proposisi ini, tetapi saya harus mengatakan setelah beberapa pemikiran lagi, itu juga masuk akal bagi saya. Ini benar-benar operator aliran kontrol, berbeda dengan semua yang lain, yang menggunakan simbol daripada teks. Ini dapat mengurangi kebingungan dengan & dan | .

Saya perhatikan bahwa bahasa yang menyediakan and dan or (Perl, Ruby, Lua -- untuk yang saya periksa) juga menyediakan not (Lua bahkan tidak menawarkan ! ). Reaksi pertama saya adalah saya tidak menyukainya, karena berlebihan dengan ! . Tapi mungkin ada alasan kuat mengapa bahasa-bahasa ini memilih untuk melakukannya.

Saya pribadi sangat menyukai not , tetapi tidak berpikir bahwa beralih ke not menawarkan sesuatu seperti pengurangan ambiguitas yang disediakan oleh and dan or .

not juga bukan operasi arus hubung singkat/kontrol, dan saya selalu kesulitan dengan cara membacanya sehubungan dengan asosiatif. Satu-satunya tempat yang saya suka di Pyhton adalah if not ... tetapi itu karena saya membacanya sebagai operasi aliran kontrol.

+1

Dapat juga ditambahkan XOR sebagai korsleting?
Dan versi hubung singkat dari versi terbalik (XNOR,NAND,NOR)?

XOR tidak pernah hubung singkat. Yang lain dapat ditulis dengan mudah dengan ! ditambah operator and dan or .

+1
Saya akan menunjukkan bahwa di Ruby, ada kebingungan terus-menerus tentang && vs 'dan' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), jadi akan lebih baik jika kita mengingat rasional yang digunakan Ruby untuk memiliki kedua set operator dan memutuskan apakah itu sepadan dengan kebingungan atau jika && harus dihapus sepenuhnya demi 'dan'.

Saya lebih suka and dan or memiliki prioritas super rendah seperti yang mereka lakukan di Perl dan Ruby sehingga Anda dapat menulis hal-hal seperti

k <= n and k *= 2

Terkadang Anda ingin menetapkan hasil boolean ke sesuatu:

cond = f() && g()

Yang tampaknya bertentangan dengan itu.

Nah, itulah mengapa Ruby dan Perl memiliki kedua set operator dengan prioritas yang berbeda. Bukan menganjurkan itu, tapi hanya mengatakan. Saya tidak yakin seberapa umum penggunaan itu sebenarnya, sedangkan memahami kode kami mengungkapkan banyak hal k <= n && (k *= 2) .

Pertama, saya juga untuk and dan or .
Saya melihat bahwa empat kelompok prioritas terendah di Julia saat ini adalah

1. Tugas termasuk += dll., := , => , dan ~
2. Operator ternary ?
3. ||
4. &&

Saya pikir ini masuk akal (tidak yakin tentang ~ , tapi bukan itu intinya). Logical and dan or berguna baik sebagai sisi kanan dari tugas dan kondisi ? . Jika Anda akan menggunakan operator penugasan atau ternary sebagai argumen untuk and atau or , saya pikir Anda tahu bahwa Anda melakukan sesuatu yang tidak biasa dan tanda kurung sudah berurutan.

Btw, saya pikir banyak orang akan berharap bahwa bahasa yang menggunakan and dan or untuk operasi logis akan menggunakan not untuk negasi logis. Tetapi jika kita memiliki alasan yang baik untuk mempertahankan ! , itu mungkin tidak masalah. (Saya kira ! tidak sepenuhnya hanya negasi logis, setidaknya jika #4892 diimplementasikan digabungkan.)

Saya akan sedikit sedih tentang not daripada ! , tetapi saya akan memilih apa pun di sini.

Saya benar-benar tidak berpikir not analog sama sekali – and dan or adalah operator aliran kontrol, bukan fungsi, sedangkan ! hanyalah sebuah fungsi.

Saya setuju dengan Stefanus. Satu-satunya hal yang not benar-benar membuat Anda tidak harus menggunakan banyak tanda kurung. Saya pikir itu masalah yang terpisah.

Saya hanya berbicara tentang harapan awal pengguna baru. Tapi saya pikir
tampaknya ada alasan yang kuat untuk dapat menjaga !

Saya ingin menjadi sebaliknya. Cukup banyak bahasa yang menggunakan && dan ||, termasuk semua yang saya gunakan dengan keteraturan apa pun, dan itu selalu korsleting. Dengan dan/atau saya tidak memiliki ekspektasi intuitif apakah mereka mengalami korsleting atau tidak. Aku juga suka caranya && dan || secara visual dipisahkan dari nama dan nomor variabel.

Tabel di http://en.wikipedia.org/wiki/Short-circuit_evaluation mungkin memiliki relevansi untuk diskusi ini.

Sebagai seseorang yang berasal dari dunia Python, saya terkejut menemukan diri saya setuju dengan @GunnarFarneback. Akhir-akhir ini saya menemukan bahwa persyaratan bahasa Inggris ( and , or , not ) sering menyebabkan saya menulis kode yang salah yang secara naif saya harapkan berfungsi (karena masuk akal dalam inggris) dan kemudian harus menggaruk-garuk kepala selama beberapa detik sementara saya secara mental mengonversi dari bahasa Inggris ke pernyataan logis sebelum menyadari kesalahan saya. Yang mengatakan saya tidak terlalu bias di kedua arah; hanya memasukkan 2¢ saya.

Saya juga untuk and dan or

+1

+1
memiliki kedua operator
and dan or dengan prioritas lemah
Saya berpendapat bahwa cond = f() && g() harus ditulis cond = (f() && g()) .
Saya juga mendukung penggunaan not dengan prioritas lemah dengan alasan bahwa ! , yang memiliki prioritas kuat dalam setiap konteks yang saya lihat, membutuhkan if !(something and something) yang saya tidak suka pada beberapa , irasional, dan tingkat yang tidak dapat diubah. Saya juga merasa kadang-kadang ! sulit dilihat. Saya juga tidak tahu tentang asal ! tetapi merasa bahwa ia memiliki tempat yang lebih tepat sebagai operator faktorial pada bilangan bulat--jadi preferensi untuk sintaks ~ matlab.

@johnmyleswhite masalah ini ditutup? Saya pikir kapal telah berlayar yang satu ini.

:(

korsleting wajah cemberut itu

Saya pikir kita masih harus mempertimbangkan ini. Banyak orang tampaknya tidak suka menggunakan && dan || seperti yang kita gunakan dan lebih suka and dan or . Ada juga masalah prioritas, yang membuat && dan || agak canggung. Kita bisa pindah ke masa depan di mana && dan || memerlukan kedua operan menjadi boolean dan and dan or melakukan apa yang && dan || saat ini lakukan tetapi dengan prioritas yang lebih rendah sehingga Anda dapat menulis x == nothing and x = 0 dan semacamnya. Entah itu atau memperkenalkan sintaks bersyarat satu baris yang berbeda seperti x = 0 if x == nothing .

Sintaks terakhir x = 0 if x == nothing memiliki beberapa masalah IMO yang disarankan di https://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q.
Apakah dua opsi berikut begitu mengerikan sehingga Julia membutuhkan post-conditional?

    if x == nothing ; x = 0 ; end

atau

   x == nothing && (x = 0)

Yang mengatakan, sama seperti saya tidak keberatan melihat konstruksi repeat ; expr(s) ; until cond di Julia (tetapi dapat hidup tanpanya), saya tidak melihat ada yang salah dengan memiliki and dan or ditambahkan ke Julia.
Mereka tampaknya lebih cocok dengan sintaks julia daripada menggunakan pinjaman dari C && dan || .

Saya pikir kita masih harus mempertimbangkan ini.

+1

Saya terkejut dengan penugasan yang diprioritaskan lebih rendah daripada || , jadi saya mencari diskusi sebelumnya dan menemukan masalah ini. Ini bukan masalah besar, tetapi tanda kurung itu terlihat tidak pada tempatnya bagi saya. Butuh beberapa saat (beberapa detik, saya pikir, dan tes di REPL) untuk mengetahui lokasi penugasan mana yang tidak valid. - Pesan kesalahan menunjukkan garis melewati akhir definisi fungsi.

isempty(o) || (m.over[s][NULL] = o)

Sebaliknya, tanda kurung di cond = (f() && g()) terlihat baik-baik saja bagi saya. Saya pikir saya akan tetap menggunakannya.

Untuk apa nilainya, saya juga lebih suka and dan or .

+1 dari saya juga.

Tanggapan hampir bulat positif mendukung and dll. Saya menghitung dua pendapat menentang, satu acuh tak acuh, beberapa tidak ditentukan dan orang lain (15 atau lebih) mendukung.

Satu argumen menentang (lebih sulit dibaca) menurut saya tidak benar. Argumennya adalah bahwa foo and bar lebih sulit dibaca daripada foo && bar karena 3 kata vs kata SIMBOL kata. Namun semua orang menggunakan penyorotan sintaks, dan dalam hal ini terjadi sebaliknya. and diwarnai sebagai kata kunci, jadi a<1 and b>3 akan benar-benar mewarnai untuk memisahkan subekspresi kiri dan kanan secara visual, sedangkan a<1 && b>3 ketiga operator akan memiliki warna yang sama, isyarat potensi operator-diutamakan-menggaruk kepala.

Argumen _for_ yang belum disajikan adalah bahwa ada konsistensi elegan untuk operator boolean menjadi kata-kata, karena hasil operasinya adalah true atau false , yaitu juga sebuah kata. Jadi sangat mudah bagi pemula untuk menghafal & vs and untuk bitwise versus logis. Jauh lebih sulit untuk menghafal & vs && , karena tampaknya merupakan penugasan arbitrer. Dijamin pemula akan menggunakan & tidak benar, karena & menyampaikan kata and dalam bahasa Inggris. Ini mungkin menyebabkan bug prioritas(?).

Argumen lain yang mungkin _untuk_ adalah bahwa otak secara alami mem-parsing {BUNCH OF SYMBOLS} kata {BUNCH OF SYMBOLS}.

Mengapa tidak beralih saja? Sekarang selalu waktu terbaik untuk melakukannya, tidak akan pernah lebih mudah dari sekarang. Tidak sulit untuk memperbaiki kode yang saat ini menggunakan &&.

Punya and or not xor mungkin nand hanya untuk kelengkapan?? Saya tidak keberatan mempertahankan ! . Biarkan programmer memilih kapan harus menggunakan yang mana. Tidak ada yang salah dengan itu! Karena itu, ! sudah digunakan dalam fungsi gaya foo! , jadi ada beberapa argumen "minimalkan simbol kembali".

@StefanKarpinski tampaknya ada konsensus yang mendukung sejak 2013, saya dapat mencoba menerapkan ini, tetapi saya khawatir jika ini akan dipertimbangkan sama sekali, karena masalah ini belum ditutup, saya akan menganggap ini masih terbuka untuk diskusi? Menggunakan kata-kata ini alih-alih simbol akan berjalan dengan baik dengan isa menjadi operator infiks juga, sama seperti dengan true , false , end , dll. Tampaknya lebih konsisten dan mudah dibaca dengan cara ini.

+1

Baru pindah ke Julia dari Python. Tampaknya Julia dalam bahaya masuk ke simbol overflow. Demi kode yang dapat dibaca manusia, saya sangat mendukung and dan or

Mendukung kata kunci not juga dapat meningkatkan keterbacaan kode.

Haruskah kita menghentikan/melarang penggunaan and dan or (dan mungkin not ) masing-masing di 0.7/1.0, untuk dapat menambahkan ini nanti jika kita memutuskan untuk memang seperti mereka?

Aku akan turun dengan itu. Saya yakin @JeffBezanson menentang, tetapi kami jika kami melarang sekarang, kami selalu dapat mengubah pikiran kami nanti dan mengizinkannya, sedangkan kami tidak dapat pergi ke arah lain. Mungkin juga membantu untuk dapat memberikan pesan kesalahan sederhana "Gunakan && alih-alih and " kepada pengguna yang mencoba operator gaya Python.

Saya pikir itu bagus!

Membuka kembali dan menambahkan tonggak untuk memastikan kita tidak lupa.

Saya tidak mengerti maksud dari milestone tersebut, kita akan menambahkan and dan or ? kita mempertimbangkannya kembali? mencari penggunaan lain dari ini? Atau maksud Anda Anda akan menambahkan penghentian seperti peringatan, sehingga orang yang berasal dari Python tahu untuk menggunakan && alih-alih and ?

Saya memiliki https://github.com/JuliaLang/julia/pull/19788 di mana mereka adalah alias, tetapi saya dapat mengubahnya untuk menggantikannya.

Tonggak sejarah harus berarti: Mencapai keputusan. Atau, jika kami tidak dapat mengambil keputusan tepat waktu, hentikan penggunaan and dan or sehingga kami dapat menunda keputusan tanpa risiko melanggar kode siapa pun di kemudian hari.

Saya mengerti bahwa aspirasi yang diberikan untuk membekukan kode dalam beberapa minggu mungkin sudah terlambat untuk membuka kembali kaleng cacing ini sekarang (dan saya menghargai gagasan menambahkan penyusutan untuk membiarkan pintu terbuka untuk masa depan), tetapi satu pemikiran:

Ketika ini pertama kali muncul untuk diskusi (2013), saya pikir komunitas Julia terutama adalah pengembang -- orang-orang dengan latar belakang CS yang kuat yang lebih dari terbiasa menggunakan && dan || . Saya _mencurigai_ bahwa orang-orang yang mungkin menghargai and dan or sebagian besar adalah pengguna terapan yang tidak begitu nyaman dengan salad ascii dan yang belum menghabiskan cukup waktu dalam bahasa yang lebih lama untuk sepenuhnya terbiasa && dan || . Mungkin menarik untuk melihat bagaimana perasaan orang tentang hal ini jika kami melakukan polling terhadap pengguna Julia saat ini (terutama jika kami membahasnya tentang wacana di mana lebih banyak non-pengembang cenderung melihatnya).

Apa yang diusulkan adalah memesan sintaks and , or dan not . Jika kita melakukannya, kita dapat menambahkan ini sebagai operator kapan saja di timeline 1.x. Tidak ada diskusi lebih lanjut diperlukan untuk saat ini.

Saya akan baik-baik saja dengan menguraikan ini sebagai kesalahan sintaksis permanen, seperti yang kita lakukan dengan ** . Tapi saya masih sangat, sangat menentang memberi mereka arti apa pun sebaliknya.

Saya juga merasa disayangkan bahwa kami menggali masalah lama yang keputusannya telah dicapai, terutama yang mendekati 1.0.

Untuk lebih jelasnya: ini dilakukan jika seseorang melakukannya.

Terimakasih atas klarifikasinya! :D

Tampaknya sangat konyol bagi saya untuk repot-repot menguraikannya dan melarang penggunaan lain, dan tetap menjadikannya kesalahan sintaksis. Saya pikir kebanyakan orang lebih suka tidak memiliki situasi di mana and dan or adalah kata-kata yang dicadangkan (yaitu tidak dapat digunakan dalam konteks seperti <strong i="7">@stackeval</strong> 1 0 and 1 or ) namun tidak melakukan apa pun yang berguna. Saya akan menyarankan agar mereka tidak diuraikan sama sekali, atau diuraikan sebagai alias (yang tidak biasa, seperti yang dilakukan C dan Ruby).

Kami sudah memutuskan untuk tidak mengurai mereka sebagai alias, itu sebabnya PR ditutup. Jadi +1 untuk tidak menguraikannya sama sekali.

Dengan risiko mengulangi diskusi ini yang telah menimbulkan mual, saya akan perhatikan bahwa mengenai C dan Ruby, menggunakan and dan or dalam C sangat jarang dalam pengalaman saya, dan yang paling panduan gaya Ruby umum memerlukan && dan || daripada and dan or .

IMHO: sepertinya debat asli agak terbagi, dan menambahkan perlindungan ini hanya menyisakan ruang bagi komunitas untuk mengunjunginya kembali di masa depan yang mereka inginkan.

Saya tidak tahu mengapa ini dibuka kembali.

Dialek Julia dengan fitur sintaksis seperti ini dapat dilakukan menggunakan JuliaParser.jl dengan mudah, setelah API internal dan meta-pemrograman stabil, tidak sabar untuk itu! :senyum:

Bagi mereka yang datang ke masalah ini tanpa mengikuti apa yang telah terjadi: Meskipun ide menggunakan and dan or mengumpulkan cukup banyak dukungan *), PR pertama yang mendekati masalah - #19788 - terutama mengarah pada diskusi yang tidak meyakinkan tentang apakah and dan or harus menjadi pengganti langsung untuk && dan || atau harus memiliki semantik yang sedikit berbeda, mis. didahulukan, tetapi hanya menjadikannya alias dianggap tidak diinginkan. PR #24965 akan memesan kata kunci (bersama dengan not ), untuk memungkinkan memberi mereka arti selama siklus 1.x. Namun, diskusi selama panggilan triase menghasilkan ketidaksetujuan, jadi titik paling awal di mana hal ini dapat dipertimbangkan kembali adalah untuk 2.0. (Dan seseorang mungkin perlu membuat kasus yang benar-benar meyakinkan agar perubahan terjadi saat itu.)

*) Sepertinya perubahan yang diusulkan kurang populer dengan pengembang yang lebih berpengaruh/"inti", jadi hanya melihat jumlah 👍 mungkin menyesatkan.

Saya harap saya tidak terlalu menyederhanakan dan menyelesaikan semuanya dengan benar. Maaf jika tidak.

jadi titik paling awal di mana hal ini dapat dipertimbangkan kembali adalah untuk 2.0. (Dan seseorang mungkin perlu membuat kasus yang benar-benar meyakinkan agar perubahan terjadi saat itu.)

Saya tidak mengerti mengapa itu akan terjadi jika kami telah memutuskan berkali-kali sekarang untuk tidak melakukannya. Saya harap kami dapat menghindari menggali masalah ini lagi untuk setiap rilis besar.

Jika Julia bertahan cukup lama untuk bersaing dengan Python, saya dapat menjamin ini akan muncul lebih dan lebih. Banyak pengguna Python tidak ingin kembali ke sintaks C. Itu salah satu dari banyak alasan mengapa Python begitu populer: mudah dipelajari, membuat ketagihan untuk digunakan, Anda tidak ingin kembali ke cara lama dalam melakukan sesuatu.

Desainer bahasa baru sering mengklaim bahwa mereka menginginkan sintaks yang ramah pengguna, namun mereka cenderung tersesat dalam fitur-fitur mewah yang hanya diinginkan atau digunakan oleh sebagian kecil pengguna, sambil mengabaikan penyesuaian sederhana yang dapat mendorong adopsi.

Contoh kasus: operator Unicode yang aneh didukung , tetapi bukan bahasa alami and dan or .

R juga menggunakan && dan || dan 1-indexing. Ini bukan hanya bahasa yang lebih tua (atau bahasa tingkat rendah seperti C). Saya tidak peduli yang mana yang digunakan tetapi tidak lebih sulit: Saya telah mengajarkan R dan Python untuk menyelesaikan pemula (tidak ada perbedaan pemrograman) dan ini bukan yang mereka perjuangkan. Biasanya konsep yang mendasarinya lebih penting dan membutuhkan lebih banyak waktu untuk dipelajari daripada simbol atau kata yang digunakan untuk menulis kode. Sintaks "Ramah pengguna" dan "intuitif" bagi Anda sebagai pengguna R, Python, C, dll akan berbeda hanya karena apa yang sudah Anda kenal. Itu tidak berlaku untuk pemula mutlak yang harus lebih kita perhatikan di sini karena saya pikir mereka yang memiliki pengalaman pemrograman dalam bahasa lain memiliki pengalaman dan keahlian untuk menangani konvensi yang berbeda dalam bahasa baru.

Satu-satunya alasan yang tampaknya diangkat di sini adalah karena Python menggunakan and dan or dan orang-orang seperti itu. Apakah itu sepadan dengan kesulitan untuk berubah? Julia bukan Python dan seharusnya tidak mencoba. Kami sudah memiliki Python. Untuk memberi motivasi kepada siapa pun untuk beralih ke bahasa baru, itu harus berbeda. Pengguna baru Julia mungkin bukan programmer Python, mereka mungkin memiliki pengalaman dengan bahasa yang berbeda (atau tidak sama sekali jika menjadi cukup populer).

Saya menyadari ini mungkin masalah mati, tetapi sebagai balasan ke @TomKellyGenetics , saya akan menyarankan bahwa IMHO banyak dari kita akan berpendapat R memenuhi syarat sebagai "lebih tua" dan itu tidak terlalu ramah pengguna... Dan sementara saya setuju bahwa dengan pemula, && "bukan yang mereka perjuangkan", saya pikir sebagian besar siswa yang saya ajar menemukan operator bahasa Inggris ( and , or ) lebih akrab dan dapat dibaca apakah mereka Python pengguna atau tidak.

R juga menggunakan && dan || dan 1-pengindeksan. Ini bukan hanya bahasa yang lebih tua (atau tingkat yang lebih rendah) seperti C).

Saya mengacu pada bahasa seperti C, yaitu bahasa yang banyak meminjam sintaks dari C, biasanya dengan argumen yang terpenuhi dengan sendirinya 'itu adalah sintaks yang digunakan setiap bahasa lain'. Sintaks R agak mirip C, meskipun berbeda di sana-sini. Julia lebih mirip Fortran daripada C, meskipun ada beberapa yang tumpang tindih.

Saya telah mengajarkan R dan Python untuk menyelesaikan pemula (tidak ada perbedaan pemrograman) dan ini bukan yang mereka perjuangkan.

Siswa IME yang baru mengenal pemrograman berjuang dengan sintaks di atas segalanya, itu mati dengan seribu luka. Pemrograman itu asing, dan memilih simbol abstrak daripada bahasa alami membuatnya semakin asing dan mudah dilupakan. Saya sering mendengar pemula dalam bahasa seperti C menanyakan hal-hal seperti, "Bagaimana Anda menulis 'atau' lagi?"
Tetapi bahasa alami dalam pemrograman bukan hanya masalah bagi pemula. Bahkan pemrogram berpengalaman lebih cenderung melewatkan ! daripada not , dan banyak yang merasa lebih mudah untuk mempercepat membaca dan mengetik or dan and lebih dari || dan && .

Julia bukan Python dan seharusnya tidak mencoba. Kami sudah memiliki Python. Untuk memberi motivasi kepada siapa pun untuk beralih ke bahasa baru, itu harus berbeda.

Julia juga bukan C atau Fortran. Sebagian besar bahasa populer mirip-C, jadi menonjol biasanya berarti melakukan sesuatu yang berbeda dari C. Saya sebenarnya menyukai Fortran, C dan turunannya, menggunakannya sepanjang waktu, tetapi di beberapa tempat mereka gagal dan saya pikir kita bisa lakukan lebih baik. Menggunakan bahasa yang lebih alami adalah salah satu caranya. Perlu dicatat bahwa Fortran 77 dan lebih tinggi menggunakan .not. , .and. dan .or. untuk efek yang baik. Dalam hal ini saya sebenarnya ingin Julia menjadi lebih seperti Fortran, kurang seperti C!

Masalah ini telah diselesaikan; and dan or diperbolehkan sebagai pengidentifikasi dan kami akan terus menggunakan && dan || untuk aliran kontrol. Saya tidak yakin mengapa ini masih dibahas.

Ada kecenderungan untuk melebih-lebihkan pentingnya masalah sintaksis yang dangkal, karena mereka sangat terlihat, mudah didiskusikan, dan implikasinya biasanya jelas. Di bidang lain, bahasa dianggap tidak dapat digunakan kecuali blok kode dikelilingi oleh kurung kurawal, dalam hal ini baik julia dan python berada di luar batas.

Saya pikir masih bisa diperdebatkan apakah a and b memang lebih mudah dibaca daripada a && b . && menonjol. Fakta bahwa || dan && memiliki panjang yang sama juga dapat menghasilkan pemformatan yang lebih baik. Salah satu alasan simbol operator seperti a = b dan a + b bekerja dengan baik adalah karena mereka menambahkan struktur visual pada sesuatu seperti set a to b . a[i] atau element i of a ?

Anda tidak akan ingin kembali ke cara lama dalam melakukan sesuatu.

Bagi saya, cara lama dalam melakukan sesuatu adalah manajemen memori manual dan dukungan lemah untuk polimorfisme, bukan ejaan && .

Julia memiliki beberapa ekspresi bahasa alami, seperti for a in [1, 2, 3] . Ini membaca lebih baik dan lebih intuitif daripada for a = [1, 2, 3] , yang juga didukung Julia. Saya tentu tidak akan menyarankan kami menyediakan alternatif bahasa alami untuk semua operator simbolis, hanya beberapa yang membuat Julia lebih intuitif dan mudah dibaca.

FWIW, saya memilih untuk mengadopsi kedua set operator, untuk memudahkan adopsi dan memberikan pilihan gaya kepada pengguna. Dalam proyek C++ di mana orang menggunakan keduanya, itu tidak pernah mengganggu saya. Saya tidak melihat ada kerugian di dalamnya, hanya manfaat.

Secara keseluruhan saya suka arah sintaks Julia telah pergi. Keseimbangan yang hebat antara bahasa alami dan simbol, membuktikan bahasa numerik dapat unggul dalam pemrograman tujuan umum. Tidak sabar untuk melihat bagaimana ia tumbuh dan berkembang. Yang merupakan cara saya untuk mengatakan menambahkan operator bahasa alami secara teknis kompatibel. :menyeringai:

Saya akan mencoba memesan or , and dan not untuk kemungkinan penggunaan di masa mendatang, dan untuk mengeluarkan peringatan / saran untuk menggunakan simbol yang sesuai. Haruskah saya melakukan ini di Julia 0.7, 1.0, atau keduanya?

24965 ?

Ah, ketinggalan itu, terima kasih! Saya kira tidak memesan kata kunci tidak mencegah mendukung kata kunci ini di masa mendatang.

Maaf, baca semua diskusi, tetapi masih tidak mengerti, bagaimana saya bisa menggunakan and , or di Julia sekarang ?

kamu tidak bisa