Mengapa pertanyaan "berikan lima hal yang Anda benci tentang C #" begitu sulit dijawab selama wawancara? [Tutup]


32

Dalam podcast 73 , Joel Spolsky dan Jeff Atwood mendiskusikan, di antara subyek lain, "lima hal yang setiap orang harus benci tentang bahasa pemrograman favorit mereka":

Jika Anda senang dengan rantai alat Anda saat ini, maka tidak ada alasan Anda perlu beralih. Namun, jika Anda tidak dapat membuat daftar lima hal yang Anda benci tentang bahasa pemrograman favorit Anda, maka saya berpendapat Anda belum cukup tahu untuk menilai. Ada baiknya untuk mengetahui alternatifnya, dan memiliki mata kritis yang sehat untuk apa pun yang Anda gunakan.

Karena penasaran, saya mengajukan pertanyaan ini kepada setiap kandidat yang saya wawancarai. Tak satu pun dari mereka yang dapat mengutip setidaknya satu hal yang mereka benci tentang C # ¹.

Mengapa? Apa yang begitu sulit dalam pertanyaan ini? Karena konteks wawancara yang penuh tekanan maka pertanyaan ini tidak mungkin dijawab oleh orang yang diwawancarai?

Apakah ada sesuatu tentang pertanyaan ini yang membuatnya buruk untuk wawancara?


