Apa gunanya menambahkan dukungan pengidentifikasi Unicode ke berbagai implementasi bahasa?


14

Saya pribadi menemukan membaca kode yang penuh dengan pengidentifikasi Unicode membingungkan. Menurut pendapat saya, ini juga mencegah agar kode tidak mudah dipelihara. Belum lagi semua upaya yang diperlukan untuk penulis dari berbagai penerjemah untuk mengimplementasikan dukungan tersebut. Saya juga terus-menerus memperhatikan kurangnya (atau keberadaan) dukungan pengidentifikasi Unicode dalam daftar (dis) keuntungan dari berbagai implementasi bahasa (seperti itu benar-benar penting). Saya tidak mengerti: mengapa begitu banyak perhatian?


1
Apakah yang Anda maksudkan nama untuk sesuatu, atau maksud Anda karakter khusus seperti bintang, lambda, dan titik tengah?
Frank Shearar

5
lol! Tahukah Anda bahwa ada dunia di luar negara yang berbahasa Inggris? Penemuan Amazign, bukan?
deadalnix

3
deadalnix: Saya tinggal di negara seperti itu, jadi kami mungkin menggunakan pengidentifikasi seperti größe. Yang mengatakan, saya tidak pernah melakukan itu dan saya sangat tidak menyarankan melakukan itu. Karena itu, pertanyaannya sangat valid.
user281377

2
deadalnix: Sejauh ini saya belum pernah berada di negara berbahasa Inggris. Mengapa tidak memperhatikan pertanyaan yang sebenarnya, bukan penanya?
Egor Tensin

6
Saya berharap bahasa akan fokus pada mendapatkan Unicode benar dalam penanganan string dan meninggalkan pengidentifikasi unik unicode. Sumber daya pemrograman yang baik adalah dalam bahasa Inggris (StackOverflow), jadi mari kita akui pemrograman harus dilakukan dalam bahasa Inggris (juga membuat berbagi lebih mudah) dan fokus pada penerapan manipulasi string Unicode yang tepat.
Matthieu M.

Jawaban:


17

Ketika Anda berpikir unicode, Anda berpikir karakter Cina atau Rusia, yang membuat Anda memikirkan beberapa kode sumber yang ditulis dalam bahasa Rusia yang Anda lihat di internet, dan yang tidak dapat digunakan (kecuali Anda tahu bahasa Rusia).

Tetapi jika unicode dapat digunakan dengan cara yang salah, itu tidak berarti itu buruk dengan sendirinya dalam kode sumber.

Saat menulis kode untuk bidang tertentu, dengan unicode, Anda dapat mempersingkat kode Anda dan membuatnya lebih mudah dibaca . Dari pada:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

kamu bisa menulis:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

yang mungkin tidak mudah dibaca untuk pengembang biasa, tetapi masih mudah dibaca untuk orang yang menggunakan simbol matematika setiap hari .

Atau, saat melakukan aplikasi yang terkait dengan fotografi SLR, alih-alih:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

Anda dapat mengganti aperture dengan simbolnya ƒ, dengan tulisan yang lebih dekat ke ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Ini mungkin tidak nyaman : ketika mengetik kode C # umum, saya lebih suka menulis:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

daripada:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

karena dalam kasus pertama, IntelliSense membantu saya untuk menulis seluruh kode hampir tanpa mengetik dan terutama tanpa menggunakan mouse saya, sedangkan dalam kasus kedua, saya tidak tahu di mana menemukan simbol-simbol itu dan akan dipaksa mengandalkan mouse untuk pergi dan cari di daftar penyelesaian otomatis.

Ini dikatakan, itu masih berguna dalam beberapa kasus. currentLens.GetMaximumƒ();contoh saya sebelumnya bisa mengandalkan IntelliSense dan mudah diketik GetMaximumAperture, lebih pendek dan lebih mudah dibaca. Juga, untuk domain tertentu dengan banyak simbol, pintasan keyboard dapat membantu mengetik simbol lebih cepat dari padanan literalnya dalam kode sumber.

