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

F>Наконец-то — дождались ! Вот оно — ключевое слово: "проще".

Ключевое слово — "к чему знание деталей реализации"

F> Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там

А без некорректных приемов выразить свою точку зрения никак?

F>Факториал — это да, это классика. Но именно как пример. Наверное процентов 90 всех книг по программированию объясняют рекурсию на примере именно факториала. Но между теорией и практикой дистанция немалого размера.

Ну да. И что?

F> Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?

Иногда очень даже стоит. Только вот, сдается мне, как раз таки нерекурсивный обход дерева может вызвать у новичков затруднение, а не рекурсия.
А еще иногда нужно рекурсивный обход замаскировать под нерекурсивный. И вот тут то уже частенько у знатоков быстрой сортировки начинаются проблемы.

F>А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело. Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают

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

F>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг

О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.

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

VE>Вы всего лишь сказали одну банальную истину. Что выбор того или иного алгоритма должен быть осознанным, т.е. надо разобраться в _характеристиках_ и выбрать то, что подходит.
VE>Но это не значит, что я должен уметь писать каждую сортировку (и тем более, что я должен был их когда-то писать), но знать их характеристики — должен. Но и то, только тогда, когда эта сортировка мне понадобится.

Если я правильно понял, он утверждает что человеку без знания подробного алгоритма запомнить характеристики невозможно, и что иное встречается крайне редко.

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

AVK>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.

Эххх, ну когда же все поймете, важна ведь не длина, а диаметр!

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

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

VE>>Т.е. я правильно понял вашу точку зрения:
VE>>1. Программист(инженер) должен учитывать характеристики составных частей при проектировании более сложной системы. Если существующие составные части не подходят, можно использовать специальные нестандартные детали.
VE>>2. Большинство программист(инженер) ленивые и потому берут первую попавшуюся деталь, если не бились ранее лбом по этой теме. Если бились, то обычно разбираются в вопросе и сразу думают, какую деталь лучше взять.
VE>>3. Если программист(инженер) не имеет знаний о сортировках, то он относится к пункту 2
VE>> 3.a [с большой вероятностью].
VE>>?

N>Речь не идёт о знании, как писать конкретную сортировку. Но о знании граничных и оптимальных условий их применения, хотя бы минимальных оценок эффективности. И о том, что лучший способ усвоения этих знаний — написать в порядке обучения хотя бы парочку.
С этим никто не спорит.
Ясно, добавим пункт 4 (чтобы ссылаться).
4. Лучший способ усвоить знания — проверить на практике. Т.е. если инженер пробовал на практике — велика вероятность, что усвоил.

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

Так вот.
* Почему именно сортировок? Требуйте знание всего абсолютно. Или есть некая специфика? Ну так она у каждого инженера своя. Ясное дело, что оптик должен про линзы и аберрации знать. Но это не значит, что если он не знает, то он плохой инженер. Оптик плохой. Программист — это не только написатель алгоритмов. Писатель алгоритмов должен знать сортировки. Обобщённый программист — нет.
* Пока я не понимаю, откуда следует вывод, что если инженер не писал сортировок, то он их не усвоил. Ибо
(A => B) =/> (!A => !B) // =/> — не следует
A: писал сортировки
B: усвоил их

N>Пусть сортировка только классический показательный пример, но программист, который решил применить quicksort на множестве ключей без линейного порядка — мягко говоря, поступает некорректно.
Этого никто не отрицал.
Отрицают, что абстрактный программист должен знать сортировки, иначе он программист уровня ниже, нежели тот, кто писал.

VE>>Во-вторых, если даже он относится к пункту 2, то он сталкивался.

N>Почему?

Потому что именно это утверждает пункт 2: B (берут первую попавшуюся деталь), если A (не бились ранее лбом по этой теме). !A => !B, !B => !A. Если берёт осознанно — бился лбом. При условии, если программист относится к множеству (2), разумеется.

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

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

AVK>>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.

Y>Эххх, ну когда же все поймете, важна ведь не длина, а диаметр!

Девушки говорят — важна и длина, и диаметр!!!

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

AVK>Если я правильно понял, он утверждает что человеку без знания подробного алгоритма запомнить характеристики невозможно, и что иное встречается крайне редко.

Я тоже так понял. И чтобы исключить недопонимание, я предлагаю ввести таки буквенные логические утверждения и пользоваться логикой, что частично сделал

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

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

F>>Наконец-то — дождались ! Вот оно — ключевое слово: "проще".