Jelas, itu tidak berarti bahwa C # sempurna. Saya sendiri memiliki daftar lima hal yang saya benci tentang C #:

  • Kurangnya jumlah variabel jenis dalam obat generik (mirip dengan paramsargumen).
    Action<T>,
    Action<T1, T2>,
    Action<T1, T2, T3>,
          ⁞ Serius ?!
    Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>

  • Kurangnya dukungan untuk satuan ukuran, seperti dalam F #.

  • Kurangnya hanya baca properti. Menulis private readonlybidang dukungan setiap kali saya ingin properti hanya baca membosankan.

  • Kurangnya properti dengan nilai default. Dan ya, saya tahu bahwa saya dapat menginisialisasi mereka di konstruktor tanpa parameter dan memanggilnya dari semua konstruktor lainnya. Tapi saya tidak mau.

  • Warisan berganda. Ya, itu menyebabkan kebingungan dan Anda tidak memerlukannya dalam banyak kasus. Ini masih berguna dalam beberapa kasus (sangat jarang), dan kebingungan juga berlaku (dan dipecahkan dalam C #) untuk kelas yang mewarisi beberapa antarmuka yang berisi metode dengan nama yang sama.

Saya cukup yakin bahwa daftar ini jauh dari lengkap, dan ada lebih banyak poin yang perlu disoroti, dan terutama yang jauh lebih baik daripada milik saya.


¹ Beberapa orang mengkritik beberapa majelis dalam .NET Framework atau kurangnya beberapa perpustakaan dalam kerangka tersebut atau mengkritik CLR. Ini tidak masuk akal, karena pertanyaannya adalah tentang bahasa itu sendiri, dan sementara saya berpotensi menerima jawaban tentang sesuatu yang negatif dalam inti .NET Framework (misalnya sesuatu seperti fakta bahwa tidak ada antarmuka umum untuk TryParse, jadi jika Anda ingin mengurai string ke beberapa jenis, Anda harus mengulang sendiri untuk setiap jenis), jawaban tentang JSON atau WCF benar-benar di luar topik.


52
Why the question “give five things you hate about C#” is so difficult to answerKarena ini adalah daftar pertanyaan, dan seorang mod jahat akan menutupnya sebagai "tidak konstruktif" sebelum Anda mendapatkan kesempatan untuk menjawabnya ...; P
yannis

6
@Yannis Rizos: poin bagus. BTW, ketika mengetik pertanyaan ini dalam judul, Stack Overflow memperingatkan bahwa "Pertanyaan yang Anda ajukan tampak subyektif dan kemungkinan akan ditutup."
Arseni Mourzenko

5
Mungkin ruang penyimpanan otak Anda untuk hal-hal yang membenci bahasa pemrograman sebagian besar diisi dengan aspek-aspek dari bahasa lain yang harus Anda tangani.
whatsisname

9
Mungkin karena kebanyakan orang tidak membenci. Benci adalah kata yang cukup kuat bagi kebanyakan orang. Dilihat dari daftar item yang benar-benar sepele yang Anda "benci" tentang C #, saya benar-benar tidak ingin berada di dekat Anda ketika ada alasan untuk benar-benar membenci sesuatu. Saya menduga kepala Anda akan meledak. Saya juga curiga membuat daftar itu sulit bagi kebanyakan orang karena Anda harus benar-benar meregangkan untuk membuat daftar Anda dan Anda punya waktu berhari-hari untuk memikirkannya.
Dunk

19
Apakah Anda memperhatikan bahwa semua item dalam daftar Anda adalah tentang sesuatu yang hilang dan bukan sesuatu yang salah. Dalam pandangan saya Anda gagal menjawab pertanyaan wawancara. Setiap orang dapat membuat daftar fitur yang hilang dari bahasa dan menyatakannya sebagai alasan untuk membenci tetapi bahasa yang paling dibenci adalah yang memiliki semua fitur.
Stilgar

Jawaban:


42

Jika saya harus menebak:

  1. Beberapa programmer tidak memiliki eksposur bahasa yang beragam. Sulit untuk melihat ada yang salah dengan bahasa ketika Anda tidak tahu bahwa ada hal-hal yang lebih baik.

  2. Beberapa programmer hanyalah kode monyet. Mereka nyaris tidak menganalisis masalah di depan mereka, apalagi sesuatu seperti bagaimana bahasa pemrograman mereka bisa lebih baik.

  3. Hanya sedikit orang yang sangat kritis. Mereka melihat manfaat dan fitur, bukan kekurangan. Sulit bagi mereka untuk beralih ke cara berpikir seperti itu jika wawancara tidak berjalan seperti itu.

  4. Setidaknya di sekitar sini, bersikap terlalu kritis dipandang sebagai cacat kepribadian yang fatal. Alih-alih menjadi 'pengembang berwawasan luas yang selalu mencari cara yang lebih baik dalam melakukan sesuatu' (seperti beberapa area yang pernah saya jalani), mereka adalah 'bajingan yang membenci segalanya'. Bahkan orang-orang yang dapat memikirkan hal-hal yang mereka benci dalam bahasa itu mungkin akan menunda dalam sebuah wawancara untuk tampak kurang akrobat.


22
Sedangkan untuk nomor 2, kami lebih memilih Software Simians , Pak.
toniedzwiedz

@ Tom saya pikir itu pan programmatoribus .
Stefano Borini

9
@ Telastyn seharusnya tidak ada lima poin dalam jawaban Anda?
Ben Jackson

# 4 adalah apa yang terlintas di pikiran saya segera, terutama di lingkungan kerja yang berkomitmen untuk menggunakan C #. Mengingat wawancara umum dan saran perilaku di tempat kerja, ditanya hal ini dalam wawancara kerja mungkin tampak seperti umpan untuk menangkap "sikap buruk" yang mungkin membuat mereka tidak ingin mempekerjakan orang itu. Tidak seperti penuntutan hukum, dalam wawancara kerja jebakan tidak mungkin menjadi pembelaan yang efektif. ;-)
Dronz

35

Saya membayangkan pertanyaan itu sangat sulit dijawab selama wawancara karena:

  1. Benar-benar tak terduga,

  2. Membutuhkan banyak pemikiran, dan pemikiran dengan cara yang sangat berbeda dari yang digunakan saat wawancara,

  3. Sulit dijawab secara umum dalam waktu singkat (kecuali disiapkan sebelum wawancara).

1. Tidak terduga

Pertanyaan yang tidak terduga sangat sulit, terutama dalam konteks yang penuh tekanan. Bayangkan dialog berikut selama wawancara:

- Apa perbedaan antara HashSet<T>dan List<T>?
- Hashset dioptimalkan sedemikian rupa sehingga pencarian elemen sangat cepat. Misalnya jika Anda sering menggunakan set.Contains()dalam satu lingkaran, memindahkan setdaftar dari ke hashset dapat membuat segalanya lebih cepat.
- Bagaimana Anda membuat properti hanya baca?
- Saya menggunakan bidang yang ditandai sebagai readonlybidang dukungan untuk properti yang hanya memiliki pengambil.
- Apa gunanya sealed?
- Anda menggunakannya untuk kelas yang tidak boleh diwariskan.
- Apa yang terakhir kali Anda melihat dokter gigi?
- Apa?!

2. Ini membutuhkan banyak pemikiran yang berbeda

Ketika Anda ditanya pertanyaan tipe wawancara umum, Anda menggunakan ingatan Anda untuk mengingat kembali apa yang telah Anda pelajari dari buku atau dari praktik Anda tentang bahasa dan kerangka kerja. Anda mungkin berpikir sedikit untuk menemukan jawaban, tetapi tidak terlalu banyak.

Di sisi lain, pertanyaan tentang lima hal yang Anda benci memerlukan pemikiran yang lebih dalam. Anda tidak bisa hanya mengingat sesuatu yang telah Anda pelajari dari buku, dan Anda tidak dapat menemukan apa pun dengan analogi. Alih-alih bersikap pasif, Anda harus menjadi kritikus dan menemukan apa yang bisa tidak menyenangkan dalam bahasa yang Anda gunakan.

3. Membutuhkan waktu

Terus terang, saya punya daftar lima (sebenarnya lebih) hal yang saya benci tentang C #, tetapi saya memikirkannya dalam jangka waktu yang lama. Beberapa hal berasal dari era .NET Framework 2; sebagian besar masalah yang saya daftarkan untuk .NET Framework 2 tidak lagi valid karena telah dihapus, beberapa dengan LINQ dan semua hal pemrograman fungsional ini, yang lain dengan pemrograman dinamis. Saya tidak yakin apakah, tanpa menyiapkan pertanyaan ini, saya akan dapat menemukan semua lima elemen selama wawancara.


3
Saya pikir Anda secara umum benar, tetapi pemrograman dalam bahasa tertentu untuk waktu yang cukup hanya akan membuat Anda membenci 'kekhasan' tertentu. Seperti daftar sasaran. Atau setidaknya saya punya satu untuk setiap bahasa / platform yang pernah saya gunakan. Atau mungkin aku hanya manja dan pilih-pilih.
K.Steff

2
@ K.Steff: "Daftar-Hit" adalah nama yang sempurna untuk itu :). Saya pasti bisa memikirkan lebih dari lima masalah bahkan dengan platform favorit saya; jika Anda bertanya kepada saya tentang bahasa yang saya tidak suka tetapi telah dipaksa untuk menggunakan (misalnya Java atau Python) saya mungkin bisa berlangsung berjam-jam: P.
Tikhon Jelvis

