Чи має Linq вражаючий ефект на програмувачів .NET?

36

Багато з нас почали бачити це явище з jQuery приблизно рік тому, коли люди почали запитувати, як робити абсолютно божевільні речі, як отримати рядок запитів за допомогою jQuery . Різниця між бібліотекою (jQuery) та мовою (JavaScript), очевидно, втрачається у багатьох програмістів і призводить до того, що багато невідповідних, згорнутого коду записуються там, де це не потрібно.

Можливо, це лише моя фантазія, але я клянусь, що я починаю бачити хитрість у кількості питань, де люди просять зробити подібні божевільні речі з Linq, як знайти діапазони в відсортованому масиві . Я не можу зрозуміти, наскільки доречні розширення Linq для вирішення цієї проблеми, але ще важливіше те, що автор просто припускав, що ідеальне рішення передбачає Linq, не думаючи про це (наскільки я можу сказати). Здається, що ми повторюємо історію, розводячи нове покоління .NET-програмістів, які не можуть визначити різницю між мовою (C # / VB.NET) та бібліотекою (Linq).

Що відповідає за це явище? Це просто галас? Сорокові тенденції? Чи взяв Лінк репутацію форми магії, де замість того, щоб насправді писати код, потрібно просто вимовити правильний заклик? Я навряд чи задоволений цими поясненнями, але нічого іншого не можу думати.

Що ще важливіше, чи це насправді проблема, і якщо так, то який найкращий спосіб допомогти просвітити цих людей?

programming-practices .net

— Aaronaught
джерело

6

+1 для "припускав, що ідеальне рішення передбачає Лінк, але насправді не думаючи про це". Це дійсно поза мною.

— Яко Преторій

1

Linq повільний ...

2

@Pierre: На якій підставі ви заявляєте це твердження?

— Aaronaught

5

@Mason: Це абсолютно жахливий орієнтир, написаний кимось, хто явно не знає, що вони роблять. Бенчмаркінг у кліщах? Угорська позначення? І версія Linq навіть не робить те саме, вона намагається повторити кожен результат, а не зупинятися на першому. Не кажучи вже про те, що вся передумова є дурною, про що, безумовно, йшлося в гарячому сьогоднішньому питанні .

— Aaronaught

3

І, до речі, @Mason, Linq вбудовано багато оптимізацій. Для майже будь-якого методу, який може бути оптимізований, він спочатку шукає інтерфейс, що підтримує оптимізований метод. Для інших методів, заснованих на наборах, таких як еквіджоїни, він створює хеш-таблиці. Він не оптимізує ваш код для вас, але він також не буде робити ваш код повільніше; більшість фактично задокументованих уповільнень реального світу пов'язані з лямбдами / закриттями, які не залежать від Linq.

— Aaronaught

52

Це в основному тому, що програмування принципово складно. Це вимагає багато логічної, структурованої думки таким чином, що багато людей просто не знають, як це зробити. (Або просто не вдається, залежно від того, кого ви слухаєте.)

Такі речі, як LINQ та jQuery, значно полегшують певні загальні завдання з обробки даних. Це чудово для тих із нас, хто знає, що ми робимо, але прикрий побічний ефект полягає в тому, що він знижує планку. Людям, які не мають уявлення про те, що вони роблять, простіше почати писати код і змусити роботу працювати. А потім, коли вони натрапляють на реальність і знаходять щось принципово важке, що їхні прості методи високого рівня абстракції не дуже підходять, вони губляться, бо не розуміють платформи, на якій будується їхня бібліотека.

Ваше запитання начебто на вірному шляху, але так само, як і багаторічна суперечка про насильницькі відеоігри, що "перетворюють дітей на насильство", мають напрямок посилання назад. Легкі методи програмування не роблять програмістів дурними; вони просто залучають дурних людей до програмування. І насправді з цим можна зробити не так багато.

— Мейсон Вілер
джерело

30

+1 за "Легкі методи програмування не роблять програмістів дурними; вони просто залучають дурних людей до програмування."

— Стівен Еверс

1

Одна чудова річ про LINQ - це те, що вона дозволяє мені прототипувати рішення у функціональному підході. Потім, коли у мене є рішення про помилку, я можу використовувати його як тестовий стенд для оптимізованої необхідної версії. Якщо завдання досить просте, як застосування одного фільтра, я навіть не буду турбуватися.

— ChaosPandion

5

Я все ще сумніваюся, що LINQ приваблює некомпетентних програмістів - із того, що я бачив, це здається однією з найскладніших концепцій, яку можна зрозуміти для новачків - але, здається, це найкраща відповідь поки що.

— Aaronaught

1

Ви повинні поставити авторське право на це останнє речення. Добре сказано, сер.

— AJ Johnson

1

Смішно. Для мене LINQ - це не поняття, яке особливо легко освоїти. Якщо ви робите що-небудь підступне, дуже швидко вам потрібно перестати думати про кермо і почати розуміти трансмісію. Я дивлюся на тебе ламда!

— Брайан Маккей

13

Для мене це нове іграшкове явище. Виходить щось нове (LINQ), і тепер кожен розробник хоче пограти з ним.

Вони бачать LINQ як молоток, і кожна проблема - цвях. Кого хвилює, чи простіше це зробити іншим способом? LINQ має бути відповіддю! Як, коли всі використовували XML для ВСЕ! Файл конфігурації? XML. Зберігання даних? XML. І т.д.

— PSU_Kardi
джерело

5

Тут не хочеться починати дебати XML, але варто зазначити, що XML насправді хороший у обох цих речах. Це не завжди оптимально - якщо файли конфігурації не потрібно структурувати, то KVP краще, а якщо сумісність між додатками не є вимогою, то двійковий формат явно кращий для зберігання / серіалізації. Але я не думаю, що XML є настільки чудовим прикладом, оскільки він, як правило, застосовується в областях, де він був просто неоптимальним на відміну від абсолютно невідповідного.

— Aaronaught

4

+1: Варто дотягнути свої інструменти, щоб побачити, скільки проблем може бути забито у формі нігтя, коли ви вивчаєте технологію.

— Стівен Еверс

+1: Іншими прикладами подібного роду магічного молота є jQuery (про що йдеться у запитанні) та регулярні вирази. Не те, що ці речі погані, адже вони справді корисні, але вони не є відповіддю на все.

— Тім Гудман

14

Я думаю, що "LINQ - це молоток, і кожна проблема - цвях", аналогія підштовхує це трохи далеко. Я б сказав, що LINQ - настільки хороший молоток, що коли велика частина вашої роботи залучає цвяхи, ви можете потрапити в канавку і не помітити, що ви просто забивали в гвинт. Навіть якщо ви не поганий програміст.

— Carson63000

@Aaronaught: З іншого боку, використання XML з довгими іменами поля здавалося мені неоптимальним для передачі даних через низьку пропускну здатність і не зовсім надійні радіозв'язки. Потім знову це те, що я подумав про дизайн бази даних для цього продукту.

— Девід Торнлі

10

Я думаю, що LINQ пропонує дійсно гарну можливість в C # для вирішення проблем, використовуючи більш функціональний підхід. Ми не повинні відкидати новий стиль вирішення проблем лише тому, що у нас вже є щось, що працює.

Походить із важкого фону SQL, мені подобається мати можливість використовувати задану логіку в моєму C # для кращого опису намірів моїх операцій.

Це сказав; контекст є королем, і будь-чим можна зайвим користуватися.

— dotjosh
джерело

Хто звільняє? Я використовую Linq весь час, мене просто хвилює кількість випадків, які я бачу, як люди, які його використовують (або намагаються використовувати), для проблем, явно ітеративних і не встановлених.

— Aaronaught

Я дуже звик намагатися вирішувати проблеми, про які потрібно писати в SQL, і використовувати для цього задану логіку замість курсорів. Зловживання інструментами завжди відбуватиметься, але я припускаю, що принаймні, якщо вони пишуть поганий код LINQ замість поганого процесуального коду, наступна версія .NET буде легше, принаймні, мати можливість паралелізувати його.

— dotjosh

2

LINQ та jQuery - це найновіші «іграшки», і розробники люблять демонструвати, як вони можуть робити речі, використовуючи найновіші речі.

— Dan Diplo
джерело

Я згоден з цим твердженням. Я не дуже впевнений, чи пояснює це конкретний феномен. Люди, які задають ці запитання, насправді не є типовими показниками, хоча це допоможе пояснити, чому інші програмісти намагаються відповідати на запитання, а не обстоювати більш безпечний підхід.

— Aaronaught

@Aaronaught - Так, я думаю, я більше думав, чому люди відповідають на питання, використовуючи такий підхід.

— Дан Дипл

2

Якщо ви правильно користуєтеся Linq і розумієте його під кришкою, ви знайдете всілякі новітні новітні методи програмування.

Тож якщо ви глибоко замислюєтесь над вдосконаленнями, я стверджую, що це робить вас кращим програмістом. Незалежно від того, чи дійсно це робить той чи інший програміст, це не вина Лінка.

Той же аргумент можна зробити і для об'єктно-реляційних Mappers. Хтось справді вже не пише сирі запити SQL проти таблиць баз даних? :)

— Роберт Харві
джерело

10

Гей, я пишу сирий SQL ... sniff

— Aaronaught

2

Сирий SQL - найкращий вибір, якщо ви знаєте, що робите.

— Фоско

1

+1 за аргумент "робить вас кращим програмістом". Розуміння зв'язку та особливо методів, які її підтримують, безумовно покращило моє розуміння деяких дуже корисних програм програмування.

— Джон М Гант

1

Я думаю, що хтось образився на коментар ORM проти необробленого коментаря SQL. Це не я; Я використовую обоє, і я зрозумів це зауваження як язичко в щоку.

— Aaronaught

1

Я б ніколи не довіряв своїм складним запитам до бази даних лайно, про яке пише ОРМ. Це чудово для простих речей, але так, наприклад, для запитів типу звітування. Знову ж таки, в руках того, хто знає, що вони роблять, ORM - це добре, а в руках того, хто лінивий, щоб зрозуміти бази даних, катастрофа попереду.

— HLGEM

1

Деякі з цих божевільних речей полягають у тому, що люди використовують неправильний молоток, інші - тому, що будують справді елегантний супер-молоток, але вони натрапили на дивну деталь, яку потрібно подолати.

Наприклад, якщо ви бачите питання про використання linq для створення динамічного linq для використання проти нединамічного linq дев'ять разів із десяти, людині це просто цікаво, якщо це можливо, або гавкає неправильне дерево, але є кілька речі, які ви можете вирішити таким чином, які важко зробити безглуздо вирішити інакше.

Я приймаю такі питання у двох частинах:

чи можна це зробити, і якщо так, як би це виглядало
якщо це буде зроблено, чи є ризик чи краща альтернатива

Я виявив, що майже завжди роблю їх у такому порядку. Це дає відповідь на питання, а також допомагає зробити краще пояснення для потенційних альтернатив.

— Білл
джерело

0

Я не знаю про який-небудь заніміючий ефект на розум розробників, але погляньте тут на вплив численних інструментів / мов на ставки. Поговоріть про зниження планки!

— Піт Вілсон
джерело

0

Я згоден з Мейсоном Уілером. Однак не зовсім божевільно намагатися вирішити https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq , працюючи на "послідовності". Проблема полягає в тому, що ітератори Java та .Net підтримують не всі 3 операції: поточне значення, наступне значення та перехід до наступного. Clojure може зробити всі 3, і я підозрюю, що в Clojure легше це зробити правильно. У Python також є спільні програми, і я хочу спробувати це зламати. http://clojure.org/ наслідки http://www.try-clojure.org/

Насправді, якщо вхід - це нескінченна послідовність, наприклад http://oeis.org/A007401 , тоді ледачий - це єдиний шлях.

— Робота
джерело

"Linq" не означає "ітераторів", ані "ледачих" обов'язково - адже більшість Linq насправді стосується дерев виразів. Ви можете легко, якщо хочете, реалізувати свій власний 3-значний або N-оцінений агрегат із закриттям і зовсім не дуже великим кодом у C #. Біда виникає тоді, коли люди не мають уявлення, як насправді це зробити, або навіть як почати, і просто шукають якусь магічну заклик, що живе в System.Linqпросторі імен.

— Aaronaught

@Aaronaught ... '' '"Linq" не означає "ітераторів", ані "ледачих" обов'язково "" - добре, Linq може виглядати як SQL, але цей синтаксичний цукор компілюється у фактичний код IL, який у разі де-компіляції , виглядатиме еквівалентно купі IEnumerable [<T>] з підключеними разом. Цей матеріал лінивий і використовує нумератори, які іншими мовами називали б ітераторами. Але так, проблема полягає в тому, що LINQ робить кодування виглядає легко, а некваліфіковані спробуйте. Деякі з них все-таки можуть стати гідними програмістами. Якщо C # є їхньою першою мовою, і вони загальні ноуби, то вони мають справу з великою мовою.

— робота

Звичайно, Linq для об'єктів (не Linq для SQL, Linq для Entities, Linq для DataSet або будь-яка інша гілка Linq) заснована на ітераторах і відкладеному виконанні, але це все під кришкою. Блоки ітератора та yieldзаява існували перед Linq, як і делегати. Закриття відбулося в тому ж самому випуску, що і Linq, але деякі чисті операції "Linq" насправді потребують збору локальної змінної. Задаючи питання "Як я можу зробити [опис повністю ітеративної операції / функції] з Linq?" зраджує глибоке незнання як самого Linq (що це робиться), так і самої мови.

— Aaronaught