Hal yang sama, omong-omong, berlaku untuk komentar. Tidak ada yang mau membaca kode yang berisi komentar dalam bahasa Mandarin (kecuali jika Anda sendiri tahu bahasa Mandarin) Namun dalam beberapa bahasa pemrograman, simbol unicode masih bisa bermanfaat. Salah satu contohnya adalah catatan kaki¹.


¹ Saya pasti tidak akan menikmati catatan kaki dalam kode C # di mana ada seperangkat aturan gaya yang ketat tentang cara menulis komentar. Di PHP di sisi lain, jika ada banyak hal untuk dijelaskan, tetapi hal-hal itu tidak terlalu penting, mengapa tidak meletakkannya di bagian bawah file, dan membuat catatan kaki di PHPDoc dari metode ini?


ASCII mencakup 37 karakter yang dapat digunakan dalam pengidentifikasi; Saya berharap bahwa di sebagian besar font, mereka cukup berbeda secara visual sehingga bahkan orang yang tidak fasih dalam alfabet Latin dapat belajar untuk memberitahu dua string karakter dalam font yang berbeda adalah pengidentifikasi yang sama. Berapa banyak upaya debugging yang akan sia-sia ketika seorang programmer menggunakan "Ф" untuk sudut bukan "Φ"?
supercat

1
@ superupat: poin bagus. Tetapi contoh yang Anda berikan menunjukkan penggunaan alat yang buruk daripada alat itu sendiri buruk. Δxatau penggunaan -∞yang valid (dengan beberapa kelemahan saya jelaskan dalam jawaban saya). Ф/ Φdi sisi lain hanya tanda-tanda bahwa programmer tidak mengerti bagaimana menamai variabel dengan benar.
Arseni Mourzenko

1
Jika seorang programmer menginginkan huruf kecil Yunani theta (misalnya untuk sudut horizontal), apakah Anda tahu simbol mana yang saya berikan yang benar? Ada banyak kelompok karakter yang terlihat sangat mirip jika tidak identik. Jika file sumber diminta untuk berisi arahan yang menentukan karakter apa yang bisa hidup berdampingan dalam pengidentifikasi yang mungkin membantu, tetapi sebaliknya saya melihat banyak potensi kebingungan antara variabel yang dinamai secara akurat dengan karakter asing versus yang dinamai dengan karakter yang mirip.
supercat

1
@supercat: maksud Anda huruf Yunani phi? Maksud saya adalah jika pemrogram menggunakan simbol ini dalam aplikasi di mana istilah "fungsi distribusi kumulatif" diharapkan, setiap orang yang sadar akan terminologi dan simbol domain akan memahami apa artinya Φ. cumulativeDistributionFunctionterlalu panjang CDFkurang terbaca dari Φ. cumDistFuncjelek. Ini juga berarti bahwa jika programmer menggunakan huruf kecil Cyrillic EF (Ф) sebagai gantinya dalam konteks ini, itu hanyalah kesalahan. Dengan cara yang sama, seorang programmer bisa menggunakan istilah yang salah atau singkatan yang salah.
Arseni Mourzenko

1
Jika nama variabel terdiri dari underscires, 0-9, az, dan AZ, seseorang dengan salinan kode yang tidak mendukung copy / paste (misalnya cetakan) mungkin berharap untuk mereproduksi secara akurat. Seseorang yang mencoba menyalin "ɸ" tanpa mengetahui apa artinya mungkin dengan mudah berakhir dengan "Ф", dan bahkan jika pemrogram tahu itu seharusnya "phi", tidak akan jelas apakah "φ" atau "ɸ" adalah sesuai. [Satu adalah "Latin Small Letter Phi", dan satu adalah "Greek Small Latter Phi" - mereka tampak jelas berbeda dalam font komentar ini, tetapi tidak dalam mis Lucida Sans Unicode].
supercat