1
Apakah Anda dapat dengan mudah mengingat hal-hal yang Anda benci dalam bahasa akan tergantung pada seberapa merepotkan 'kekhasan' relatif terhadap hal-hal lain yang harus Anda tangani. Sebagai contoh, sebagian besar pekerjaan saya melibatkan interaksi dengan sistem asing tertentu (dan khususnya mengerikan) dan API-nya. Kebanyakan mengeluh tentang C # /. NET pucat dibandingkan dan didorong ke belakang pikiran saya.
Dan Lyons

Sangat luar biasa bahwa Anda dapat melacak "daftar sasaran" untuk setiap bahasa / platform dan membawanya kemana-mana karena Anda telah memprogram dalam bahasa tertentu untuk "waktu yang cukup". Lalu ada orang lain yang tidak repot-repot membawa masalah-masalah itu setelah pemrograman untuk "cukup waktu". Apa yang orang lain lakukan adalah mencari solusi untuk masalah-masalah dalam daftar-hit mereka dan kemudian tidak perlu khawatir tentang masalah-daftar-hit lagi karena mereka membuatnya pergi. Jika cukup masalah untuk membawa daftar, maka mereka pasti berpikir itu cukup masalah untuk mengambil waktu untuk menyelesaikan sesuai dengan keinginan mereka.
Dunk

21

Saya pikir ini sulit karena kata lima . Dan pada tingkat yang lebih rendah, karena kata benci .

Lima ? Bagaimana jika Anda hanya menghasilkan empat? Apakah Anda gagal menjawab pertanyaan? Bagaimana jika Anda memiliki lebih dari lima? Sekarang, di tempat, Anda harus mencari tahu mana di antara mereka adalah lima terbaik untuk digunakan.

Benci adalah kata yang sangat negatif. Ini adalah jenis negatif yang diminta orang untuk dihindari dalam wawancara. Selain itu, saya pikir itu akan terdengar aneh untuk banyak orang untuk memiliki banyak hal yang mereka "benci" tentang bahasa mereka akan menghabiskan sepanjang hari pemrograman di Beberapa orang mungkin berpikir itu adalah pertanyaan jebakan. Jika mereka benar-benar tidak datang dengan lima hal, mereka akan didiskualifikasi karena membenci terlalu banyak C # untuk diprogram dengan baik. Sayangnya, pertanyaan tipuan tipuan seperti ini tidak pernah terdengar dalam wawancara.

