Apakah Linq memiliki efek mematikan pikiran pada programmer NET?

36

Banyak dari kita mulai melihat fenomena ini dengan jQuery sekitar setahun yang lalu ketika orang-orang mulai bertanya bagaimana melakukan hal-hal yang benar-benar gila seperti mengambil string kueri dengan jQuery . Perbedaan antara perpustakaan (jQuery) dan bahasa (JavaScript) tampaknya hilang pada banyak programmer, dan menghasilkan banyak kode yang tidak tepat dan berbelit-belit yang ditulis di tempat yang tidak perlu.

Mungkin itu hanya imajinasiku, tapi aku bersumpah aku mulai melihat uptick dalam sejumlah pertanyaan di mana orang-orang meminta untuk melakukan hal-hal gila yang sama dengan Linq, seperti menemukan rentang dalam array yang diurutkan . Saya tidak bisa melupakan betapa tidak pantasnya ekstensi Linq untuk menyelesaikan masalah itu, tetapi yang lebih penting adalah kenyataan bahwa penulis hanya berasumsi bahwa solusi ideal akan melibatkan Linq tanpa benar-benar memikirkannya (sejauh yang saya tahu). Tampaknya kita mengulangi sejarah, membiakkan generasi baru .NET programmer yang tidak dapat membedakan antara bahasa (C # / VB.NET) dan perpustakaan (Linq).

Apa yang bertanggung jawab atas fenomena ini? Apakah ini hanya hype? Kecenderungan murai? Apakah Linq mendapatkan reputasi sebagai bentuk sihir, di mana alih-alih menulis kode, Anda hanya perlu mengucapkan mantra yang benar? Saya hampir tidak puas dengan penjelasan itu tetapi saya tidak bisa memikirkan hal lain.

Lebih penting lagi, apakah itu benar-benar masalah, dan jika demikian, apa cara terbaik untuk membantu mencerahkan orang-orang ini?

programming-practices .net

— Aaronaught
sumber

6

+1 untuk "mengasumsikan bahwa solusi ideal akan melibatkan Linq tanpa benar-benar memikirkannya". Ini benar-benar di luar jangkauan saya.

— Jaco Pretorius

1

Linq lambat ...

2

@Pierre: Atas dasar apa Anda membuat klaim itu?

— Aaronaught

5

@ Alasan: Itu adalah tolok ukur yang benar-benar mengerikan yang ditulis oleh seseorang yang jelas tidak tahu apa yang mereka lakukan. Benchmarking dalam ticks? Notasi Hungaria? Dan versi Linq bahkan tidak melakukan hal yang sama, ia mencoba untuk mengulangi setiap hasil bukannya berhenti pada yang pertama. Belum lagi, seluruh premis itu konyol, seperti yang secara tidak sengaja dibahas dalam pertanyaan panas hari ini .

— Aaronaught

3

Dan, kebetulan @Mason, Linq memiliki banyak optimisasi bawaan . Untuk hampir semua metode yang mampu dioptimalkan, pertama-tama mencari antarmuka yang mendukung metode yang dioptimalkan. Untuk metode berbasis set lainnya seperti equijoins, ia menciptakan tabel hash. Itu tidak mengoptimalkan kode Anda untuk Anda tetapi itu tidak akan membuat kode Anda lebih lambat juga; sebagian besar pelambatan dunia nyata yang terdokumentasi sebenarnya disebabkan oleh lambdas / penutupan yang tidak tergantung pada Linq.

— Aaronaught

52

Ini pada dasarnya karena pemrograman pada dasarnya sulit. Dibutuhkan banyak pemikiran logis dan terstruktur sedemikian rupa sehingga banyak orang tidak tahu bagaimana melakukannya. (Atau tidak bisa melakukannya, tergantung pada siapa yang Anda dengarkan.)

Hal-hal seperti LINQ dan jQuery membuat tugas manipulasi data umum tertentu jauh lebih mudah. Itu bagus untuk kita yang tahu apa yang kita lakukan, tetapi efek samping yang disayangkan adalah efeknya menurunkan standar. Itu membuatnya lebih mudah bagi orang-orang yang tidak tahu apa yang mereka lakukan untuk mulai menulis kode dan membuat semuanya berfungsi. Dan kemudian ketika mereka bertemu dengan kenyataan, dan menemukan sesuatu yang secara fundamental sulit sehingga teknik tingkat abstraksi sederhana dan tinggi mereka tidak cocok untuk itu, mereka hilang, karena mereka tidak memahami platform yang menjadi dasar perpustakaan mereka dibangun.

Pertanyaan Anda agak di jalur yang benar, tetapi seperti kontroversi abadi tentang video game kekerasan "mengubah anak-anak kekerasan," itu memiliki arah tautan ke belakang. Teknik pemrograman yang mudah tidak membuat programmer bodoh; mereka hanya menarik orang-orang bodoh ke pemrograman. Dan benar-benar tidak banyak yang dapat Anda lakukan.

— Mason Wheeler
sumber

30

+1 untuk "Teknik pemrograman yang mudah tidak membuat programmer bodoh; mereka hanya menarik orang bodoh ke pemrograman."

— Steven Evers

1

Satu hal hebat tentang LINQ adalah memungkinkan saya untuk membuat prototipe solusi dalam pendekatan fungsional. Kemudian setelah saya memiliki solusi bebas bug saya dapat menggunakannya sebagai bangku tes untuk versi imperatif yang dioptimalkan. Jika tugasnya cukup sederhana seperti menerapkan filter tunggal saya bahkan tidak akan repot.

— ChaosPandion

5

Saya masih ragu bahwa LINQ menarik programmer tidak kompeten - dari apa yang saya lihat, tampaknya menjadi salah satu konsep yang paling sulit dipahami pemula - tetapi, ini tampaknya menjadi jawaban terbaik sejauh ini.

— Aaronaught

1

Anda harus memberi hak cipta pada kalimat terakhir itu. Kata baik, tuan.

— AJ Johnson

1

Lucu. Bagi saya, LINQ bukan konsep yang mudah dikuasai. Jika Anda melakukan sesuatu yang subtant, sangat cepat Anda harus berhenti memikirkan kemudi dan mulai memahami transmisi. Saya melihat Anda, para lama!

— Brian MacKay

13

Bagi saya itu adalah fenomena mainan baru. Sesuatu yang baru keluar (LINQ) dan sekarang setiap pengembang ingin bermain dengannya.

Mereka melihat LINQ sebagai palu dan setiap masalah adalah paku. Siapa yang peduli jika lebih mudah melakukannya dengan cara lain? LINQ harus menjadi jawabannya! Seperti ketika semua orang menggunakan XML untuk SEMUANYA! File konfigurasi? XML Menyimpan Data? XML Dll

— PSU_Kardi
sumber

5

Tidak ingin memulai debat XML di sini, tetapi perlu menunjukkan bahwa XML sebenarnya bagus dalam kedua hal itu. Ini tidak selalu optimal - jika file konfigurasi tidak perlu terstruktur maka KVP lebih baik, dan jika kompatibilitas lintas-aplikasi bukan persyaratan maka format biner jelas lebih baik untuk penyimpanan / serialisasi. Tapi saya tidak berpikir XML adalah contoh yang bagus karena ia cenderung menemukan dirinya digunakan di daerah-daerah di mana itu hanya sub-optimal dibandingkan dengan benar-benar tidak pantas.

— Aaronaught

4

+1: Layak untuk merentangkan alat Anda untuk melihat berapa banyak masalah yang bisa ditumbuk ke dalam bentuk paku ketika Anda belajar teknologi.

— Steven Evers

+1: Contoh lain dari palu ajaib ini adalah jQuery (sebagaimana disebutkan dalam pertanyaan) dan ekspresi reguler. Bukannya hal-hal ini buruk, sebenarnya mereka benar-benar berguna, tetapi mereka bukan jawaban untuk semuanya.

— Tim Goodman

14

Saya pikir analogi "LINQ adalah palu dan setiap masalah adalah paku" mendorongnya agak terlalu jauh. Saya akan mengatakan LINQ adalah palu yang baik sehingga ketika sebagian besar pekerjaan Anda melibatkan paku, Anda dapat masuk ke alur dan tidak melihat bahwa Anda hanya memalu sekrup. Bahkan jika Anda bukan programmer yang buruk.

— Carson63000

@Aronaught: Di sisi lain, penggunaan XML dengan nama bidang yang panjang tampaknya kurang optimal bagi saya untuk transmisi data melalui bandwidth rendah dan tidak sepenuhnya dapat diandalkan tautan radio. Kemudian lagi, itu juga yang saya pikirkan tentang desain database pada produk itu.

— David Thornley

10

Saya pikir LINQ menawarkan peluang yang sangat bagus dalam C # untuk menyelesaikan masalah menggunakan pendekatan yang lebih fungsional. Kita tidak boleh mengabaikan gaya baru pemecahan masalah hanya karena kita sudah memiliki sesuatu yang berhasil.

Berasal dari latar belakang SQL yang berat, saya suka memiliki opsi untuk menggunakan logika berbasis set di C # saya untuk lebih menggambarkan maksud operasi saya.

Yang mengatakan; konteks adalah raja, dan apa pun bisa digunakan secara berlebihan.

— dotjosh
sumber

Siapa yang memberhentikan? Saya menggunakan Linq sepanjang waktu, saya hanya khawatir tentang jumlah insiden yang saya lihat dari orang yang menggunakannya (atau mencoba menggunakannya) untuk masalah yang jelas berulang dan tidak berbasis-set.

— Aaronaught

Saya sangat terbiasa untuk mencoba memecahkan masalah yang telah diminta untuk ditulis dalam SQL, dan menggunakan set-based logic daripada cursor untuk melakukannya. Penyalahgunaan alat akan selalu terjadi, tetapi saya kira setidaknya jika mereka menulis kode LINQ yang buruk alih-alih kode prosedural yang buruk, versi berikutnya. NET akan lebih mudah setidaknya dapat memparalelkannya.

— dotjosh

2

LINQ dan jQuery adalah "mainan" terbaru dan pengembang senang memamerkan bagaimana mereka dapat melakukan hal-hal menggunakan hal-hal terbaru.

— Dan Diplo
sumber

Saya setuju dengan pernyataan ini. Saya tidak begitu yakin apakah ini menjelaskan fenomena khusus ini. Orang-orang yang mengajukan pertanyaan-pertanyaan ini tampaknya bukan tipe pamer - walaupun itu akan membantu menjelaskan mengapa programmer lain mencoba menjawab pertanyaan seperti yang diajukan alih-alih menganjurkan pendekatan yang lebih waras.

— Aaronaught

@Aonaonaught - Ya, saya kira saya lebih memikirkan mengapa orang menjawab dengan pertanyaan menggunakan pendekatan ini.

— Dan Diplo

2

Jika Anda menggunakan Linq dengan benar, dan memahaminya di bawah tenda, Anda akan menemukan segala macam teknik pemrograman mutakhir.

Jadi jika Anda berpikir mendalam tentang perangkat tambahan, saya berpendapat bahwa itu membuat Anda seorang programmer yang lebih baik. Apakah programmer yang diberikan benar-benar melakukan ini atau tidak, itu bukan kesalahan Linq.

Argumen yang sama dapat dibuat untuk Object-Relational Mappers. Apakah ada yang benar-benar menulis query SQL mentah terhadap tabel database lagi? :)