AVK>Ключевое слово — "к чему знание деталей реализации"
Ага. Теоретически я знаю, как пилотировать самолет, но практически — предпочту обратиться к тому, кто в деталях знает как это делается. Ну извините — опять "некорректный" прием !

F>> Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там

AVK>А без некорректных приемов выразить свою точку зрения никак?
Так живее. Многое проще объяснить на пальцах, чем строить строгое доказательство. Тем более в такой области, где сколько голов — столько и мнений.

F>>Факториал — это да, это классика. Но именно как пример. Наверное процентов 90 всех книг по программированию объясняют рекурсию на примере именно факториала. Но между теорией и практикой дистанция немалого размера.

AVK>Ну да. И что?
И ничего. Я же написал "именно как пример", поскольку на императивных языках обычный цикл эффективнее.

F>> Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?

AVK>Иногда очень даже стоит. Только вот, сдается мне, как раз таки нерекурсивный обход дерева может вызвать у новичков затруднение, а не рекурсия.
А что, программист не должен знать (или хотя бы предполагать) где и в чем могут возникнуть затруднения и уметь их либо обходить, либо решать ? Но для этого, думается мне, надо все же знать и детали реализации.

AVK>А еще иногда нужно рекурсивный обход замаскировать под нерекурсивный. И вот тут то уже частенько у знатоков быстрой сортировки начинаются проблемы.
Не понял — а зачем маскировать ? Ясность — лучшее "украшение" программы (после, понятно, эффективности, т.е. быстродействия и расхода памяти).

F>>А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело. Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают

AVK>Только вот, как оказалось, на современных компьютерах линейный поиск на очень коротких списках может оказаться самым быстрым решением. Вот ведь незадача.
Незадача, да только у кого ? Ведь я и привел пример короткого списка 100 элементов в массиве — это разве много ? Для него, действительно, практически никогда не надо осуществлять дополнительных телодвижений.

F>>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг

AVK>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.
Вот тут, коллега, вы сами себе противоречите Выше, если не ошибаюсь, вы указали мне на использование некорректных приемов. Может, будем последовательными ?

В общем, я понял — минусов я себе заработал

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

VE>Но насколько я понял, вы утверждали, что инженер обязан написать хотя бы пару сортировок, или он клавишное мясо.

Именно сортировка была показательным примером. В каждой суботрасли свой набор таких ключевых знаний.

VE>Так вот.
VE> * Почему именно сортировок?

Уже отвечено много раз.

VE> Требуйте знание всего абсолютно. Или есть некая специфика? Ну так она у каждого инженера своя.

Я так и говорил. Вы почему-то не хотите это прочитать.

VE> * Пока я не понимаю, откуда следует вывод, что если инженер не писал сортировок, то он их не усвоил. Ибо
VE>(A => B) =/> (!A => !B) // =/> — не следует
VE>A: писал сортировки
VE>B: усвоил их

По общей логике — да, не следует. Но практика показывает заметную корреляцию, а психология её обосновывает.

VE>Отрицают, что абстрактный программист должен знать сортировки, иначе он программист уровня ниже, нежели тот, кто писал.

Я не знаю, кто это отрицает — я его не поддерживаю (или поддерживаю с сильными ограничениями).

VE>>>Во-вторых, если даже он относится к пункту 2, то он сталкивался.
N>>Почему?
VE>Потому что именно это утверждает пункт 2: B (берут первую попавшуюся деталь), если A (не бились ранее лбом по этой теме). !A => !B, !B => !A. Если берёт осознанно — бился лбом. При условии, если программист относится к множеству (2), разумеется.

Что-то сильно сложно завёрнуто.:)

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

[]

со всем более-менее согласен кроме

IT>Немерле – это удачная попытка совмещения традиционного программирования и FP. Практически все, что наработано в FP поддерживается в Немерле и уже сейчас готово к использованию. Можно отложить в сторону каменный топор (if/else) и взять в руки охринительной мощности базуку (match). Кривизну out/ref параметров можно заменить на tuples, а зоопарк из приватных методов на удобные локальные функции. Много чего. И главное больше нет необходимости компенсировать скудность тактических средств стратегией.

локальная функция, если она не захватывает контекст, ничем не лучше private static, а может быть и хуже, тк захламляет код оснофной функции. Если же захватывает, то надо быть очень осторожным. Тут по работе пришлось насмотреться на локальные функции в delphi.net — ппц.

[]

Собственно.
Вопрос к fplab и netch80:

"Программист должен написать хотя бы пару сортировок, иначе его уровень программизма ниже, чем у тех, кто сортировки писал."

Если это то, что вы утверждаете, то:

A: уровень программиста ниже
B: написал сортировки
C: усвоил сортировки