Alih-alih, Anda bisa bertanya Apa yang akan Anda tingkatkan tentang C # jika itu terserah Anda? Ini memungkinkan orang yang diwawancarai untuk menjawab dengan sejumlah hal. Ungkapan ini juga memperdagangkan negatif kata "benci" untuk "peningkatan" yang relatif positif.


2
Poin Anda terhadap "lima" adalah hal yang baik - banyak orang mungkin akan memiliki rangkaian hal-hal yang mereka sukai dalam tingkat yang berbeda-beda, tetapi satu-satunya cara mereka dapat memutuskan hal-hal yang mewakili lima teratas adalah dengan memberi peringkat segala sesuatu yang mungkin dekat. Jika seseorang baru-baru ini mengalami masalah dengan sesuatu yang umumnya sedikit mengganggu, mereka mungkin harus berpikir sejenak untuk mencari tahu apakah itu benar-benar masuk dalam lima besar, atau jika baru saja terlintas dalam pikiran karena itu merupakan masalah baru-baru ini. Lebih lanjut, C # sangat terkait dengan .NET sehingga sulit untuk mengatakan apa yang harus disalahkan pada apa. Misalnya ...
supercat

1
... Saya berpendapat bahwa semua bahasa harus menjamin bahwa jika konstruktor melempar, objek yang dibangun sebagian akan mendapatkan Disposed, tetapi tidak ada persyaratan bahwa semua bahasa menerapkannya, orang dapat berpendapat bahwa bahasa yang melakukannya akan mengundang harapan yang salah. Dengan demikian mungkin tidak jelas apakah kesulitan menghindari kebocoran sumber daya pada kegagalan konstruktor C # harus disalahkan pada C # atau CLS.
supercat

14
  • Sebagian besar kandidat tidak terlalu terlibat dengan lebih dari satu bahasa atau paradigma untuk kontras . Saya belum pernah bekerja dengan bahasa berorientasi objek lain selama lebih dari 5 tahun sekarang, dan bahasa yang saya pakai (PowerBuilder), saya punya banyakkencing dengan. Kebanyakan pria yang baru lulus dari perguruan tinggi (atau mengira mereka) hot stuff di satu, mungkin dua bahasa, dan telah menerima "pemaparan" ke tiga atau empat lebih (artinya mereka menyelesaikan setidaknya satu tugas pekerjaan rumah yang membutuhkannya tetapi kurang dari satu semester penuh mempelajarinya). Itu tidak cukup pengetahuan atau pengalaman untuk benar-benar tahu apa yang salah dengan bahasa. Dapatkan pekerjaan di dunia nyata, dan fokus itu sangat menyempit; Anda belajar lebih banyak tentang bahasa yang memberi Anda gaji daripada yang lain, dan dalam prosesnya, Anda menerima apa yang tidak akan dilakukan, atau dilakukan dengan cara yang aneh, sampai pada titik di mana Anda tidak dapat mengingat melakukannya secara berbeda.

  • Kebanyakan kandidat C # -savvy yang membandingkannya dengan Java / C / C ++ cukup senang dengannya . C # dirancang dari bawah ke atas untuk melakukan banyak hal lebih baik daripada Java (acara, panggilan balik, perpustakaan grafik, pekerjaan basis data). Java pada gilirannya dirancang agar lebih mudah digunakan, dan jadi lebih fokus pada kode yang benar, daripada C ++. Saya belum pernah bertemu seorang programmer C # yang ingin kembali ke C ++ di lingkungan mana pun di mana kinerja yang melepuh dan kontrol level dekat-sirkuit bukan kebutuhan penting.

Dengan kata lain, See-Sharpers memilikinya cukup bagus, semua hal dipertimbangkan.

