Linq có ảnh hưởng đến các lập trình viên .NET không?

Rất nhiều người trong chúng ta bắt đầu thấy hiện tượng này với jQuery khoảng một năm trước khi mọi người bắt đầu hỏi làm thế nào để thực hiện những điều hoàn toàn điên rồ như lấy chuỗi truy vấn bằng jQuery . Sự khác biệt giữa thư viện (jQuery) và ngôn ngữ (JavaScript) rõ ràng đã bị mất đối với nhiều lập trình viên và dẫn đến rất nhiều mã không phù hợp, phức tạp được viết khi không cần thiết.

Có lẽ đó chỉ là trí tưởng tượng của tôi, nhưng tôi thề là tôi bắt đầu thấy sự gia tăng số lượng câu hỏi mà mọi người đang yêu cầu làm những điều điên rồ tương tự với Linq, như tìm phạm vi trong một mảng được sắp xếp . Tôi không thể biết được các phần mở rộng Linq không phù hợp đến mức nào để giải quyết vấn đề đó, nhưng quan trọng hơn là tác giả chỉ cho rằng giải pháp lý tưởng sẽ liên quan đến Linq mà không thực sự nghĩ về nó (theo như tôi có thể nói). Dường như chúng ta đang lặp lại lịch sử, tạo ra một thế hệ lập trình viên .NET mới, những người không thể nói được sự khác biệt giữa ngôn ngữ (C # / VB.NET) và thư viện (Linq).

Điều gì chịu trách nhiệm cho hiện tượng này? Có phải chỉ là cường điệu? Xu hướng Magpie? Linq có nổi tiếng là một dạng phép thuật không, thay vì thực sự viết mã, bạn chỉ cần phải thốt ra câu thần chú đúng? Tôi hầu như không hài lòng với những lời giải thích đó nhưng tôi thực sự không thể nghĩ gì khác.

Quan trọng hơn, nó có thực sự là một vấn đề không, và nếu vậy, cách tốt nhất để giúp soi sáng cho những người này là gì?

Về cơ bản là vì lập trình rất khó. Nó đòi hỏi rất nhiều suy nghĩ hợp lý, có cấu trúc theo cách mà nhiều người không biết làm. (Hoặc đơn giản là không thể làm, tùy thuộc vào người bạn nghe.)

Những thứ như LINQ và jQuery làm cho một số tác vụ thao tác dữ liệu phổ biến dễ dàng hơn rất nhiều. Điều đó thật tuyệt vời cho những người trong chúng ta biết những gì chúng ta đang làm, nhưng tác dụng phụ đáng tiếc là nó làm giảm thanh. Nó giúp dễ dàng hơn cho những người không biết họ đang làm gì để bắt đầu viết mã và làm cho mọi thứ hoạt động. Và sau đó khi họ chạy vào thực tế và thấy một điều khó khăn cơ bản là các kỹ thuật đơn giản, mức độ trừu tượng cao của họ không phù hợp lắm, họ đã lạc lối, vì họ không hiểu nền tảng mà thư viện của họ được xây dựng.

Câu hỏi của bạn được sắp xếp đúng hướng, nhưng giống như cuộc tranh cãi lâu năm về các trò chơi video bạo lực "biến trẻ em thành bạo lực", nó có hướng liên kết ngược. Kỹ thuật lập trình dễ dàng không làm cho lập trình viên trở nên ngu ngốc; họ chỉ thu hút những người ngu ngốc để lập trình. Và thực sự không có nhiều bạn có thể làm về nó.

Đối với tôi đó là hiện tượng đồ chơi mới. Một cái gì đó mới xuất hiện (LINQ) và bây giờ mọi nhà phát triển đều muốn chơi với nó.

Họ coi LINQ như một cái búa và mọi vấn đề là một cái đinh. Ai quan tâm nếu nó đơn giản hơn để làm điều đó theo cách khác? LINQ phải là câu trả lời! Giống như khi mọi người đang sử dụng XML cho MỌI THỨ! Tập tin cấu hình? XML. Lưu trữ dữ liệu? XML. Vân vân

Tôi nghĩ LINQ cung cấp một cơ hội thực sự tốt trong C # trong việc giải quyết các vấn đề bằng cách sử dụng một cách tiếp cận chức năng hơn. Chúng ta không nên loại bỏ một phong cách giải quyết vấn đề mới chỉ vì chúng ta đã có một cái gì đó hoạt động.

Xuất phát từ một nền tảng SQL nặng nề, tôi thích có tùy chọn sử dụng logic dựa trên tập hợp trong C # của mình để mô tả rõ hơn ý định hoạt động của tôi.

Mà nói; bối cảnh là vua, và bất cứ điều gì có thể được sử dụng quá mức.

LINQ và jQuery là "đồ chơi" mới nhất và các nhà phát triển thích thể hiện cách họ có thể làm mọi thứ bằng cách sử dụng thứ mới nhất.

Nếu bạn sử dụng Linq đúng cách và hiểu nó dưới mui xe, bạn sẽ tìm thấy tất cả các loại kỹ thuật lập trình tiên tiến mới.

Vì vậy, nếu bạn suy nghĩ sâu sắc về các cải tiến, tôi lập luận rằng nó làm cho bạn trở thành một lập trình viên tốt hơn. Cho dù một lập trình viên nhất định có thực sự làm điều này hay không, đó không phải là lỗi của Linq.

Lập luận tương tự có thể được đưa ra cho các Mappers quan hệ đối tượng. Có ai thực sự viết các truy vấn SQL thô đối với các bảng cơ sở dữ liệu nữa không? :)

