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

I>А можно ссылку на анонс (или демку где скачать)? Хотелось бы сравнить с 1с-овским веб-решением.

ХЗ, я этим не занимаюсь. Знаю что точно есть на диске, который Парус распространяет среди своих партнеров.

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

S>У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC.

Я бы обобщил данный вывод на всех производителей мобилок.

Здравствуйте, AndrewVK, Вы писали:
S>>У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC.
AVK>Я бы обобщил данный вывод на всех производителей мобилок.
Кстати, у меня есть гнусное подозрение, что весь этот доп.софт был как раз саутсорсен в страны третьего мира, как нестратегический. Хотя... такое г могут и свои написать.

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

AVK>>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
ggg>Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.
ggg>Написать серьезный драйвер, игнорируя основные принципы, невозможно.

На самом деле Вы действительно прочитали пару книжек по теории СУБД, но никогда серьезно не работали с ними на практике. На практике использование внешних ключей ни к чему кроме тормозов при вставке данных не приводит, а необходимость в целостности данных не исчерпывает. По-этому проверки проще возложить на другие механизмы, а неудачно созданные в начале разработки внешние ключи, снести во время первого серьезного внедрения.

P.S. Мысли вслух. На рынке полно работоспособных с виду драйверов, и нет ни одной приличной биллинговой системы. К чему бы это...

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

G>P.S. Мысли вслух. На рынке полно работоспособных с виду драйверов, и нет ни одной приличной биллинговой системы. К чему бы это...

Потому что все нормальные спецы заняты написанием драйверов.

P.S. Hello world!!!

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

A>>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.

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

тут обсуждается сравнительная сложность написания драйвера и "распределенную ОО-систему, скажем для управления тех.процессом на предпрятии"

а ты отвечаешь "все работы хороши — выбирай на вкус", т.е. не в кассу

IMHO, драйвера — это нудо и скушно. Весь "высший пилотаж" — в трудностях отладки, да отчасти в недостатке информации. Преодоление этих трудностей — процесс, как я уже отметил, нудный и скушный.

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

ggg>3) "Цена вхождения" в системное программирование выше. Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например, и написание хоть как-то работающего приложения.

Ну да, мне 1С-ники тоже рассказывали, что фигли там ваши java и c#, "цена вхождения в 1С" куда выше. И в чем-то были правы. Потому что 1с-никам нужно уметь не столько программировать, сколько отлично знать бухгалтерию, учет, и т.п.(иногда эти знания лучше, чем у бухов и руководителей предприятий, куда это все внедряется).
Вобщем, каждый свое болото хвалит.
А на деле получается, как уже говорили, сравнение кто сильнее: слон или кит. Потому как сравнить можно что-то четко измеримое. Понятие "крутость программиста" не есть измеримое.

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


AVK>Драйвера S3 до самого конца. Драйвера nVidia времен Riva128, драйвера Voodoo, драйвера 100Мбит сетевух на DECовском чипе, драйвера звуковых карт Creative, референсные драйвера тюнеров Philips. Это то, что сразу вспомнил.

Драйвера безпроводных сетевух D-Link(регулярный BSOD на всех машинах, пока не поставили обновленные дрова из инета).
Первые драйвера для телефона Samsung D600(как раз в то время, когда они только появились, и еще рекламировались на каждом углу) это та еще сказка (по мотивам фильма ужасов).

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

E__>Первые драйвера для телефона Samsung D600(как раз в то время, когда они только появились, и еще рекламировались на каждом углу) это та еще сказка (по мотивам фильма ужасов).

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

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

Д>телефоны у них сейчас вполне приличные, в отличие от софта. Хотя у других сотовых компаний софт ничем не лучше.

Какое-то время спустя... Их телефоны действительно многие хвалят. Лично я их софт не видел. Не довелось пользоваться их продукцией.

Д>Во всяком случае, это касается того софта, который я видел лично. Может быть, кому то и довелось видеть "синюю птицу" — нормального качества софт для телефонов

