Здравствуйте, Паблик Морозов, Вы писали:

ПМ>А как тогда отсеять людей, не способных программировать?

я бы проверял навыки, которые вам нужны. Создаете АТД? Тогда задача на список хорошая. Пользуетесь СУБД? Значит программа с запросами к СУБД на используемом языке и/или задача на проектирование базы. Обрабатываете строки? Значит задачи на работу со строками. Пишите параллельные программы? Значит задачи на параллелеизм и обработку конфликтов.

Если вам нужен "кодер для клепания формочек", нафига его мучать АТД, вам главное что бы он знал какой контрол куда применить и что бы бизнес-логику тонким слоем по коду не размазывал.

Здравствуйте, gandjustas, Вы писали:

G>Я не перепутал, я именно их и имел ввиду. Потому что в твоем способе разница нужна между парой рядомстоящих локальных экстремумах.
Ну, значит после второго фейла идём гуглить. Более того: вообще в жизни алгоритм ищется, а не придумывается. Вот только чтоб знать, что искать, нужно проблему идентифицировать, упростить, обобщить, и в нескольких эквивалентных вариантах представить) Потому что алгоритмов, если верить старику Дейкстре, всего лишь примерно сто, а алгоритмически сложных задач сто раз по сто, и одно к другому свести уметь надо)

Я уж не говорю о том, что если работодатель, типа, ganjustas, то можно смело писать очевидное решение за n проходов на linq — скорее всего, прохляет

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, gandjustas, Вы писали:

ПМ>>>Постоянно — это всегда. Программирование — это и есть написание алгоритмов.
G>>Неверно. Современное программирование — комбинирование существующих алгоритмов.
b-3>Так задачу на комбинирование (именно комбинирование, а не вызвать готовую функцию API) ты ж тоже завалишь
Комбинирование — и есть вызов готовых функций. У тебя какое-то другое понимание комбинирования?

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, gandjustas, Вы писали:

G>>Я не перепутал, я именно их и имел ввиду. Потому что в твоем способе разница нужна между парой рядомстоящих локальных экстремумах.
b-3>Ну, значит после второго фейла идём гуглить. Более того: вообще в жизни алгоритм ищется, а не придумывается. Вот только чтоб знать, что искать, нужно проблему идентифицировать, упростить, обобщить, и в нескольких эквивалентных вариантах представить) Потому что алгоритмов, если верить старику Дейкстре, всего лишь примерно сто, а алгоритмически сложных задач сто раз по сто, и одно к другому свести уметь надо)
Не умничай, задачу то ты не решил.

b-3>Я уж не говорю о том, что если работодатель, типа, ganjustas, то можно смело писать очевидное решение за n проходов на linq — скорее всего, прохляет
Конечно прохляет, если всех устраивает.

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, samius, Вы писали:

S>>Решение на Linq может быть лишь немногим менее эффективно чем соответствующее решение на чем-нибудь другом. Конечно, если ты читаешь линком 10000 файлов а паскалем 20-и элементный список из реестра, то проблемы не в линке, а в твоей голове.
b-3>Вот тут я категорически не соглашусь. Проблема в данном случае именно в linq, а не в голове.
Проблема в голове.

b-3>Как философия разработки linq — плоха. Потому что подязык запросов философией разработки никогда, как вы понимаете, не являлся. И то, что "должен быть только один способ сделать это", и "если можно сделать иммутабельно — делай иммутабельно", и то что "ФП лучше всего, а linq — почти ФП, нафиг думать, пишем на linq!", и тому подобные убеждения приводят к тому, что программа на линку читает 10000 файлов, а программа на паскале 20 ключей из реестра.
Ну вот видишь, только проблема в твоей голове не позволяет читать 20 ключей из реестра линком, и почему-то заставляет читать 10000 файлов, причем все сразу, и при этом сортировать их в памяти.

b-3>Кто здесь виноват — судите сами
Межает однозначно проблема в голове. А кто виноват и что делать —

ПМ>>1. Если человек не в состоянии обратить список, способен ли он вообще написать что-нибудь разумное или сразу нафиг?

вообще, это задачка с первых семинаров на ВМик МГУ Если не умничать, пытаясь сразу написать программу, а нарисовать список в виде прямоугольничков, решение становиться тривиальным и очевидным

Здравствуйте, gandjustas, Вы писали:

b-3>>Так задачу на комбинирование (именно комбинирование, а не вызвать готовую функцию API) ты ж тоже завалишь
G>Комбинирование — и есть вызов готовых функций. У тебя какое-то другое понимание комбинирования?
Да, у меня комбинирование — это объединение функциональности.