Вы утверждаете:
!B => A // Не писал сортировок — плохой программист
что эквивалентно
!A => B // Хороший программист — писал сортироки

Обоснование, как я понял, вот такое:
B => C => !A // Писал сортировки, значит усвоил, значит хороший программист
Далее получаем:
B => !A // пропуская C
И потом делаем логическую ошибку:
!B => A // что явно неверно, т.о. вывод из предпосылок неверен

Т.о. либо у вас другие предпосылки, либо вы неправы.

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

AVK>Скептическое отношение у меня как раз таки к МП, а точнее к его реализации в Немерле.

Мне очень интересно послушать, какие в ней есть реальные проблемы.

AVK>Ну и еще, хоть я и стараюсь с собой бороться, местный неуемный немерлевый пиар, приправленный изрядной порцией демагогии, периодически переходящей в хамство, вызывает чисто инстинктивное раздражение и отторжение.

Угм. "Сниму шапку, пусть назло бабушке уши отмерзнут нахрен". Всё таки странно слышать такую аргументацию от взрослого человека.

Здравствуйте, Константин Л., Вы писали:

КЛ>со всем более-менее согласен кроме
IT>>…а зоопарк из приватных методов на удобные локальные функции.…

КЛ>локальная функция, если она не захватывает контекст, ничем не лучше private static, а может быть и хуже, тк захламляет код оснофной функции. Если же захватывает, то надо быть очень осторожным. Тут по работе пришлось насмотреться на локальные функции в delphi.net — ппц.

Ага, уж лучше замусорить тело класса пачкой функций-хелперов, чем тело одной единственной функции

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

N>По общей логике — да, не следует. Но практика показывает заметную корреляцию, а психология её обосновывает.

Вот именно, что заметную, а не абсолютную.
Утверждение же "должен был писать пару сортировок, иначе его уровень ниже" неверно.
Правильно так: "если не писал пары сортировок, вероятно, его уровень ниже".

Чтобы не было демагогии и искажения собственных слов, я приведу цитату:

_FR>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

Какой ответ на этот вопрос Вы хотите? Можно ответить цинически — мол, есть клавишное мясо, которое не способно даже осознать, что оно теряет и почему. А можно — что пусть себе и дальше продолжает, но пусть осознаёт, где его потолок. В принципе, оба ответа правильны.

Т.е. фактически это равносильно вашему утверждению "Не писал сортировок => клавишное мясо с потолком"

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

AVK>>Ключевое слово — "к чему знание деталей реализации"
F>Ага. Теоретически я знаю, как пилотировать самолет, но практически — предпочту обратиться к тому, кто в деталях знает как это делается.

Либо пойти на курсы и получить 20 часов налета и корочку пилота-любителя.

F> Ну извините — опять "некорректный" прием !

Не извиню.

AVK>>А без некорректных приемов выразить свою точку зрения никак?
F>Так живее.

Ничуть. Так — путь к разжиганию флейма и повышению градуса дисскуссии. Проходили уже. Сейчас твои оппоненты начнут тоже самое делать и понеслась.

F> Многое проще объяснить на пальцах, чем строить строгое доказательство.

Объяснение на пальцах != доказательство по аналогии. Второе выеденного яйца не стоит и ничего не аргументирует ни на капельку.

F> Тем более в такой области, где сколько голов — столько и мнений.

F>>>Факториал — это да, это классика. Но именно как пример. Наверное процентов 90 всех книг по программированию объясняют рекурсию на примере именно факториала. Но между теорией и практикой дистанция немалого размера.

AVK>>Ну да. И что?
F>И ничего. Я же написал "именно как пример", поскольку на императивных языках обычный цикл эффективнее.

А чего ты вдруг про эффективность заговорил, если до этого речь шла о принципах и навыках? Ну и, в данном конкретном случае, факториал эффективнее вообще не считать и воспользоваться табличным преобразованием, там допустимый диапазон аргументов крошечный.
Только это опять все то же самое — увод спора в сторону.

AVK>>Иногда очень даже стоит. Только вот, сдается мне, как раз таки нерекурсивный обход дерева может вызвать у новичков затруднение, а не рекурсия.
F>А что, программист не должен знать (или хотя бы предполагать) где и в чем могут возникнуть затруднения и уметь их либо обходить, либо решать ?

Должен. Но из этого никак не следует необходимость досконального знания большого количества алгоритмов сортировки.

F> Но для этого, думается мне, надо все же знать и детали реализации.

Не знаю. Вопрос в том, что это за затруднения. Если речь о производительности, то, об этом уже говорено не раз, начинать надо не с деталей алгоритмов, а с запуска профайлера.