— Robert Harvey
sumber

10

Hai, saya menulis SQL mentah ... sniff

— Aaronaught

2

SQL mentah adalah pilihan terbaik jika Anda tahu apa yang Anda lakukan.

— Fosco

1

+1 untuk argumen "menjadikan Anda programmer yang lebih baik". Memahami LINQ dan terutama metode yang mendukungnya telah meningkatkan pemahaman saya tentang beberapa konsep pemrograman yang sangat membantu.

— John M Gant

1

Saya pikir seseorang tersinggung ORM vs komentar SQL mentah. Bukan aku; Saya menggunakan keduanya, dan saya memahami ucapan itu sebagai bahasa yang sederhana.

— Aaronaught

1

Saya tidak akan pernah mempercayai permintaan basis data saya yang rumit pada omong kosong yang ditulis ORM, Tidak masalah untuk hal-hal sederhana, tetapi ugh untuk melaporkan pertanyaan jenis. Sekali lagi, di tangan seseorang yang tahu apa yang mereka lakukan, ORM adalah hal yang baik, di tangan seseorang yang terlalu malas untuk memahami database, malapetaka di depan.

— HLGEM

1

Beberapa hal gila itu adalah karena orang menggunakan palu yang salah, yang lain karena mereka sedang membangun palu super yang sangat elegan, tetapi mereka telah mengalami detail aneh yang perlu diatasi.