На простом примере:
Вот есть программа А — ввод данных в форму и сохранение их на диск в XML. И библиотека Б — передача данных по сети (TCP/IP). Это даже не алгоритмы, всё simple и stupid.
Говоришь, вызов готовых функций? И какие готовые функции нужно вызвать, чтобы данные сохранились на диск, но на удалённом компьютере?

Так вот с алгоритмами то же самое.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Mystic, Вы писали:

M>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Mystic, Вы писали:

M>>>>Здравствуйте, Vzhyk, Вы писали:

V>>>>>За 20 лет ни разу не понадобилось писать оное самому. Всегда была в
V>>>>>наличии функция sort.

M>>>>Было похожее: надо из 10 000 000 элементов вывести 1000 первых по определенному критерию. Обычный sort оверхид, ибо сортирует все. Может и есть что готовое, но проще было написать самому...

G>>>.Where(<критерий>).Take(1000)

G>>>И linq-гуано (с) рвет в какашки любые поделки по выразительности.

M>>Увы, на С# я просто не умею писать высокопроизводительный код.

G>Это легко. Вот ты говоришь что у тебя есть массив из 10000000 элементов. Но ведь эти элементы не из воздуха появились.

Данные берутся из базы. Но необходимые запросы выполнятся крайне медленно: кретиев очень много, они строятся динамически, индексы использовать не получается... Да и если запрос должен вернуть примерно 60% всех элементов, то индекс просто бесполезен. Соответственно на основании данных из базы строится SHM-объект, из которого C++-шная утилита, часто методом тупого перебора, выполняет нужные запросы.

Здравствуйте, samius, Вы писали:

b-3>>Как философия разработки linq — плоха. Потому что подязык запросов философией разработки никогда, как вы понимаете, не являлся. И то, что "должен быть только один способ сделать это", и "если можно сделать иммутабельно — делай иммутабельно", и то что "ФП лучше всего, а linq — почти ФП, нафиг думать, пишем на linq!", и тому подобные убеждения приводят к тому, что программа на линку читает 10000 файлов, а программа на паскале 20 ключей из реестра.
S>Ну вот видишь, только проблема в голове не позволяет читать 20 ключей из реестра линком, и почему-то заставляет читать 10000 файлов, причем все сразу, и при этом сортировать их в памяти.
Ну что поделать, специфика отрасли такая. "Голова" формируется программными средствами и книжками по использованию программных средств. Людей, способных более-менее критически это воспринимать — мало.

Напоминаю, что обсуждаем-то мы, должен ли уметь программист разворачивать списки. Если не должен, то должен ли он уметь справиться с задачей про 20 лучших фильмов без чтения 10тыс файлов?

S>Межает однозначно проблема в голове. А кто виноват и что делать — : xz:
Дай на собеседовании задачу "напишите сортировку 20-элементного массива вставками", пол-рсдна будет кричать, что подобное никогда не надо, потому что есть List.Sort и Linq.EnumerableQuery У них у всех проблемы в голове?

Здравствуйте, b-3, Вы писали:

S>>Мне непонятно, почему ты обвиняешь Linq в невозможности создать решение, которое ты на других технологиях даже не рассматриваешь. Может линк не позволяет тебе ходить по списку, который хранится в реестре?
b-3>Линку никак не помогает этот список ни менять, ни читать, не сохранять. Соответственно, linq не позволяет решить задачу вышеописанным способом, а только предлагает "загрузить всё и отсортировать". Можно не применять здесь linq, конечно.
А что применять?

b-3>Делаю вывод, что задача отобрать 20 лучших из 10000 иногда открываемых фильмов, на Linq эффективно не решается.
А на чем решается эффективно?

b-3>Делаю вывод, что бывают задачи, когда правильнее вместо linq запроса написать ужасный for.
Покажи чтоли?

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, samius, Вы писали:

S>>Давай-ка прежде всего сравнивать одинаковые решения. Или ты выбираешь 20 файлов на паскале (читая и сравнивая) и сравниваешь этот подход с решением с ликном. Или ты читаешь на паскале список из реестра и сравниваешь этот подход с решением с линком.

S>>Решение на Linq может быть лишь немногим менее эффективно чем соответствующее решение на чем-нибудь другом. Конечно, если ты читаешь линком 10000 файлов а паскалем 20-и элементный список из реестра, то проблемы не в линке, а в твоей голове.
b-3>Вот тут я категорически не соглашусь. Проблема в данном случае именно в linq, а не в голове.
Именно в голове. Так как linq совсем неплохо может и с реестром работать.

b-3>Как философия разработки linq — плоха. Потому что подязык запросов философией разработки никогда, как вы понимаете, не являлся.
Что значит "философия разработки"? Что ты понимаешь под этим словосочетанием?