Здесь, похоже, ничего не изменилось. У меня, к примеру, NOKIA. Очень юзабельный сам по себе, но софт... Поубивал бы. Переставлять иногда при подключенном к компу телефоне приходится, иначе невозможно заставить его работать. Не видят они друг друга.

Ай какая радость. Я вот DDK MVP, и ни разу в такой славной нитке не поучаствовал

Несколько соображений.

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

Так вот, граница понятия "системное программирование" проходит именно вот тут. Это не обязательно кернел. Это и сложная алгоритмика, и наукоемкие задачи (типа OCR). Это и юзер-модный код, который исполняет главнейшую функциональность продукта — а весь остальной код есть обертка вокруг него, UI к нему, удаленное управление им по сети, хранение параметров для его запуска в базах данных и так далее.

Несложно догадаться, что между этими двумя классами задач есть принципиальная разница, даже на уровне руководства проектами (о чем и писал Гапертон), не говоря уж о технических уровнях.

Разница эта приводит, например, вот к чему: в "прикладных" проектах действительно применим паттерн "1 умный архитектор — орава посредственных кодеров". Там реально ниже требования к профессионализму программиста. Там устроят посредственности. Продукт все равно будет работать, и работать удовлетворительно. Вон тут жаловались, что у CBOSS нету декларативных внешних ключей. И чего? плохо работает? а почему-то МТС на нем жил долгое время. Региональные мобильные провайдеры по сей день живут.

Что такое непрофессиональный драйверописатель? это угребищные драйвера к клавиатурам Лоджитека и к принтерам Лексмарка. Т.е. низкое качество девелоперов — сразу низкое качество продукта. В угребищность есть и второй вклад — продакт-менеджеры настояли на никому не нужных доп. фичах и всяких угребищных порнотных вылезалках-для-дебилов, которые невозможно реализовать корректно зачастую (Windows не позволяет из некоторых контекстов), и они реализованы некорректно — но лоховство девелоперов тоже играет роль.

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

Какова бы не была тяжесть последствий такого бага, его цена невысока, ибо он элементарно ловится совершенно стандартным тестированием (всю бизнес-логику можно вообще юнит-тестами обвязать и разрабатывать test-driven, а баги в UI бросаются в глаза) и столь же элементарно правится. Сложных багов там не бывает в принципе, ибо разработка есть сочетание готовых кубиков, а кубики — хорошего качества (ибо написаны в более серьезной компании более серьезными людьми).

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

Я не буду говорить, что в прикладном программировании все глупы. Я только буду говорить, что там все проще. Намного. Там _устроят девелоперы более слабого уровня_. Вот например — многонитевое асинхронное программирование — это некий барьер в мозгу, и я реально видел девелоперов, у которых это реально не помещалось в голове. Я не говорю, что все прикладники такие. Я говорю, что в прикладниках устроит и такой.

Ну вот пример. В 90ые годы писали на таких языках, как Клиппер и Кларион — помните такие? на них решали реальные задачи для реальных бизнесов, года с 91 была написана немеряна куча самописок на Клиппере для автоматизации совершенно реальных потребностей достаточно серьезных организаций — участки финансового учета, кадровый учет, кажется, старая версия Паруса (1994) тоже на Клиппере была написана. Технологии реально и успешно использовались, и жили до массового перехода на SQL и сервера баз данных, который произошел во второй половине 90х — 95-00 есть довольно точная временная оценка этого перехода в московском ИТ. Короче — реальные тулы для реальных задач.

Теперь дальше. Вы помните язык Клиппер? ляп-ляп-ляп большие стандартные куски — оператор BROWSE такой был там, помнится, показывал связанный с ISAMовским курсором грид и ждал ответа юзера. Реальные задачи на нем так и программировали — ляп-ляп-ляп, нажми на кнопку, получишь результат. Почти никто не вдавался в подробности, почти никто не пытался что-то заточить под себя — а те, кто пытались, быстро понимали, что это мартышкин труд, и данный тул просто это толком не поддерживает.