Inilah daftar saya:

  • Pernyataan Lambda tidak dapat ditonton / dievaluasi . Panggilan ke metode yang disebutkan bisa dicolokkan ke QuickWatch VS. Begitu juga ekspresi. Tapi lambda? Tidak (setidaknya tidak dalam VS2010). Menjadikan debugging Linq rantai tugas yang nyata.

  • Nilai parameter opsional untuk tipe referensi selain string hanya bisa nol . jika saya membuat overload stack, saya mungkin ingin menggunakan default lain. Saya mungkin dapat default satu nilai berdasarkan properti atau ekspresi sederhana berdasarkan parameter lain. Tetapi saya tidak bisa. Jadi nilai tidak harus membuat tumpukan kelebihan (yang kecil dengan asisten refactoring seperti ReSharper untuk menangani platplate) berkurang ketika opsi untuk parameter opsional sangat terbatas secara drastis.

  • C # menjadi cukup tua untuk memiliki masalah kode warisan yang serius . Kode yang awalnya ditulis untuk 1.1 akan menyebabkan siapa pun yang terbiasa dengan 4.0 merasa ngeri. Bahkan kode 2.0 sering gagal. Pada saat yang sama, perpustakaan pihak ketiga telah hadir yang membuat hal-hal seperti ADO.NET tampak sangat primitif (dan banyak "model terhubung" ADO.NET sekarang merupakan anti-pola yang besar). Namun, untuk kompatibilitas ke belakang, .NET schleps mendukung semua kode lama dan buruk ini, tidak pernah berani mengatakan sesuatu seperti "ArrayList adalah cara jelek untuk melakukannya, kami minta maaf kami pernah memasukkannya dan kami menerima keluar, gunakan Daftar saja dan jika Anda benar-benar membutuhkan daftar jenis yang berbeda, nyatakan sebagai List<Object>.

  • Aturan pergantian pernyataan yang sangat terbatas . Mungkin salah satu hal terbaik yang bisa saya katakan tentang PowerBuilder adalah bahwa pernyataan Choose Case (setara dengan switch) memungkinkan ekspresi Boolean berdasarkan variabel. Itu juga memungkinkan pergantian pernyataan untuk jatuh bahkan jika mereka memiliki kode. Saya mengerti alasan mengapa yang kedua itu dianulir (itu lebih mungkin dilakukan tanpa sengaja daripada sengaja) tetapi akan lebih baik dari waktu ke waktu untuk menulis pernyataan seperti:

    switch(someInt)
    {
        case < 0: //all negative values enter here
           //...
           break;
        case 0: 
           //...
           break;
        case 1:
           //...
           //no break; continue through to the code for > 1
        case > 1 // all positive values enter here (including 1)
           //...
           break;
    }
  • Tidak ada antarmuka INumerik . Jika angka, Anda bisa berhitung dengan itu. Dalam banyak kasus, metode yang sebenarnya tidak harus peduli dengan tipe mana yang dicolokkan; ketepatan adalah tanggung jawab penelepon. Namun tidak mungkin untuk membuat metode atau kelas umum yang hanya dapat menerima tipe angka sebagai GTP.

3
"Kebanyakan kandidat C # -savvy yang membandingkannya dengan Java / C / C ++ cukup senang dengannya". Ini adalah pemikiran saya. Tidak banyak yang dibenci tentang C # karena memungkinkan Anda fokus pada solusi untuk masalah bisnis daripada solusi untuk masalah teknis. Keluhan terbesar yang saya miliki dengan bahasa adalah bahwa saya tidak dapat menggunakan string sumber daya dalam tes kasus beralih karena mereka secara teknis variabel dan bukan konstanta.
Stephen

4
Bit pada generik dan wadah - Contoh yang berguna dengan super dan ketidakjelasan dengan meluas di Generics? menjelaskannya sedikit. Menugaskan Bag<Fruit> bag = Bag<Huckleberry>berarti Anda bisa melakukan bag.add(new Watermelon())yang tidak dapat menahannya.

4
+1 untuk No Inumeric. Jarang, tapi menjengkelkan.
jmoreno

Misalkan Thing<out T>memiliki bidang statis yang diakses oleh metode instance dan metode statis. Jika a Thing<Cat>diteruskan ke metode yang mengharapkan a Thing<Animal>, dan metode itu memanggil instance dan metode statis yang disebutkan di atas Thing<Animal>, bidang statis manakah yang harus diakses oleh metode tersebut?
supercat

11

Saya menyarankan bahwa bagian dari masalahnya adalah takut memberikan jawaban yang buruk - Anda mengatakan Anda membenci X, pewawancara mencintai X atau berpikir bahwa alasan Anda membenci X adalah idiot, mengatakan bahwa Anda pikir itu boleh saja tampaknya merupakan pilihan yang kurang kontroversial.