Здравствуйте, b-3, Вы писали:

b-3>Дай на собеседовании задачу "напишите сортировку 20-элементного массива вставками", пол-рсдна будет кричать, что подобное никогда не надо, потому что есть List.Sort и Linq.EnumerableQuery

И они будут правы

b-3>У них у всех проблемы в голове?
нет, проблемы у тебя.

Если ты искренне считаешь что для сортировки 20-элементов надо писать что-либо кроме .sort или .orderby, то ты зря тратишь деньги твоего работодателя.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, b-3, Вы писали:

b-3>>Здравствуйте, gandjustas, Вы писали:

G>>>Я не перепутал, я именно их и имел ввиду. Потому что в твоем способе разница нужна между парой рядомстоящих локальных экстремумах.
b-3>>Ну, значит после второго фейла идём гуглить. Более того: вообще в жизни алгоритм ищется, а не придумывается. Вот только чтоб знать, что искать, нужно проблему идентифицировать, упростить, обобщить, и в нескольких эквивалентных вариантах представить) Потому что алгоритмов, если верить старику Дейкстре, всего лишь примерно сто, а алгоритмически сложных задач сто раз по сто, и одно к другому свести уметь надо)
G>Не умничай, задачу то ты не решил.
Я инициировал процесс разработки, который на ранней стадии дал прототип, что уже приятно для заказчика и который, в конечном счёте, после тестирования и переписывания кода, приведёт к решению задачи.

Ты объективно оценил свои возможности и написал дубовый код с n проходами, а то и вовсе отказался решать задачу.

Что из этого лучше? зависит от организации программного проекта на самом деле В очень многих областях лучше отказаться решать задачу, чем написать код, требующий тестирования и работающий не всегда. В других лучше написать код, работающий не всегда, чем огрести зависимости от 10 фреймворков, склеенных соплями)

Соискатель должен понимать, в какую фирму он устраивается. Если б я устраивался конфигурации для 1с писать, боже меня упаси сложные алгоритмы на собеседовании придумывать. А если б в игродев, так понимал бы, что после слов "без готового фреймворка я это писать не буду!" со мной распрощаются) Я себе новую подпись придумал, кстати.

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, samius, Вы писали:

b-3>Ну что поделать, специфика отрасли такая. "Голова" формируется программными средствами и книжками по использованию программных средств. Людей, способных более-менее критически это воспринимать — мало.
Вот ты критически воспринимаешь линк. А в какой книжке ты прочитал что им нельзя ходить в реестр?

b-3>Напоминаю, что обсуждаем-то мы, должен ли уметь программист разворачивать списки.
Мое мнение — уметь разворачивать списки не должен. Но должен суметь его развернуть, даже если не умел. Хотя бы не по месту.

b-3>Если не должен, то должен ли он уметь справиться с задачей про 20 лучших фильмов без чтения 10тыс файлов?
Ну вот смотри. Дали тебе задачу про 20 лучших фильмов из 10к. Ты думаешь что в реестре уже есть 20 записей? Боюсь, что раз в условии этого нет, то и рассчитывать что прокатит решение через чтение из реестра записей не стоит. Помести туда эти записи, тогда потом читай. Так что задача выборки 20 лучших фильмов из 10к файлов без чтения реестра все равно стоит. Следующий момент: линк позволит решить эту задачу не сортируя ВСЮ коллекцию и не держа всю коллекцию в памяти. Вообще больше 20+1 записей держать в памяти для решения этой задачи не нужно. Есть возражения против того, что линком эту задачу решить можно?

S>>Межает однозначно проблема в голове. А кто виноват и что делать — : xz:
b-3>Дай на собеседовании задачу "напишите сортировку 20-элементного массива вставками", пол-рсдна будет кричать, что подобное никогда не надо, потому что есть List.Sort и Linq.EnumerableQuery У них у всех проблемы в голове?
Отвечу за себя. Я кричать не буду, я спокойно отношусь к задачам про сортировку, белочек, гномиков и т.п. Включая те, которые я еще не решал и возможно не решу если придется. А за пол рсдн-а отвечать не собираюсь.

Здравствуйте, Mystic, Вы писали:

M>Данные берутся из базы. Но необходимые запросы выполнятся крайне медленно: кретиев очень много, они строятся динамически, индексы использовать не получается...

Выделенное случается крайне редко и является признаком плохого проектирования.


M>Да и если запрос должен вернуть примерно 60% всех элементов, то индекс просто бесполезен. Соответственно на основании данных из базы строится SHM-объект, из которого C++-шная утилита, часто методом тупого перебора, выполняет нужные запросы.