А PowerBuilder? а на Access что-то тоже программировали? а FoxPro? вот это все семейство одного уровня. Кто-то лучше поддерживает SQL, кто-то хуже, но философия у них у всех примерно одинакова. "Потащи Data Control мышкой, положи на форму".

Тупая, монотонная работа. Там вполне устроит тупой. Сложное там только управление требованиями (что ранее называлось "постановка задачи").

Сравним разработку складского учета на Клиппере и разработку сервера приложений на COM и ATL. Кому-то приходилось делать и то, и другое? При разработке на COM/C++/ATL возникает ощущение эдакого создания своей ручной работы, хотя там и есть стандарные кубики типа _com_ptr_t и классов ATL. А на датабазных тулах того поколения? сборка мозаики из стандарных кубиков. Стандартная и туповатая. Разница примерно та же, что между художником (пусть и художником-оформителем вывесок) и маляром.

Это я вот к чему. Старик Маслоу сказал, что у нормальной личности (ну пусть относительно нормальной) есть тенденция к саморазвитию. Есть тенденция ставить себе challenges и их решать.

Вырасти из клиппериста в Си++ника — это таки challenge, ибо разница между двумя языками — примерно такая же, как между вступительными задачками по математике на мехмат МГУ и в борисоглебский (городок такой рядом с Урюпинском есть) пед.

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

Но мне очевидно, что математики на мехмате МГУ — это качественно иной уровень.

Если человек хочет быть Настоящим Математиком, ставит себе такой challenge, такой Путь для самореализации — то ему надо стремиться на мехмат МГУ. Нет, начать можно и с борисоглебского педа. Но нельзя им заканчивать под лозунгом "а мы тоже важное и нужное дело делаем". Остановишься на этом — Математиком с большой буквы не станешь. Станешь "тоже важным и нужным человеком". Возможно, это тоже неплохо.

Профессиональный уровень — стремление к повышению которого я считаю чуть ли не высшим способом самореализации — как раз и определяется — чем занимается коллектив, где ты работаешь (коллектив есть всегда, минимальны 2 человека — ты и твой заказчик)? какого уровня задачи решает? какого уровня профессионалы тебя окружают? каково качество твоего общения на профессиональные темы? в этом и есть разница между уровнем, скажем, архитектора из Паруса (привет AVK ) и училки информатики из Весьегонска. Или продавцом мамок с Савелы — они там, кстати, себя мега-спецами мнят

Вот это и есть разница между рядовым (не-руководящим) системным программистом и рядовым программистом-прикладником.

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

Была когда-то единственная женщина в ядре Линукса — голландка по имени, кажется, Полина Мидделинк. Была у нее веб-страничка с резюмешкой. Профессиональный опыт? ваяние формочек на Аксесе где-то. Линуксом занималась в свободное от работы время.

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

В сторону: я вот предвижу, придет сейчас сюда ПиЭм или тимлид из какого-нить Сибосса и скажет "да что этот Линукс, фигня это все, несерьезно, вот бизнес-приложения — другое дело!". Или произнесет еще какую заяву из серии "умное не востребовано на рынке".

Вот у меня при таких выступлениях (обычно ими занимаются люди, которые, возможно, толковые администраторы и управленцы, но никогда не были хорошими программистами) возникает ассоциация с бригадиром грузчиков или там прапорщиком, который орет на тему "да хули они там на своем мехмате МГУ фигней маются! вот чугуний таскать — это да, Дело!". И действительно дело. И чугуний народу нужен, и дело это для настоящих мужиков. Только вот _разницы в уровнях мехматянина и профессионального таскателя чугуния_ это не отменяет. Хотя да, мехматянин мог до поступления и чугуний потаскать — в армии, например.