8

Saya akan mengatakan:

  1. untuk memudahkan non-profesional dan pemula yang belajar pemrograman (misalnya di sekolah) dan tidak tahu bahasa Inggris. Mereka tidak menulis kode produksi. Saya telah melihat kode berkali-kali seperti:

    double upsos, baros;
    cin >> upsos >> baros;
    

    Biarkan orang miskin menulisnya dalam bahasanya:

    double ύψος, βάρος;
    cin >> ύψος >> βάρος;
    
  2. Apakah kamu tidak menyukainya?

    class ☎ {
    public:
        ☎(const char*);
        void 📞();
        void 🎧(👨);
    };
    
    ☎ ☏("031415926");
    ☏.🎧(👨("Bob"));
    ofstream f;
    f.💾();
    

Ironisnya, kode di bawah "Dont 'you like it" tidak ditampilkan dengan benar, jenis yang menggambarkan mengapa Anda mungkin ingin tinggal jauh dari menggunakan karakter yang funky.
Kris

5

Tentu saja, setiap kompiler modern harus berurusan dengan kode sumber Unicode hari ini. Misalnya, konstanta string mungkin perlu mengandung karakter Unicode. Tapi begitu ini tercapai, mengapa tidak mengizinkan pengidentifikasi unicode juga? Ini bukan masalah besar kecuali kode kompiler Anda tergantung pada karakter menjadi kode 7-bit.

Tetapi OP benar sejauh: Sekarang mungkin bahwa seorang India berbahasa Hindi harus menjaga kode dengan pengidentifikasi Rusia dan komentar Arab. Sungguh mimpi buruk bagi orang Tionghoa miskin yang seharusnya melakukan pemeriksaan kualitas dan yang tidak dapat membaca salah satu dari 3 huruf di atas!

Oleh karena itu, sekarang merupakan tugas organisasi untuk memastikan program pengidentifikasi dan komentar ditulis dalam bahasa yang sama. Saya tidak dapat menahannya tetapi saya pikir ini akan menjadi bahasa Inggris untuk beberapa waktu mendatang.


Masalah dengan memungkinkan pengidentifikasi Unicode adalah memungkinkan kode sumber memuat informasi yang secara semantik penting tetapi tidak dapat dicetak. Sebagai contoh, jika sebuah kelas menyatakan field А, konstruktornya menerima parameter Α, dan pernyataan dalam konstruktor mengatakan var x = A.boz();, akan Amerujuk pada field, parameter, atau mungkin sesuatu yang lain? Bagaimana orang bisa tahu?
supercat

1
Ya, tetapi kemudian, hanya beberapa karakter yang mirip dan kemudian, seperti yang sering terjadi, masalah gaya, pedoman pengkodean dan jaminan kualitas yang harus memastikan Anda tidak menggunakan 3 karakter berbeda yang terlihat seperti A in satu tempat. OTOH, sebagai pencinta kebebasan, aku benci melarang sesuatu hanya karena orang tidak yakin itu bisa disalahgunakan oleh seseorang.
Ingo

Saya kira saya cenderung berpendapat bahwa program harus dimasukkan baik dalam format yang dapat dibaca manusia, atau dalam format yang tidak dibatasi menjadi file teks terpadu (tetapi dapat mencakup negara yang saling berhubungan dengan garis, penjelasan yang melekat pada hal-hal , dll.). Saya pikir ada nilai yang cukup untuk mengetahui bahwa "apa yang Anda lihat adalah - setidaknya secara semantik - apa yang ada di sana", dan berpikir bahwa program yang berbeda harus terlihat berbeda. Jika ada standar yang melarang penggunaan pengidentifikasi yang dekat, tetapi tidak cukup cocok, pengidentifikasi dalam lingkup yang lebih dekat, itu mungkin membantu.
supercat

4