Ниче не понял, но понял что работает неэффекттивно. Эффективно заставлять базу считать, она умет оптимизировать считывание с диска, в отличие от программного кода.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, b-3, Вы писали:

b-3>>Здравствуйте, gandjustas, Вы писали:

ПМ>>>>Постоянно — это всегда. Программирование — это и есть написание алгоритмов.
G>>>Неверно. Современное программирование — комбинирование существующих алгоритмов.
b-3>>Так задачу на комбинирование (именно комбинирование, а не вызвать готовую функцию API) ты ж тоже завалишь
G>Комбинирование — и есть вызов готовых функций. У тебя какое-то другое понимание комбинирования?

Задача обращения списка и строится из вызова готовых фунций (главным образом функций присваивания), если человек не может скомбинировать эти функции надлежащим образом, то и более сложную программу он не напишет.

Здравствуйте, gandjustas, Вы писали:

G>Нет, это способ отсеять тех кто не писал разворот списка последние полгода.

Нет, это именно способ отсеять тех, у кого голова соображает настолько плохо, что они не могут решить эту задачу.
Если человек помнит, как решать эту задачу (т.е. писал её в последние полгода), я дам другую и отсею его, если выяснится, что он не соображает, а разворот списка просто выучил наизусть.

Здравствуйте, gandjustas, Вы писали:

Ты решил ответить на все мои сообщения сразу?

b-3>>Дай на собеседовании задачу "напишите сортировку 20-элементного массива вставками", пол-рсдна будет кричать, что подобное никогда не надо, потому что есть List.Sort и Linq.EnumerableQuery
G>И они будут правы
С точки зрения "программирования отчётов" конечно да.

b-3>>Как философия разработки linq — плоха. Потому что подязык запросов философией разработки никогда, как вы понимаете, не являлся.
G>Что значит "философия разработки"? Что ты понимаешь под этим словосочетанием?
Подразумеваю набор убеждений разработчика, который влияют на его результат. Ты его уже замечательно поскипал:

должен быть только один способ сделать это
если можно сделать иммутабельно — делай иммутабельно
ФП лучше всего, а linq — почти ФП, нафиг думать, пишем на linq!

могу всё это хорошо расширить, добавив cюда kiss, но это нужно начинать отдельную тему

Если подобные убеждения приводят к тому, что видеоплеер начинает требовать базу данных, .NET 4.5 и небазовую версию Windows, значит в этом случае с этими убеждениями не всё правильно.

G>Если ты искренне считаешь что для сортировки 20-элементов надо писать что-либо кроме .sort или .orderby, то ты зря тратишь деньги твоего работодателя.
Прочитай ветку, которую мы обсуждаем, на примере B2B — сервиса и видеоплеера) Если ты считаешь, что ради сокращения подобного кода до .sort или .orderby можно делать 10 тыщ запросов к вебсервису или сканировать список из дохрена файлов — ты будешь прав далеко не всегда)

b-3>>Соответственно, linq не позволяет решить задачу вышеописанным способом, а только предлагает "загрузить всё и отсортировать". Можно не применять здесь linq, конечно.
G>А что применять?
Уже писал

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, gandjustas, Вы писали:

G>>Не умничай, задачу то ты не решил.
b-3>Я инициировал процесс разработки, который на ранней стадии дал прототип, что уже приятно для заказчика и который, в конечном счёте, после тестирования и переписывания кода, приведёт к решению задачи.

Ты неимоверно пафосно облажался с этим решением. Думаю, что вряд ли такое понравилось бы собеседующим. Одно дело — просто не решить. Другое — не решить ТАК Хоть бы извинился...

Здравствуйте, jhfrek, Вы писали:

J>Здравствуйте, Паблик Морозов, Вы писали:

ПМ>>А как тогда отсеять людей, не способных программировать?

J>я бы проверял навыки, которые вам нужны. Создаете АТД? Тогда задача на список хорошая. Пользуетесь СУБД? Значит программа с запросами к СУБД на используемом языке и/или задача на проектирование базы. Обрабатываете строки? Значит задачи на работу со строками. Пишите параллельные программы? Значит задачи на параллелеизм и обработку конфликтов.

J>Если вам нужен "кодер для клепания формочек", нафига его мучать АТД, вам главное что бы он знал какой контрол куда применить и что бы бизнес-логику тонким слоем по коду не размазывал.

Но сеньёр-девелопер, не могущий решить задачку по программированию для первокурсников — это ведь просто смешно. Зачем он такой нужен? Лучше сразу взять первокурсника, писать SQL-запросы он научится быстрее (т.к. соображает лучше).