Умное на рынке, кстати, востребовано, просто рынок узкий, и пробиться туда сложно. Думаю, что можно даже получать нормальные деньги даже в России, занимаясь фулл-тайм развитием ядра Линукса. Сам не пробовал, но, думаю, возможно — если, скажем, обратить на себя внимание кого-то из мэйнтейнеров, сделать добровольцем несколько полезных контрибуций, а там, глядишь, Редхат или еще кто и на оклад возьмет. Думаю, что возможно, хотя и ой непросто и идти к этому придется долго.

Теперь представим себе такого человека. Вы знаете, у меня есть основания полагать, что его прикладной софт не будет интересовать вовсе со всей своей востребованностью на рынке. Из серии "так, где-то что-то существует, но я тут при чем?". Ни у одного прикладника — в т.ч. ПМов и архитекторов — никогда не получится всерьез доказать ему, что он мается херней. Человек в высшей степени профессионально самореализован.

Какие у нас еще есть пути самореализации умных прикладников? Два назову с ходу просто по материалам этого форума.

Во-первых, это погружение в детали и нюансы конкретных _тулов_. Не _платформ_, а _тулов_. Разница очевидна — для успешной работы с платформой нужно знать почти все ее нюансы, а для успешной работы с тулом совсем не обязательно знать все его возможности. 20% зачастую хватит. Зачем открывать все лезвия в ноже Victorinox, если задача — карандаш наточить?

Причем некоторые особенности тулов (в т.ч. языков) таковы, что совершенно очевидно — сделано ради чистого интеллектуального изыскания и строительства башни из слоновой кости. Ну например — нахрена RTTI в Си++ на уровне языка? недостатки этой фичи описал сам же Страуструп в начале 90х.

Потому лично мне такая возможность тула просто не интересна. Я знаю саму концепцию RTTI. Я знаю, что она полезна дай бог в 5% задач. И я знаю, что, если мне она будет действительно нужна, я ее сляпаю за 10 минут на макросе типа MFCшного DECLARE_DYNAMIC, и сделаю это без багов (делов-то). При этом я буду иметь контроль над имплементацией, а не полагаться на компилятор, и смогу сделать такой class object, какой нужен мне под конкретную задачу, а не какой нужен Страуструпу в его башне из слоновой кости.

Ну или — нахрена лямбды? сложно дать этому куску кода какое-то имя, и сделать из него просто функцию? читабельнее будет. Значительно.

Сидим как-то с коллегой с бывшей работы (великолепный Си++ник и архитектор) на одной из Платформ, слушаем бессмертное выступление Шатохина, который "потерял здоровье от Джавы" . После выступления со всех сторон пошли ремарки типа "а вы пользуетесь ABC? нет, XYZ намного лучше!". Я прослушал это несколько минут и говорю коллеге — "смотри. Здесь почти все обсуждение идет — о _тулах_. Тут обсуждают не задачи и методы их решения, а кто с каким тулом игрался". Коллега согласился.

Интеллектуальна ли такая деятельность? да. Бесспорно. Головоломки с темплейтами тройного уровня вложения — не сразу поддаются решению. Это вполне достойный полет интеллекта.

Что лично мне в нем не нравится — нет ориентации на результат, на решение реальной девелоперской задачи. Деятельность, целью которой является не результат, а сам процесс, называется в философском словаре — игрой. Потому речь идет об _игрании_ в тулы и языки, как будто это бирюльки.

Головоломный код с многовложенными темплейтами — это хорошо. Но скажите, кто будет писать головоломный код в _реальном проекте_, где надо достичь результата? Головоломный код в реальном деле — это зло.

Так же злом является использование наворочанных узкоспециальных фич не по делу. RTTI не по делу (пиши полиморфно!). Лямбды не по делу (лямбды полезны в узких конкретных случаях), и прочее такое.

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

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

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

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

Но вспомним, что написано в книгах. Просмотрел по диагонали этот знаменитый текст про 10 главных паттернов — и понял, как персонаж Мольера, что я всю жизнь говорил прозой что все это я давно знаю и пользуюсь каждый день, что, например, паттерн визитора — это и до боли известный IPersistStream::Save(IStream*), и IoSetCompletionRoutine, где нижележащий драйвер "посещается" completion contextом через адаптер под названием IRP, и прочее такое. Эти паттерны (не поименованные) есть еще в книжке VAX/VMS Internals, про ОС 70х годов.