Saya pikir itu masuk akal untuk memungkinkan karakter unicode di string dan komentar. Dan jika lexer & parser harus mendukung unicode untuk itu, penulis kompiler mungkin mendapatkan dukungan karakter unicode secara gratis, jadi sepertinya pembatasan sewenang-wenang untuk hanya mengizinkan karakter ASCII dalam pengidentifikasi.


8
Tidak juga. Dalam string literal, karakter non-ASCII dapat diperlakukan sebagai buram. Dengan pengidentifikasi, Anda perlu membuat keputusan tentang karakter mana yang valid, dan apakah akan menormalkannya (mis., várSama dengan vár?)
dan04

4

Sejauh yang saya ketahui, ini murni untuk alasan pemasaran . Dan juga dapat membuat hidup kita lebih sulit.

Argumen pemasaran

Anda tahu daftar fitur gila yang dibanggakan sebagian besar bahasa ini? Secara umum ini sangat tidak berguna, karena sangat jauh dari bahasa sehingga tidak memberikan banyak informasi spesifik, tetapi memungkinkan seseorang untuk dengan cepat berpakaian meja dengan kutu dan tanda silang dan secara tepat menyimpulkan bahwa karena X memiliki lebih banyak kutu daripada Y, itu harus Jadi lebih baik.

Nah, dukungan Unicode untuk pengidentifikasi adalah salah satu dari itu. Tidak masalah jika dibandingkan dengan dukungan Lambda, dukungan pemrograman Generik, dll ... mungkin tidak banyak, orang yang menggambar tabel tidak peduli dengan kualitas setiap baris, hanya tentang jumlah mereka.

Dan dengan demikian mereka dapat menyombongkan diri: "Ah, dengan Y Anda tidak memiliki dukungan Unicode untuk pengidentifikasi Anda! Di X kami melakukannya, jadi bagi siswa itu jauh lebih mudah!"

Kekeliruan aksesibilitas

Sayangnya, argumen aksesibilitas keliru.

Oh, saya mengerti bahwa bisa menulis "résultatDuJetDeDé" alih-alih "daduThrowResult" (ya saya orang Prancis) mungkin tampak seperti kemenangan dalam jangka pendek ... namun ada kekurangannya!

Pemrograman adalah tentang berkomunikasi

Program Anda tidak hanya ditujukan untuk kompiler (yang tidak terlalu peduli dengan pengidentifikasi yang Anda gunakan), tetapi juga ditujukan untuk rekan Anda. Mereka harus bisa membacanya, dan memahaminya.

  • membacanya menyiratkan mampu memvisualisasikan karakter yang Anda gunakan, Unicode tidak begitu didukung oleh semua font
  • memahaminya berarti bergantung pada pengidentifikasi - kecuali jika Anda menambahkannya dengan komentar panjang, tapi itu melanggar aturan KERING.

Tentu saja, teman sekelas Anda mungkin berbicara dengan bahasa yang sama seperti yang Anda lakukan (tidak jelas, saya memiliki kelas pemrograman dengan Jerman, Spanyol, Libanes dan Cina), dan mungkin juga guru Anda ... tetapi anggaplah bahwa entah bagaimana Anda mengerjakannya di rumah dan tiba-tiba butuh bantuan: Internet itu hebat, Anda bisa berbicara dengan ribuan ribu orang yang tahu solusinya, mereka hanya akan menjawab jika mereka mengerti pertanyaan Anda. Dan Anda perlu memahami jawaban mereka juga.

Pemrograman membutuhkan pemahaman

Aksesibilitas dan inisiasi mengharuskan Anda mendasarkan diri pada perpustakaan untuk melakukan pengubahan ketinggian untuk Anda: Anda tidak ingin menemukan kembali lapisan IO untuk membaca dari / menulis ke konsol pada tugas pertama Anda.

  • Dalam bahasa apa perpustakaan itu ditulis?
  • Dalam bahasa apa perpustakaan itu didokumentasikan?

Jika Anda menjawab bahasa Arab Morrocan, saya akan terkejut.