Một số trong những điều điên rồ đó là do mọi người đang sử dụng búa sai, những người khác là vì họ đang chế tạo một siêu búa thực sự thanh lịch, nhưng họ đã gặp phải một chi tiết kỳ quặc cần phải khắc phục.

Ví dụ: nếu bạn thấy một câu hỏi về việc sử dụng linq để tạo linq động để sử dụng chống lại linq không động, chín lần trong số mười người, chỉ là tò mò nếu có thể, hoặc sủa sai cây, nhưng có một vài những điều bạn có thể giải quyết theo cách này rất khó đến mức không hợp lý để giải quyết theo cách khác.

Tôi lấy những loại câu hỏi này thành hai phần:

1. nó có thể được thực hiện không, và nếu vậy nó sẽ trông như thế nào
2. nó nên được thực hiện, có rủi ro, hoặc một sự thay thế tốt hơn

Tôi đã thấy rằng tôi hầu như luôn luôn làm chúng theo thứ tự đó. Nó trả lời câu hỏi và cũng giúp bạn đưa ra lời giải thích tốt hơn cho các lựa chọn thay thế tiềm năng.

Tôi không biết về bất kỳ hiệu ứng gây tê nào trong tâm trí của các nhà phát triển nhưng hãy xem ở đây về tác động của các công cụ / ngôn ngữ có đầu óc đánh giá về tỷ lệ. Nói về việc hạ thấp thanh!

Tôi đồng ý với Mason Wheeler. Tuy nhiên, không hoàn toàn điên rồ khi cố gắng giải quyết https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq bằng cách vận hành theo "trình tự". Vấn đề là các trình lặp của Java và .Net không hỗ trợ cả 3 thao tác: giá trị hiện tại, giá trị tiếp theo và chuyển sang tiếp theo. Clojure có thể làm cả 3 và tôi nghi ngờ rằng trong Clojure sẽ dễ dàng hơn để làm điều này đúng. Python cũng có các thói quen chung và tôi muốn thử bẻ khóa nó. http://clojure.org/ Hậu quả http://www.try-clojure.org/

Trong thực tế, nếu đầu vào là một chuỗi vô hạn, chẳng hạn như http://oeis.org/A007401 , thì lười biếng là cách duy nhất.