Все это и так понятно. Оттого, что я назову это "паттерн визитора", суть не изменится, как не изменится и решение задачи.

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

Я больше скажу. Не думаю, что Пушкин или Байрон знали, что такое аблаут

Мне говорили — "программирование — это применение паттернов". Ну да. А устная речь — это применение фонем, в том числе дифтонгов. И что, для того, чтобы красиво говорить и сочинять стихи, надо знать, что такое дифтонг?

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

Еще один путь профессионального саморазвития девелопера — это уход в управленцы. Или вообще смена рода деятельности.

Что мы имеем:
— рядовой прикладной программист — это явно "не задача" и "не дело" для человека с развитым интеллектом. Начинать можно и с нее. Жареный петух клюнет — можно заниматься и этим. Но всерьез застрять на такой деятельности? ну, можно и чугуний всю жизнь грузить или работать сборщиком электророзеток. Все это тоже очень нужно людям.
— хобби в виде играния в головоломный код, изучение мельчайших фич языков и экзотических языков, а также играние с тулами — вот это уже достойное для интеллекта занятие.
— уход в высокие эмпиреи чистой архитектуры-по-книжке — тоже достойное для интеллекта занятие.
— системное программирование — тоже достойное для интеллекта занятие, и имеет (в глазах некоторых людей вроде меня) преимущество перед первыми двумя — строгая мотивация на результат. Интеллект применяется именно для достижения результата, а не для игры в башню из слоновой кости из многовложенных темплейтов, паттернов и лямбд.
— уход в другие профессии и в чистый менеджмент я не буду обсуждать. Там все другое. Мы обсуждаем чисто интеллектуальные пути самореализации, а у человека есть еще много что — воля, целеполагание, социальные навыки, харизма, интуиция, личное обаяние, и прочее и прочее.

Итак, я показал несколько различных путей самореализации прикладника, многие из которые весьма интересны с чисто познавательной точки зрения как гимнастика ума, и показал то, чем, с моей ИМХовой точки зрения, системное программирование отличается от них в лучшую сторону — интеллект применяется _прямо на достижение главной цели девелопмента_ — получения продукта, удовлетворяющего требованиям, а не на "сделайте мне красиво".

Я не буду говорить, что драйверист (да а почему только драйверист? мало серьезных задач, не ляпаемых из стандартных кубиков, и не представляющих собой кучу мелких скриптиков для SQL Server или для IE/Мозиллы?) обязательно превосходит архитектора-прикладника интеллектуально и круче него только горы. Я буду говорить, что по степени интеллектуальности эти виды деятельности примерно одинаковы, при этом у драйвериста интеллект идет прямо в лоб на достижение цели. Более "целеположенная" работа. Кому-то это нравится, кому-то это кажется занудным. Тут уже дело вкуса.

Здравствуйте, Maxim S. Shatskih, Вы писали:

Все комментировать не вижу смысла. Но мимо некоторых частей сообщения пройти не могу.

MSS>При разработке на COM/C++/ATL возникает ощущение эдакого создания своей ручной работы, хотя там и есть стандарные кубики типа _com_ptr_t и классов ATL.
Это не кирпичики, а костыли нужные исключительно из-за убогости С++.

MSS>Ну или — нахрена лямбды? сложно дать этому куску кода какое-то имя, и сделать из него просто функцию? читабельнее будет. Значительно.
Это ты так говоришь исключительно по тому что не понимаешь ФВП(функции высшего порядка).
А пользоваться ими без полноценных замыканий почти не возможно.

MSS>Интеллектуальна ли такая деятельность? да. Бесспорно. Головоломки с темплейтами тройного уровня вложения — не сразу поддаются решению. Это вполне достойный полет интеллекта.
Только совершенно бесполезный.
Те абсолютно.