Mungkin juga sesuatu yang belum dipikirkan oleh kebanyakan orang; mereka memiliki masalah saat ini dan masalah masa lalu, masalah masa lalu yang disebabkan oleh langauge sudah selesai dan orang-orang terutama memikirkan solusinya dan bukan masalah karena itu lebih penting, dan sedikit yang akan memiliki masalah saat ini yang disebabkan oleh bahasa.


7

Untuk wawancara saya hanya akan meminta 1 atau 2, tetapi saya setuju, jika Anda tidak dapat menyebutkan batasan alat yang Anda gunakan, maka Anda mungkin tidak mengetahuinya dengan baik. Kami mengajukan pertanyaan yang tepat tentang SSIS dan ini benar-benar membantu memisahkan gandum dari sekam; setiap orang yang kami pekerjakan yang menjawab pertanyaan ini dengan baik berubah menjadi karyawan yang hebat. Kami membutuhkan orang-orang yang memiliki pengetahuan tingkat lanjut bukan seseorang yang telah melihatnya beberapa kali. Dan saya bertaruh itulah yang Anda inginkan juga.

Saya pikir ini adalah pertanyaan yang valid dan fakta bahwa begitu banyak yang tidak bisa menjawabnya hanyalah sebuah contoh seberapa buruk banyak dari kandidat untuk pekerjaan itu sebenarnya. Jika seseorang tidak cukup analitis untuk dapat mengetahui beberapa keterbatasan alat, bagaimana mereka akan menjadi cukup analitis untuk menyelesaikan masalah pemrograman yang sulit?


1
+1 Five menakutkan, karena alasan ini 1 atau 2 mungkin akan mendapatkan lebih banyak jawaban.
Laurent Couvidou

2
Benci sangat berbeda dari batasan ......
mattnz

4

Itu turun seperti Anda mengatakan kurangnya pengalaman mendalam dengan C # dan / atau kurangnya paparan ke bahasa lain. Saya telah mewawancarai sejumlah pengembang yang menganggap diri mereka senior yang tidak dapat menjawab beberapa pertanyaan yang bahkan harus diungkapkan oleh goresan ringan di permukaan C # kepada mereka.

Tanpa menggali cukup, Anda tidak akan mencapai batas bahasa dan berharap bahwa mereka pergi. Lima besar saya kalau-kalau ada yang bertanya-tanya

  1. Objek yang tidak dapat diubah membutuhkan banyak upacara untuk dibuat (sebagai lawan dari bahasa fungsional di mana objek tidak dapat diubah secara default).
  2. Pemrograman ulang sulit dilakukan. Bandingkan tipe emit dengan macro Lisp. (Layanan Kompiler akan banyak membantu dalam hal ini ke depan).
  3. Metode penyuluhan hebat ... properti ekstensi dan operator ekstensi (khususnya operator implisit dan eksplisit) akan lebih baik.
  4. Pemain Eksplisit diselesaikan pada waktu kompilasi alih-alih run-time.
  5. No Sequence Matching jauh lebih bersih daripada fungsi yang berlebihan.

Saya setuju dengan dua poin pertama Anda, tetapi saya ngeri dengan gagasan konversi implisit ekstensi.
CodesInChaos

3

Saya berpikir tentang apa yang dia katakan; Jika Anda pikir itu rusak, Anda mungkin tidak mengerti mengapa hal itu terjadi. Mungkin ada lubang dalam pengetahuan Anda.

Ironisnya, pewawancara yang berpikir mereka mengutip "Joel besar" dengan menggunakan itu sebagai pertanyaan wawancara mungkin agak tidak penting.


Saya berpendapat ini tidak selalu terjadi. Contohnya, Douglas Crockford mengatakan dalam "JavaScript: The Good Parts" bahwa Anda harus menghindari fitur-fitur tertentu dari bahasa tersebut, dan saya tidak berpikir maksudnya mereka 'terlalu hardcore' untuk digunakan.
K.Steff

10
Saya pikir dia mengatakan sebaliknya - jika Anda berpikir platform sama sekali tidak rusak, Anda tidak cukup tahu. Maksudnya, intinya adalah tidak apa-apa menempel satu platform selama Anda tidak buta akan kekurangannya.
Tikhon Jelvis