Sebagai contoh, jika Anda melihat pertanyaan tentang menggunakan LINQ untuk menghasilkan LINQ dinamis untuk digunakan terhadap LINQ non-dinamis sembilan dari sepuluh orang itu hanya ingin tahu apakah mungkin, atau menggonggong pohon yang salah, tetapi ada beberapa hal-hal yang dapat Anda pecahkan dengan cara ini yang sulit hingga tidak masuk akal untuk dipecahkan.

Saya mengambil pertanyaan-pertanyaan semacam ini dalam dua bagian:

dapatkah itu dilakukan, dan jika demikian seperti apa bentuknya
harus dilakukan, apakah ada risiko, atau alternatif yang lebih baik

Saya telah menemukan bahwa saya hampir selalu melakukannya dalam urutan itu. Ini menjawab pertanyaan dan juga membantu Anda membuat penjelasan yang lebih baik untuk alternatif potensial.

— Tagihan
sumber

0

Saya tidak tahu tentang efek mati rasa pada pikiran pengembang, tetapi lihat di sini untuk efek alat / bahasa yang berpikiran kosong pada tarif. Bicara tentang menurunkan bilah!

— Pete Wilson
sumber

0

Saya setuju dengan Mason Wheeler. Namun, tidak sepenuhnya gila untuk mencoba menyelesaikan https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq dengan mengoperasikan "urutan". Masalahnya adalah iterator Java dan .Net tidak mendukung semua 3 operasi: nilai saat ini, nilai berikutnya, dan pindah ke berikutnya. Clojure dapat melakukan semua 3, dan saya menduga bahwa di Clojure lebih mudah untuk melakukan ini dengan benar. Python juga memiliki co-rutin, dan saya ingin mencoba memecahkannya. http://clojure.org/ berikutnyaences http://www.try-clojure.org/