MSS>Головоломный код с многовложенными темплейтами — это хорошо.
Плохо.
Гораздо лучше изучить что-то болие чистое.
Например какойнибудь функциональный язык.
После этого эти трех этажные шаблоны можно будет понять с пол пинка. И главное понять их убогость.

MSS>Так же злом является использование наворочанных узкоспециальных фич не по делу. RTTI не по делу (пиши полиморфно!).
Не всегда возможно.

MSS>Лямбды не по делу (лямбды полезны в узких конкретных случаях), и прочее такое.
Гы! Утверждение типа:

Циклы не по делу (циклы полезны в узких конкретных случаях), и прочее такое.

MSS>- хобби в виде играния в головоломный код, изучение мельчайших фич языков и экзотических языков, а также играние с тулами — вот это уже достойное для интеллекта занятие.
Изучение экзотических языков это вполне практическое занаяте.
Оно повышает уровень владения всеми остальными языками.

MSS>- уход в высокие эмпиреи чистой архитектуры-по-книжке — тоже достойное для интеллекта занятие.
Паттерны это отходы жизнедейтельности архитекторов. (С) вродбе Гапертон

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

MSS>>Ну или — нахрена лямбды? сложно дать этому куску кода какое-то имя, и сделать из него просто функцию? читабельнее будет. Значительно.
WH>Это ты так говоришь исключительно по тому что не понимаешь ФВП(функции высшего порядка).
WH>А пользоваться ими без полноценных замыканий почти не возможно.

А почему замыкание не может иметь имя?
Вот по языкам, с которыми приходилось часто сталкиваться:
— C (gcc'шные расширения): есть вложенные функции, которые могут быть переданы по указателю куда-то наружу, при этом создаётся "трамплин" (trampoline), добавляющий заданный при его создании аргумент. (Иногда ещё такое средство называется thunk.)
— Perl: единственный вариант создать замыкание — определить функцию внутри создающей, которая захватит значение переменной на момент её создания.
— Python: есть и lambda, и вариант создания вложенной функции. В обоих случаях, опять же, происходит создание ссылки на переменную со значением в момент создания.

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

На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.

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

N>- C (gcc'шные расширения):
Для полноценных замыканий нужен ГЦ. В С у нас уже появился ГЦ?

N>- Perl:
N>- Python:
Языки мутанты.

N>На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.
Практика работы на немерле показывает что именованные локальные функции засовывают в ФВП в двух случаях:
1)Много кода.
2)По ходу дела кусок кода используется несколько раз.
А заводить целую функцию ради выражения a + b когда можно написать (a, b) => a + b ИМХО маразм.

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

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

N>>- C (gcc'шные расширения):
WH>Для полноценных замыканий нужен ГЦ. В С у нас уже появился ГЦ?

Нет, там ограничение, что такой трамплин живёт столько, сколько живёт породившая его внешняя функция. Тем не менее это даёт возможность делать свои специфические callback'и с полным контекстом. Я от Си в принципе большего тут и не жду. Конечно, в общем случае хотелось бы ещё и библиотечку создания трамплинов собственными силами (чтобы не зависеть от жизненного цикла фрейма), но обычно можно и без этого обойтись.

N>>- Perl:
N>>- Python:
WH>Языки мутанты.

Вот так вот — одним ярлыком срезали два утверждения:) Да, полемический приём знатный, уважаю. А по сути? (Я уж не говорю, что эти "мутанты" дают работу и удовлетворённых пользователей мне и ещё массе знакомых)

N>>На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.
WH>Практика работы на немерле показывает что именованные локальные функции засовывают в ФВП в двух случаях:
WH>1)Много кода.
WH>2)По ходу дела кусок кода используется несколько раз.
WH>А заводить целую функцию ради выражения a + b когда можно написать (a, b) => a + b ИМХО маразм.

Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