AVK>>А еще иногда нужно рекурсивный обход замаскировать под нерекурсивный. И вот тут то уже частенько у знатоков быстрой сортировки начинаются проблемы.
F>Не понял — а зачем маскировать ?

Нужно бывает. Попробуй, к примеру, сравнить два дерева.

F> Ясность — лучшее "украшение" программы (после, понятно, эффективности, т.е. быстродействия и расхода памяти).

Иногда ясность количеством деталей забивает основную суть алгоритма. Хороший пример — итераторы в шарпе (и не только в нем, впрочем).

AVK>>Только вот, как оказалось, на современных компьютерах линейный поиск на очень коротких списках может оказаться самым быстрым решением. Вот ведь незадача.
F>Незадача, да только у кого ?

Догадайся

F> Ведь я и привел пример короткого списка 100 элементов в массиве — это разве много ?

Бывает и 10 элементов.

AVK>>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.
F>Вот тут, коллега, вы сами себе противоречите Выше, если не ошибаюсь, вы указали мне на использование некорректных приемов. Может, будем последовательными ?

И где здесь некорректный прием? Я всего лишь указал на нежелательность выяснения, кто тут круче.

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

AF>Мне очень интересно послушать, какие в ней есть реальные проблемы.

А мне уже нет. Я уже мильен раз об этом говорил, и поднимать старый флейм нет никакого желания.

AF>Угм. "Сниму шапку, пусть назло бабушке уши отмерзнут нахрен". Всё таки странно слышать такую аргументацию от взрослого человека.

Это не аргументация. Это констатация факта. Если непонятно — могу проиллюстрировать: когда зовут обедать криком "жрать, суки", у меня почему то аппетит пропадает.
Ну и насчет взрослого человека — давай все таки обходится без хамства.

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

_FR>Здравствуйте, Константин Л., Вы писали:

КЛ>>со всем более-менее согласен кроме
IT>>>…а зоопарк из приватных методов на удобные локальные функции.…

КЛ>>локальная функция, если она не захватывает контекст, ничем не лучше private static, а может быть и хуже, тк захламляет код оснофной функции. Если же захватывает, то надо быть очень осторожным. Тут по работе пришлось насмотреться на локальные функции в delphi.net — ппц.

_FR>Ага, уж лучше замусорить тело класса пачкой функций-хелперов, чем тело одной единственной функции

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

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

VE>Чтобы не было демагогии и искажения собственных слов, я приведу цитату:

VE>

_FR>>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

VE>Какой ответ на этот вопрос Вы хотите? Можно ответить цинически — мол, есть клавишное мясо, которое не способно даже осознать, что оно теряет и почему. А можно — что пусть себе и дальше продолжает, но пусть осознаёт, где его потолок. В принципе, оба ответа правильны.

VE>Т.е. фактически это равносильно вашему утверждению "Не писал сортировок => клавишное мясо с потолком"

В совокупности со следующей фразой это немного странно смотрится

N>Именно сортировка была показательным примером. В каждой суботрасли свой набор таких ключевых знаний.

То ли netch80 быстро меняет свою точку зрения, то ли не до конца ее излагает.
netch80!
Вы не хотите сформулировать свою позицию так, чтобы она не вызывала противоречий?

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

_FR>>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

F>Да, однозначно. Ничто не может служить оправданием халтуры. Конечно, на практике нужно использовать оптимизированные и проверенные библиотечные функции. Но это не значит, что нет необходимости знать основные алгоритмы. Пусть пузырьковая сортировка не оптимальна: она дает навык работы с массивами. А быстрая сортировка — навык работы с рекурсией. Или, по вашему, это лишнее ?

Если человеку ни разу не приходилось писать сортировку, это не значит, что он не сможет это сделать, если понадобится. Измерять профессионализм тем, что человеку приходилось или не приходилось делать — это пустое дело. Единственный объективный индикатор профессионализма — это уровень зарплаты.

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

N>…Единственный объективный индикатор профессионализма — это уровень зарплаты.

А что значит в таком контексте "уровень"? "Уровень", как я понимаю, сама по себе штука необъективная

Если же меряться абсолютным размером… по-твоему это будет "объективно"?

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

I>IMHO ФП и ООП несовместимы.

Давай попробуем сделать так. Представим, что ФП и ООП это не целые парадигмы, а просто набор паттернов. Ну там ООП — это инкапсуляция, наследование и полиморфизм, а ФП даже лень перечислять. Так вот теперь ответь на вопрос, какие из этих паттернов между собой несовместимы.