Bahkan, jika inputnya adalah urutan yang tak terbatas, seperti http://oeis.org/A007401 , maka malas adalah satu-satunya cara.

— Pekerjaan
sumber

"Linq" tidak berarti "iterator" atau "malas" tentu saja - pada kenyataannya, sebagian besar Linq benar-benar tentang pohon ekspresi. Anda dapat dengan mudah, jika Anda mau, mengimplementasikan agregat 3-nilai atau N-nilai Anda sendiri dengan penutupan dan tidak terlalu banyak kode sama sekali dalam C #. Masalahnya muncul ketika orang tidak tahu bagaimana cara melakukan itu, atau bahkan bagaimana memulainya, dan hanya mencari mantra sihir yang hidup di System.Linqnamespace.

— Aaronaught

@Aaronaught ... '' '"Linq" tidak berarti "iterators" atau "lazy" tentu saja' '' - yah, Linq dapat terlihat seperti SQL tetapi gula sintaksis ini mengkompilasi menjadi kode IL yang sebenarnya, yang, jika tidak dikompilasi , akan terlihat setara dengan sekelompok IEnumerable [<T>] yang dihubungkan bersama. Barang-barang itu malas dan menggunakan enumerator, yang dalam bahasa lain disebut iterator. Tapi ya, masalahnya adalah bahwa LINQ membuat pengkodean terlihat mudah, dan yang tidak memenuhi syarat mencobanya. Beberapa mungkin masih bisa menjadi programmer yang layak. Jika C # adalah bahasa pertama mereka dan mereka adalah noobs total, maka mereka berhadapan dengan bahasa yang besar.

— Pekerjaan

Tentu, Linq to Objects (bukan Linq to SQL, Linq to Entities, Linq to DataSet atau cabang Linq lainnya) didasarkan pada iterator dan eksekusi yang ditangguhkan, tapi itu semua di bawah tenda. Iterator memblokir dan yieldpernyataan itu ada sebelum Linq, seperti halnya delegasi. Penutupan datang dalam rilis yang sama dengan Linq, tetapi beberapa operasi "Linq" murni sebenarnya membutuhkan tangkapan variabel lokal. Bertanya "Bagaimana saya bisa melakukan [deskripsi operasi / fungsi sepenuhnya iteratif] dengan Linq?" mengkhianati ketidaktahuan yang mendalam dari kedua Linq itu sendiri (apa artinya itu harus dilakukan) dan bahasa itu sendiri.

— Aaronaught