3

Mereka mungkin enggan menjawab karena mereka mungkin berada di bawah kesan bahwa jika mereka dapat membuat daftar 5 hal yang mereka benci tentang bahasa pewawancara mungkin berbalik dan berkata 'Oh, kami sedang mencari C #' ninja 'dan Anda tampaknya tidak untuk menyukai bahasa ', atau' Mengapa Anda melamar pekerjaan jika Anda tidak menyukai bahasa itu? '.

Orang yang diwawancarai berada di bawah banyak tekanan untuk tetap positif selama wawancara.


jika saya membenci sesuatu dalam suatu bahasa, itu tidak berarti saya membenci bahasa itu. Pertanyaan ini <del> dapat </del> harus dijawab dengan cara yang positif juga. Mengapa kita perlu HTML5 jika kita tidak membenci apa pun di HTML4? :)
e-MEE

3

Karena bahasa membentuk cara kita berpikir . Dengan menggunakan C # setiap hari, Anda telah terbiasa berpikir dan merancang kode Anda dengan cara yang secara alami mengatasi masalah bahasa.

Anda sekarang melakukannya tanpa berpikir, bahkan tanpa mengetahui bahwa Anda melakukannya. Inilah mengapa sangat sulit untuk menunjukkan apa hal-hal buruk itu. Tidak diragukan lagi bahwa hari ketika Anda mulai belajar C #, Anda menemukan banyak masalah, tetapi sekarang Anda tidak melihatnya lagi. Kebiasaan adalah hal yang kuat. Kebiasaan berpikir, bahkan lebih .

Sisi positif dari ini adalah, jika Anda merasa sulit untuk membuat daftar kekurangan dalam C #, itu pasti karena Anda adalah programmer C # yang baik, Anda menyukai bahasa, dan menggunakannya lebih dari bahasa lain.

Tetapi jika Anda ingin menjadi lebih mampu melihat kekurangan dalam C #, Anda harus mengubah cara berpikir Anda. Pelajari lebih lanjut bahasa pemrograman , dan biasakan mereka. Bertujuan untuk bahasa yang paling berbeda. Anda terbiasa mengetik statis? Coba Python atau Ruby. Anda terbiasa berorientasi objek dan imperatif? Haskell adalah dunia lain sepenuhnya.

Dan ketika Anda kembali ke C #, Anda akan seperti, "Mengapa saya perlu seratus baris C # untuk melakukan hal sederhana ini yang hanya satu baris di Haskell?". Anda akan membenci banyak hal tentang C #.

  • C # tidak memiliki tipe referensi yang tidak dapat dibatalkan.
  • Tidak ada tipe data aljabar.
  • Tidak ada interpolasi string.
  • Sintaksinya terlalu bertele-tele di mana-mana.
  • Tidak ada sistem makro.
  • Jenis inferensi terbatas.
  • Tidak ada literal regexp.
  • Tidak ada pengetikan struktural.
  • Dukungan yang buruk untuk kekekalan.
  • C # structs rawan kesalahan.
  • Perpustakaan koleksi standar sangat terbatas.
  • Tidak dapat menentukan batasan pada parameter konstruktor.
  • Tidak dapat memprogram secara umum dengan kendala pada operator matematika.
  • Tidak ada 'tipe baru'.
  • Tidak ada irisan array, tidak ada rentang literal.
  • Fungsi tidak mencantumkan efek samping yang dapat mereka lakukan sebagai bagian dari tipenya. :)

(Tentu saja tidak ada bahasa yang dapat memiliki segalanya. Desain bahasa sangat sulit, dan menambahkan setiap fitur ke dalam bahasa yang sama tidak dapat berfungsi. Alat yang berbeda untuk tujuan yang berbeda.)

Ya, pertanyaan itu sulit dijawab dengan baik, terutama saat wawancara. Tetapi orang-orang yang dapat menjawabnya membuktikan bahwa mereka telah memikirkannya, bahwa mereka memiliki beberapa perspektif.


+1. Poin luar biasa. Memang, banyak hal yang sebenarnya saya benci di C # berasal dari kenyataan bahwa bahasa lain tidak memiliki kelemahan yang sama. Kurangnya tupel nyata (yaitu ketidakmungkinan untuk melakukan (a, b) = this.something();seperti di Python) adalah hal pertama yang terlintas di pikiran saya.
Arseni Mourzenko
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.