Kecuali Anda hanya mengandalkan ceramah Anda membantu untuk, dan mereka dokumentasi yang komprehensif hadir pada setiap fitur perpustakaan Anda akan perlu digunakan (dan bahkan mungkin diterjemahkan perpustakaan), maka Anda akan harus belajar modicrum dari bahasa Inggris. Namun, Anda mungkin sudah melakukannya jauh sebelum memulai kursus pemrograman ini.

Bahasa Inggris adalah...

... lingua franca programmer (dan sebagian besar ilmuwan).

Semakin cepat dia mengakuinya, dan menyertainya alih-alih melawannya, semakin cepat dia bisa benar-benar belajar dan maju.

Beberapa orang pasti akan menentang hal ini, dan dengan benar mempertahankan hak mereka untuk berbicara bahasa pilihan mereka (bahasa ibu mereka biasanya), namun, seperti yang ditunjukkan Babel, semakin banyak bahasa digunakan, semakin sulit komunikasi yang didapat.

Masih...

Ya, seperti yang telah diperdebatkan berulang kali, beberapa dukungan Unicode (terutama simbol) dapat sangat memudahkan pemahaman bagi orang-orang yang harus menerjemahkan rumus matematika atau fisika, misalnya, ke dalam kode. Ada kekurangan beberapa simbol kelebihan beban, tetapi masih bisa membantu.

Jadi kenapa ?

Yah, seperti yang dikatakan, ini bukan tentang kenyamanan pengguna, melainkan tentang klaim pemasaran. Itu mati mudah juga, karena parser sudah Unicode sadar akan string dan komentar, jadi sebagian besar mengambil lompatan.

Dan mungkin ada manfaatnya bagi pengguna tertentu.

Tapi saya pribadi hanya akan berurusan dengan kode yang ditulis dengan pengidentifikasi bahasa Inggris. Saya tidak peduli jika Anda membutuhkan bantuan saya dengan sepotong kode Anda atau jika perpustakaan Anda hanya luar biasa dan saya bisa mendapatkan banyak dengan menggunakannya: jika saya tidak dapat memahaminya, saya hanya harus mengabaikannya.


Jadi Anda salah satu dari mereka yang bersedia memanggang realitas de facto historis menjadi yang de jure (maafkan kurangnya aksen, tampaknya tidak ada yang peduli hari ini)?
Milind R

@MilindR: Saya adalah salah satu dari mereka yang berpikir dunia akan menjadi tempat yang lebih baik jika semua orang berbicara dalam bahasa yang sama; dan saya cukup pragmatis untuk mempertimbangkan bahasa Inggris untuk peran itu, meskipun bahasa Prancis. Saya mungkin yakin bahwa subset dari Unicode dapat membantu secara umum (huruf Yunani, untuk matematika / fisika). Saya mengerti bahwa untuk pengajaran pemrograman, bahasa pemrograman di mana siswa dapat mengekspresikan pengidentifikasi dalam bahasa mereka sendiri sangat membantu; namun ini tidak mengharuskan setiap dan semua bahasa mendukung pengidentifikasi Unicode penuh. Ini pendapat pribadi saya, buat apa yang Anda inginkan :)
Matthieu M.

3

Bagaimana Anda akan mengetik pengidentifikasi ASCII pada keyboard Cina? Beberapa kata kunci bahasa adalah satu hal, dan harus melakukan seluruh kode Anda dengan cara lain.

Pemrogram harus memiliki hak dan kemampuan untuk memanggil variabel mereka apa pun yang mereka inginkan. Bukan urusan Anda bahasa apa yang ada di dalamnya.

Jika Anda merasa begitu bingung kode dengan pengidentifikasi yang memiliki simbol dari bahasa orang lain di dalamnya membaca, maka saya yakin bahwa Anda persis memahami bagaimana bingung mereka rasakan ketika mereka harus menggunakan pengenal dengan simbol dari Anda bahasa dalam.