в таком же месте. Но как Вы потом будете разбираться, например, откуда появилась эта функция? А если она прошла по ссылке через десяток других функций, затем была вставлена в ещё парочку замыканий? Если у неё есть имя — оно будет напечатано (не знаю как в Nemerle, но в питоне — точно), с точностью до модуля и собственно функции. Для поиска это полезно. А у Вас?
Будете весь код грепать?

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

N>Нет, там ограничение, что такой трамплин живёт столько, сколько живёт породившая его внешняя функция. Тем не менее это даёт возможность делать свои специфические callback'и с полным контекстом. Я от Си в принципе большего тут и не жду. Конечно, в общем случае хотелось бы ещё и библиотечку создания трамплинов собственными силами (чтобы не зависеть от жизненного цикла фрейма), но обычно можно и без этого обойтись.
Это все очень убого.

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

N>Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

в таком же месте. Но как Вы потом будете разбираться, например, откуда появилась эта функция? А если она прошла по ссылке через десяток других функций, затем была вставлена в ещё парочку замыканий? Если у неё есть имя — оно будет напечатано (не знаю как в Nemerle, но в питоне — точно), с точностью до модуля и собственно функции. Для поиска это полезно. А у Вас?
N>Будете весь код грепать?
1)Отладчик еще никто не отменял.
2)Данный сценарий случается мягко говоря не часто.
Ибо далеко таскать функцию както не часто приходится. В основном получается что-то типа list.Map(x => x.SomeProp);

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

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

N>>Нет, там ограничение, что такой трамплин живёт столько, сколько живёт породившая его внешняя функция. Тем не менее это даёт возможность делать свои специфические callback'и с полным контекстом. Я от Си в принципе большего тут и не жду. Конечно, в общем случае хотелось бы ещё и библиотечку создания трамплинов собственными силами (чтобы не зависеть от жизненного цикла фрейма), но обычно можно и без этого обойтись.
WH>Это все очень убого.

Безусловно, по сравнению с ФЯ — убого. Но я не жду большего от переносимого ассемблера.

N>>Вот так вот — одним ярлыком срезали два утверждения:) Да, полемический приём знатный, уважаю. А по сути? (Я уж не говорю, что эти "мутанты" дают работу и удовлетворённых пользователей мне и ещё массе знакомых)
WH>Ну что поделать если авторы этих языков тащат туда что попало.

Я, конечно, понимаю, что секция форума обязывает пофлеймить без обоснований, но меня сейчас интересует именно практический результат. По которому мне питон важнее видимого только в этом форуме Nemerle:))

N>>Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

в таком же месте. Но как Вы потом будете разбираться, например, откуда появилась эта функция? А если она прошла по ссылке через десяток других функций, затем была вставлена в ещё парочку замыканий? Если у неё есть имя — оно будет напечатано (не знаю как в Nemerle, но в питоне — точно), с точностью до модуля и собственно функции. Для поиска это полезно. А у Вас?
N>>Будете весь код грепать?
WH>1)Отладчик еще никто не отменял.

Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
Даже слово "отладчик" тут запрещено.

WH>2)Данный сценарий случается мягко говоря не часто.
WH>Ибо далеко таскать функцию както не часто приходится. В основном получается что-то типа list.Map(x => x.SomeProp);

Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.

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

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

N>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>Даже слово "отладчик" тут запрещено.
Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец.

N>Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.
А причем тут тамер? Изначально речь шла о ФВП. Не забыл?

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

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

N>>Я, конечно, понимаю, что секция форума обязывает пофлеймить без обоснований, но меня сейчас интересует именно практический результат. По которому мне питон важнее видимого только в этом форуме Nemerle:))
WH>Это дело времени. Питон сильно старше.

... и жизненная среда у него шире. Nemerle не для .NET уже есть?

N>>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>>Даже слово "отладчик" тут запрещено.
WH>Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец. :)))

Это не я.:)

N>>Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.
WH>А причем тут тамер?

А почему бы и нет?

WH>Изначально речь шла о ФВП. Не забыл?

Не забыл. Но — тем более.