4
Saya mengetik pesan ini menggunakan keyboard "Rusia". Saya sudah googled keyboard Cina ( goo.gl/U1q0m ) dan saya tidak benar-benar melihat perbedaan dengan yang Rusia ( goo.gl/af04R ). Perhatikan, omong-omong, bahwa keduanya memiliki tata letak Latin bersama dengan yang asli.
Egor Tensin

2
Katakanlah saya menggunakan pengidentifikasi menggunakan Cyrillic. Tetapi bagaimana dengan orang Cina yang memelihara kode saya? Katakanlah, dia akrab dengan huruf Latin, tetapi sekarang dia dibuat untuk menangani set karakter yang sama sekali berbeda! Belum lagi huruf hiasan Arab dan lain
Egor Tensin

2
Paragraf ketiga adalah alasan tepat untuk menggunakan bahasa Inggris saja, bukan?
Anton Barkovsky

9
@ Egor: Itulah alasan tim atau manajer proyek membuat aturan. Tetapi bukan alasan untuk bahasa atau implementasi untuk menegakkannya. Tim atau perusahaan selalu dapat memilih untuk membatasi pengidentifikasi lebih jauh - mereka tidak dapat memilih untuk memperluas set yang tersedia. Itu sebabnya set aslinya harus sebesar mungkin.
DeadMG

3
"Bagaimana kamu akan mengetik pengenal ASCII pada keyboard Cina?" - Persis sama seperti pada keyboard bahasa Inggris, sebenarnya. Anda memilih contoh yang buruk; Bahasa Cina (dan Jepang) biasanya dimasukkan sebagai huruf bahasa Inggris yang menggambarkan pelafalan, kemudian daftar bahasa Mandarin / Jepang yang cocok ditampilkan dari mana pengguna dapat memilih yang benar jika standarnya tidak benar (sistem modern menggunakan analisis konteks untuk memastikan bahwa itu biasanya).
Michael Borgwardt

2

Menurut PEP 3131 - Pendukung Non-ASCII tanggal 2007, bagian pertama dari Rationale menyatakan:

Kode python ditulis oleh banyak orang di dunia yang tidak terbiasa dengan bahasa Inggris, atau bahkan terbiasa dengan sistem penulisan Latin. Pengembang semacam itu sering ingin mendefinisikan kelas dan fungsi dengan nama-nama dalam bahasa asli mereka, daripada harus datang dengan terjemahan bahasa Inggris (sering salah) dari konsep yang ingin mereka beri nama. Dengan menggunakan pengidentifikasi dalam bahasa asli mereka, kejelasan kode dan pemeliharaan kode di antara penutur bahasa yang membaik.

Saya belum menyelidiki bahasa lain, tetapi itu harus menjadi salah satu alasan mereka menambahkan dukungan.


1

Itu akan benar-benar membuat hidup lebih mudah (bagi sebagian dari kita, bagaimanapun) jika kompiler tidak akan mendukung Unicode. Pengidentifikasi dari kanan ke kiri sangat buruk. Gabungan alfabet Romawi dan pengidentifikasi Unicode kanan-ke-kiri bahkan lebih buruk.

Hal buruk tentang non-dukungan adalah bahwa penyihir GUI tertentu mengambil teks yang Anda masukkan untuk item dan secara otomatis menggunakan teks itu sebagai pengidentifikasi item. Jadi apa yang akan mereka lakukan dengan teks Unicode pada item-item itu? Tidak ada jawaban yang mudah, saya takut.

Komentar Unicode dari kanan ke kiri juga bisa lucu. Misalnya, dalam VS 2010, komentar XML ditampilkan (dengan benar) sebagai RTL dalam kode ... tetapi ketika Anda menggunakan Intellisense untuk menarik pengidentifikasi di tempat lain dalam kode, tooltip menampilkan (salah) LTR. Lebih baik, mungkin, jika tidak ada dukungan sejak awal? Sekali lagi, bukan panggilan yang mudah.

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.